Why Perl 6 is different
Let’s be honest. Perl 5, Python, Ruby, they’re almost the same. There are some differences, but when your compare them with C, Java, Haskell or some such they suddenly feel rather superficial. They suitable or unsuitable for pretty much the same tasks, occupying a niche that Perl pioneered: that of a high manipulexity and whipuptitude.
They each operate at the same abstraction level. Even if a language is lacking a feature that the others have, it’s easily implemented using other constructs. There are plenty of valid reasons to prefer one over the other (taste, library availability, programmer availability), but they all offer the same power. Perl 6 is going to change that.
Perl 6, like Perl 5, Ruby and Python steals a lot from other languages. As you may expect, it steals too many things to mention from Perl 5. It steals chained comparisons from Python, objects from Smalltalk (in particular Squeak’s traits should be mentioned). It thankfully steals nothing from PHP.
It has been said that Ruby is Smalltalk with a perly syntax. Perl6 extends on that: Perl 6 is Lisp with a perly syntax.
Perl 5 is already more lispy than most outsiders realize, but Perl 6 takes that to a new level. It is built around a MOP and multimethods. Lists are quite important in it (though their semantics are more like Haskell than Lisp in being lazy). And it has macros.
Macros in Lisp are one of its most powerful features. It gives the programmer the power to mold Lisp into any shape he wants it. In Lisp macros are possible because its uniform syntax of trees of symbols. In Perl 6 macros are made possible by its key innovation. One of the feature it didn’t steal from another language: rules and grammars.
Regular expressions is the most stolen feature from Perl among other languages. It’s ironic that even Python, whose community is most critical about Perl’s syntax, took its ugliest feature in essentially unmodified form. (For an overview of all that is wrong with it, see the introduction of Apocalypse 5). It’s no coincidence that this part of the language has been redesigned from the ground up. In doing so, Larry profoundly changed the language. To quote A5: “Regular expressions are our servants or slaves”; in Perl 6 he emancipated rules and grammars to first class citizens.
Rules are like regexps, but also like methods/functions. Grammars are like classes for rules. This makes rules vastly more powerful. So powerful in fact that Perl 6’s syntax itself is defined in rules and thus in Perl 6 itself.
I can’t overstate how profound I think that change is. I think it’s no less profound than when Lisp made functions first class citizens. For the first time it will be possible to have all the metaprogramming power Lisp has without having to compromise on having syntax. Regardless of the success of Perl 6 (though obviously I do hope it will be successful), I predict that this feature will be its long term contribution to language design.
You know, that's the one thing that bothers me about Perl 6. Like Lisp, it's too flexible.
Since it can be used to create unique languages, every shop out there will. That means a programmer's Perl skills will no longer be portable. Every time you hire a new programmer, he will have to spend time to learn your language before he becomes very effective.
Another problem is that, like Lisp, you can use it to create functions that create functions to do the work. Out there in the real world, people don't want programs that manipulate their data; they want their data manipulated. If programming is the most cost-effective way to do this, then they'll use it. Otherwise they'll use something else. Adding another layer between what the programmer does and the data, just adds something else the programmer has to remember. And people are not very good at keeping a lot of things in their heads at once.
There are reasons why Lisp is not used much outside academia.
Actually, I thinking of switching to Parrot rather than Perl 6 since I can use Perl 6 to compile the modules from CPAN into Parrot and then link them to my code. That way, I'll has a consistent language and the use of CPAN.
The reason lisps are what they are is that they're homoiconic, i.e. the representation of the program is also a data structure [...] of the language itself.
I've looked at Perl 6 and its macro spec from time to time but I've failed to find anything more than a shallow Lisp.
You can define an infix operator like
+as a normal Perl 6 sub just like you'd do in Lisp. But how about some of the more hard things?How would I define the equivalent of a Lisp macro to turn
(5 10 /)into(/ 10 5)in Perl 6? I.e. to make5 / 10 sayprint2? As far as I can see the structure of the AST is still implementation defined making those sort of things hard.Perl 6 also doesn't have "everything is an expression". This makes macros that are natural in Lisp like defining
orin terms ofifawkward. Don't you have to define those with a temporary variable and wrap them in ado {}block?All in all I'm not sold on Perl 6 being the long lost M-expressions. Some of its meta-programming facilities seem more of an afterthought rather than being an inseparable core language feature as they are in Lisp.
Lisp is not something to aspire to. It's alleged beauty lies in its rejection of all the useful tools of communication in favor of the dubious benefits of homoiconicity. I like Perl because of its basis in natural language; data should look different from code because they are different. Different operations should look different because they do different things. This whole notion of "you can do everything with one big S-expression" is an interesting curiosity, but it's a terrible notion upon which to build a programming language.
I'm also a bit tired of every language with first-class functions and closures being compared to Lisp. Maybe Lisp came up with the idea (actually, I don't know if that's true, though it seems to be accepted gospel.) That hardly makes Javascript "just Lisp with curly brackets!!!!!111" or Perl "just Lisp with curse words!!!!!!!!1$@$&$&#@#(&%*@#("
If Perl 6 is going to be Lisp, I'm sure as hell not going to use it. But it won't be Lisp. It'll have first-class functions (hey, just like Perl 5!) and closures (hey!) and macros...just like Perl 5. Wahoo.
FWIW, it seems that I might be wholely unable able re-create Perl's "strict" or even stricter things in Ruby. Currently there's no idea of a pragma to affect a bit of compilation. I've got a bare idea of perhaps implementing such a thing by hooking to yacc but then this could only work on one of the Ruby flavors that actually use yacc grammars. For work, I'm interested in targeting:
JRuby - we're using it for some SOLR linkage MRI Ruby-1.8.6 - current production REE - near term future production
and I just bet that YARV Ruby-1.9.x is also in our future.
So. I have two major flavors (JRuby vs everything else) and then a varying list of related flavors since REE is the productionized derivation of MRI Ruby-1.8 and YARV Ruby-1.9.x is the successor to MRI Ruby-1.9.
It's enough to drive me up the wall. I think it's hard enough extending one interpreter but needing to handle multiples is freaking insane.
Of course, you can do that in perl 5 right now. For solving some problems, it's The Right Thing To Do. For some other problems, it's overly complex. I think that, once people have got over the "ooh, shiny!" response to the new tool, we can rely on people being fairly sensible. Same applies to company-specific grammars making programmers' skills non-portable. Once the "ooh, shiny!" phase has passed, companies won't want to do that precisely because they want to be able to employ people and for them to be useful and productive in minimal time.
I agree with Mike Friedman, Lisp and Perl represent two extremes of programming language paradigms. One is beautiful, idealistic, and "useless" in the real world. The other is "ugly", pragmatic/practical, and very much in use in the real world.
I hope Perl 6 only steals some aspects of macro from Lisp. I hope it stays true to Perl 1-5's design, that is: caring about syntax and making things easy for the programmers instead of parsers.
Btw, last time I checked, macros in Perl 6 are still very much underspecified nowadays? It'll probably take a couple of years until its specification is significantly complete, and even more years before it is usable.
"If once you start down the dark path, forever will it dominate your destiny, consume you it will, as it did Obi-Wan's apprentice."
Once a company starts down the "ooh, shiny" path, it will take a major effort to change it. You see that with COBOL. People still use it because it would cost too much to rewrite all that code. I still think there is such a thing as being too flexible.
@Steven Haryanto -- (Common) Lisp is actually pretty ugly and practical. This is actually why I prefer it to Scheme, which is stubbornly idealistic. Until recently, Scheme didn't even have modules or namespaces because the designers couldn't agree on the "right way" to design them.