Slashdot Mirror
Exegesis 6 (Perl 6 Subroutines) Released
chromatic writes "Perl.com has just published Damian Conway's Exegesis 6 which gives practical examples demonstrating how to use the new subroutine and method semantics in Perl 6. This is the companion to Larry Wall's Apocalypse 6 which discussed the changes planned for subroutines in Perl 6."
The one thing that I always found unpleasant when moving between languages was the keywords... so, I picked up a C book, migrated to C++, then Java, picked up PHP along the way. Everything was fairly similar with keywords and syntax, and then perl threw a monkey wrench into the mix. I've never looked at python, are there similarities there or are the perl gurus guiding us through their path of enlightenment?
--------
Free your mind.
the language is becoming more obtuse if thats possible. The perl programmers I know don't get along well with other languages, mostly because they have spent so much time learning the intricacies of Perl syntax. Even coming from C, Perl syntax is unnatural. Seems like once you go Perl, you can never go back (or try to learn a new language). I've never met a perl programmer who could tell me what a design pattern is either. I guess they don't go for re-use much in perl progging. I think if I went to hell, satan would probably make me write a Perl parser. (without the help of Yacc)
TallGreen CMS hosting
Shortly after I started reading Exegesis 6 I was somewhat frightened by how complex Perl had become since I stopped keeping track of updates. Of course scripting languages have always been known for borrowing the best from other programming languages, so I kept reading in the hopes that I'd recognise something. I saw some features like the is constant declaration and started worrying that maybe they'd decided to borrow some features from the very popular but insanely evil Visual Basic. But then I saw this:
and realised that, just as Python is (alleged to be?) adding Lisp-like features, Perl is adding ML-like features! That line above is (minus the '::' and ';') straight out of a Haskell program. Then I started to notice more Haskell-like syntax:
feed (Cat c) =
feed (Lion l) =
And I'm sure a more thorough reading would turn up even more. (For example, the smart-match operator reminds me of the type inferences done in a Hindley-Milner type system.) So it appears that any sufficiently advanced language contains an implementation of a purely functional language, not specifically Scheme. :) Has Damian (who certainly has Haskell exposure) or Larry ever mentioned any of these influences?
One more thing:
I'm really happy to see Perl include currying, I can't think of a programming language that I would be completely happy using without it.
In the denotational semantics community it was long ago decided that real programming languages are too messy and too much of moving targets for serious theoretical research. As a result, the most popular language is known as Idealised Algol which is a simplified and cleaned-up version of Algol-60 (I'm told Algol-W is the closest implementation).
Now that Perl 6 has a rich operator definition system*, we can look forward to Idealised Perl (IP). IP would be a version of Perl stripped down to only the necessary syntactic building-blocks. Even if much of Perl 6 were implemented in C, it'd be possible to define all the syntax in terms of IP. If you're writing code for maintainability instead of prototyping, using IP as much as possible will ensure a smaller learning curve for non-gurus. IP will be simple enough to actually allow teaching Perl in universities.
IP could be the elegant yet expressive language we all (whether we like Perl or not) wish Perl would be.
* This is, IMO, the only really neat and elegant thing to come out of Perl 6 so far. If operators can be defined to the point where most mathematical formulae are executable, Perl will become a revolutionary tool.
I like Perl. I use Perl often. I also know and use a variety of obtuse languages, including wacky ones like Forth, J, and Haskell, plus more traditional languages such as Python, C++, various BASIC derivatives, etc. In short, I'm not an anti-Perl troll. Blind language advocacy is for newbies.
That said, I can't help but think that far too much thought has been put into Perl. One of Perl's real strengths has always been that it wasn't designed up front so much as accreting things have have been proven to work: hashes, formats, regular expressions, dynamic typing, back quoting, evaluation of variables inside strings, and so on. But Perl 6 is getting years of forethought, and all of that forethought is beginning to weigh things down. The old Perl way would have been to say "Look, now we have a simple parameter passing scheme like that one Python, one which has been proven to work." The Perl 6 way is to start with a series of odd little features, then keep modifying them and adding sugar to them until the end result, after a number of iterations of this, ends up being something that looks and works like Python's parameter passing scheme, but takes ten pages of explaining to fully explain,
In short, this is the kind of thinking that begat PL/1 and Ada and other spectacularly complex languages.
Probably because he doesn't know what he's talking about, and there are numerous errors in his post.
For example, he claims that each variable has its own prefix in Perl 5. That is completely false. A "variable" in perl is a reference to a typeglob, which contains memory slots for each type of value a "name" ( variable ) in perl can store: a scalar, a hash, an array, a filehandle, and a subroutine. The prefixes before a name in perl determine which slot you access ( it is the context you are calling the variable in ).
For instance, @var for the array slot, $var for the scalar slot, %var for the hash slot, &var for subref, etc.
Each "variable type" does NOT have its own prefix. The prefixes specify the context that the variable is being called in.
By the way, *var references the entire "typeglob" at once, allowing you to do things like:
$var1 = "name";
@var1 = (1,2,3);
*anothervar = *var;
print $var1
name
print $var1[1]
2
Maybe if the person actually knew anything at all about perl, then his post would actually be worth paying attention to.
''Now, that being said, I would argue that Perl 5 already presents 99% of Lisp's flexibility. Perl 6 leap-frogs Lisp by presenting Lisp's flexibility in a package that is far easier to use (though, as you point out, perhaps not easier to LEARN).''
Ok, thats funny. I can't speak to the flexibility of Perl 6, but you are on some serious chemicals if you argue that perl5 has 99% of Lisps flexibility.
Perl has some real strengths (and real weaknesses, of course), but it is pushing it to claim it even approaches 50% of the flexibility of lisp. I would put it closer to 20%, but perhaps could be argued upward a bit. We are talking about *flexibility* here, not best-language-cause, so
here are just a few of the reasons perl is way behind lisp (let alone 20 years ago lisp (cltl1)) in flexibility:
'defmacro (there goes 30% right there)
'defgeneric & 'defclass (don't talk to me about perls alleged object system.)
'compile
closures
introspection
semantic sanity
read/write symmetry
applicative programming that works
decent numerics
the list goes and on....