Perl6 Polyglot

by Geoff Broadwell

Related link: http://pugscode.org/




When I first learned that several members of the core Perl 6 design team
(affectionately known as @Larry) had learned Ruby and/or Python, I wasn't
terribly surprised. It pays to understand one's competition after all,
and there are some nice features in each to assimilate. Perl, Ruby, and
Python all share some deep common design attributes, so they're not
exactly new ground, however. They could be considered part of the same
language family, as for example French and Italian are.




What has surprised me of late is the number of Perl 6 designers and
developers that are learning languages from completely different language
families: Dylan, Forth, Haskell, Joy, Lisp, Prolog, Scala, Scheme,
Smalltalk, and who knows how many others. This is a very good thing.




Each of these languages offers a unique perspective on programming. Each
has its own philosophies, world views, conventions, and so on. Most of
them try to be extremely good at at least one thing, and can therefore
warp their entire syntax and semantics around that task. This gives the
opportunity to find features in their "natural environment" that Perl 6
can then assimilate.




And assimilate it does. Just as Perl 5 borrowed heavily from the languages
that came before it, so Perl 6 is borrowing heavily from today's languages.
It's also taking lessons learned from long experience with older languages
from which Perl 5 didn't borrow enough. Here are a few examples:




C



  • Having easy, efficient access to C libraries is important.
    Perl 5 of course has had access to C libraries for a long
    time, but the interface was clunky and slow. The Inline
    group of modules have helped, but it's still nowhere near
    ideal. Perl 6 (and Parrot) have long had a goal of clean
    library call interfaces.

  • Better handling of native data arrays and packed data
    structures is important, too. Again, Perl 6 has long
    had native (AKA unboxed) data types in the design.




Dylan



  • Method resolution in the face of complex inheritance paths
    is a pain. Perl 6's default MRO (Method Resolution Order)
    is based on Dylan's C3 algorithm. In fact, the Perl 6
    OO MetaModel even uses some tests cribbed from examples in
    the original Dylan C3 paper.




Forth



  • The best language for any situation is one designed
    specifically for the task at hand. Perl 6's grammar system
    makes it much easier to do this in Perl. Like Forth and
    Common Lisp in their own ways, Perl 6 allows deep
    control over parsing and macro use. In fact, Perl 6's
    grammar is exposed to the programmer and can be directly
    altered -- or new grammars can be created, and swapped in
    as desired.

  • That said, the base language should have a rich
    non-orthogonal vocabulary, allowing many common tasks to
    be coded clearly, instead of being a mess of contortions
    to get around false simplicity in the language design.
    Perl 6 has this kind of rich vocabulary (in spades).

  • Refactoring is at its best when you can count on the
    compiler to keep everything running fast. Several
    implementors are working on various ways to keep Perl 6
    code running as fast as possible, without forcing the
    programmer to forgo clean, well-factored designs to do
    so.




Haskell (et al.)



  • There's more to Functional Programming than just having
    support for closures. Perl 6 is borrowing heavily from
    the powerful toolsets used every day in FP languages.
    From metaoperators to function signature pattern matching,
    Perl 6 is getting a big dose of higher-order concepts in
    the core.




Java



  • Java teaches mostly by counterexample. Yes, it's true,
    good garbage collection is important, and Perl 5's
    reference counting just didn't cut it. But the biggest
    lesson to be learned from Java is that all these nice new
    features shouldn't result in a horrendous programmer tax.
    Anything the programmer doesn't want to be faced with
    right now should just get out of the way. That's been a
    Perl tenet for some time, but ugly things like parameter
    unpacking (especially hundreds of copies of
    my $self = shift;) have gotten in the way. Many
    of those things are now fixed.




Perl 5



  • CPAN is all-important. In fact, it is probably the one
    thing other language designers are most jealous of from
    Perl 5. Perl 6 can use Perl 5 modules from CPAN directly
    (and Pugs has been able to do this for months, albeit with
    a few gotchas that Ponie should help with) while the
    whole mass is slowly migrated to Perl 6.

  • Perl 5 did a lot of things pretty well. Perl 6 doesn't
    throw them away, but rather tweaks them to be just a
    little bit better.






It's important that it's not just the core language designers that are
learning and borrowing from these disparate languages; the implementers
are as well. Both groups are getting the benefit of the broadened
horizons these languages afford. Sometimes in #perl6
(irc.freenode.net) links to language homepages and papers on language
design and implementation are flying so fast it's hard to just keep up
with the general gist of things.




And it's not just reading. Perl 6 people are going to conferences for
other languages (such as ICFP),
presenting Pugs and Perl 6, sharing knowledge with other language
designers, and soaking up vast piles of information. It's a beautiful
thing.




People have complained about how long Perl 6 is taking to arrive; I used
to grumble about that myself. Now that I watch things growing and changing
on a daily basis, I'm glad everyone is taking their time. There is so
much good stuff to assimilate, care must be taken to not end up with a
huge ugly mess. As when cooking with many ingredients, sometimes the
best thing is to let the pot simmer for a while, to let the ingredients
get to know each other, to mellow out and produce a better whole.




Of course, the benefits of learning completely different computer
languages go beyond just language design. Having new viewpoints on the
problems you face every day can be a great help, even if you don't plan
to change the language you code in. Which is why I'm joining the crowd
and learning Forth, even though I expect Perl will be my day-to-day
language for years to come.




What's your favorite "very different" language? What could Perl 6 learn
from it?


4 Comments

Reedo
2005-09-30 07:44:22
logic programming constructs could be interesting
I haven't used Prolog, but I used CLIPS in a course while getting my bachelor's. I liked the different paradigm of writing a set of rules and just letting the program take it from there (even had a program that implemented Game of Life with remarkably few lines). I'm not sure how this programming style could be integrated into Perl 6. Perhaps its support for user-defined grammars is sufficient to accomplish this. Or maybe something this specialized would belong in a module rather than in the core language.
Geoff_Broadwell
2005-09-30 14:15:31
logic programming constructs could be interesting
There are some Prolog people amongst the Perl 6 crew . . . I'd make a strong bet that Prolog (the functionality and the syntax) will at least be available in a module -- and some of the supporting functionality may be in the core for other reasons anyway. Lazy evaluation is a core feature, for example -- many programming languages and world views require it.
chromatic
2005-10-03 13:04:28
logic programming constructs could be interesting
It would be difficult to implement unification outside of the core (not that it's particularly easy to implement inside of the core...).


It would be very nice to have sometimes though.

GregBuchholz
2005-10-04 08:06:08
Polyglot?
For a different (http://ideology.com.au/polyglot/) sort of polyglot... Maybe someone will port it to Perl 6.