Related link: http://www.parrotcode.org/
One of the prime advantages of dynamic (or agile) languages — the integrated compile and run phase that handles source code directly — is actually a bit of a drawback in some circumstances. If you’re doing very fast low-level bit twiddling, Perl, Python, and Ruby probably aren’t for you. It can be difficult to approach the speed of good assembly or optimized C code.
In some applications, such as high-volume number crunching or real-time games, this is a big drawback.
Fortunately, much as you can drop to raw assembly from C code, you can link your favorite dynamic language with C or C++ code. Unfortunately, it’s usually tedious. Every newer language improved on things. Perl 5’s XS is reasonably easy for the easy things, but can require a downright arcane knowledge of the sometimes-squanmous Perl internals for the complex things. Python is easier. Ruby is easier still.
The Swig project exists to make writing language bindings easier still, but it’s still not easy.
If Parrot, the VM for Perl 6 and succeeds and attracts other languages, it may present an easier solution. Because of Parrot’s design, it’s amazingly easier to write bindings for other libraries. Even better, you can write your bindings once, to Parrot, and then they’re available to all languages that run on Parrot.
Imagine that everyone who looked longingly at PyGame from Ruby could actually use that very library from Ruby.
I’ve been working on just that project (well, not quite a full PyGame port — there are still some details to hash out). At the Portland Perl Mongers meeting on 14 April 2004, I’ll present SDL Parrot by introducing Parrot, Parrot’s Native Call Interface, object oriented Parrot, and, finally, all of the SDL bindings I can implement by then. See the web page for details.
If things go well, I may show off a custom animation language running atop Parrot in the next couple of months. Here’s a snippet of Parrot assembly code (as low-level as I can program productively) that draws a blue square to whet your appetite. Remember, this is an assembly language.
.pcc_sub _main non_prototyped, @MAIN load_bytecode "library/SDL/App.imc" load_bytecode "library/SDL/Rect.imc" load_bytecode "library/SDL/Color.imc" .local pmc app .local int app_type find_type app_type, 'SDL::App' new app, app_type .sym pmc args new args, .PerlHash set args['height'], 480 set args['width'], 640 set args['bpp'], 0 set args['flags'], 1 app.'new'( args ) .local pmc rect .local int rect_type find_type rect_type, 'SDL::Rect' new rect, rect_type new args, .PerlHash set args['height'], 100 set args['width'], 100 set args['x'], 270 set args['y'], 190 rect.'new'( args ) .local pmc color .local int color_type find_type color_type, 'SDL::Color' new color, color_type new args, .PerlHash set args['r'], 0 set args['g'], 0 set args['b'], 255 color.'new'( args ) app.'fill_rect'( rect, color ) app.'update_rect'( rect ) sleep 2 app.'quit'() end .end
This is just one piece of the puzzle for Game Programming with Parrot. Stay tuned.