Slashdot Mirror
Exegesis 3 Released (Perl 6 Examples)
chromatic writes "On the heels of Larry's most recent revelation, the mad scientist of Perl (Damian Conway) has followed up with Exegesis 3. His article gives working Perl 6 code examples of Larry's design decisions." Lots of good stuff in here.
with @all this new $syntax, won't we have to rewrite() our perl jokes? ;)
How can these be working examples when Perl 6 does not even exist yet?
I really used to like perl i thought it was great...
But now that i have been using C++ alot and really learned the in's and out's of the language, perl code really looks kinda nasty.
Yick. I never thought i'd become one of those perl is messy and crusty and ugly types, but looking at that code, blech.
So now they're gonna start using non-ascii characters in the code? Oh that's a joy, like i really wanna have to look up how to make greek characters in text editors.
They blew it, perl 5 was acceptable and pretty useable. Perl 6 just looks silly.
If i have to resort to using a scripting language for something in the future i definatly will avoid perl, especially perl 6.
Perl really is a hacked together mess.
Cool hack, but not cool to actually use for something important.
This is _heresy_ ....
it's starting to look *readable*
Oh that's a joy, like i really wanna have to look up how to make greek characters in text editors.
Use an editor which has Unicode support. This is the year 2001 if you haven't noticed.
For me tho, I guess I'll stick with array reference arguments, anyways. Probably still cheaper and faster. I wonder also if what Damian says is true:
In other words, a @ parameter in Perl 6 is like a \@ context specifier in Perl 5. .
I suspect that passing an actual array is still "by value". Seems like alot of work to avoid confusion that is not really very confusing.
I can't believe how horrible Perl 6 looks.
-Kevin
perhaps o'reilly will change the perl animal to a horse now that it's not so ugly?
The proper answer to "Why do I need to know this?" is always, "Because."
I believe you. Someday you will meet her again.
Some of this new stuff seems to be seriously blurring the difference between language and library.
Of course it's cool to write something like @costs, but why must be an operator? It seems to me it would work just as well as an ordinary procedure.
I'm wondering if they are thinking about constructs to define new syntax at runtime. In Scheme for example most of the syntactic forms are defined in the library using define-syntax .
public class MyPerlClass
{
my public $member_obj1 = new CGI ();
my private %hash = ( 'some' => 'values' );
my private int foo = 1;
public sub new ( const int $int )
{
this.foo += $int;
return this;
}
public sub get_foo ()
{
return this.foo;
}
public sub set_foo ( const int $new_foo )
{
this.foo = $new_foo;
}
private sub _recalculate_stuff ()
{
# some important stuff here...
}
}
perl-lover and then some, but give me syntax sugary OO dear larry!!!
d_i_r_t_y
I do love the hell out of perl, but I sure hope I can "use English 'operators';" for things like the hyper-operators. 'course, maybe 'use English' is deprecated ... can't wait for 'use Chinese', imagine what perl would look like then...
I would much rather see "@diffs = @set1 ^- @set2" expressed as a list comprehension, say @diffs = (each $x - $y suchthat $x in @set1, $y in @set2); (assuming I have said "english operators" on, otherwise I would imagine at least the 'suchthat' operator would be some punctuation char). It's a bit contrived for something as simple as subtracting every member of a couple lists, but list comprehension is beautiful stuff when combined with lazy evaluation in languages like Haskell.
Oh, and Perl6 is going to have an 'in' operator, right?
I've finally had it: until slashdot gets article moderation, I am not coming back.
I want to understand this, I really do, but I just don't. Sorry, Larry and Damien, I tried...
Carousel is a lie!
Man, am I glad I switched to Ruby a few months back. The transistion to Perl6 looks pretty nasty!
Go Ruby! (the O'Reilly book "Ruby in a Nutshell" is due out next month).
No, it'll look like this.
(Ruby)
On the other hand, if you can obscure complex operations into short syntactic sequences, you can keep the programmer from shooting himself in the foot. Look at Java - its syntax is probably as plain and up-front as you can get, but the need to spell most things out explicitly means most programmers spell them out incorrectly. Therein lies the magic of some syntactic freakshows like regular expressions - imagine programmers defining their own NDFAs? I understand this is not a great example as other languages support perl-like regexes, but maybe you get my drift.
I think the conlcusion is that perl will be like Haskell and Lisp in a way (not a functional language per se) in that programming in perl will simply require a different approach and strategy. You'll have to think in perl in order to properly program in perl. It simply won't be for translating C into an interpreted environment or sh into a portable syntax, it'll be its own paradigm.
You may see some new Ruby programmers afte the Perl 6 fallout - I think there is going to be a severe backlash when Larry unleashses a language so vastly different from the pervious version that it really requires even experienced Perl programmers to go back to square one.
I believe there is extensive remodelling called for by the current Perl6 gameplan, although I think this will further distance Perl 6 from Perl 5 programmers, and most likely some of them will simply move on to other languages which don't seem like such moving targets (although with Python claiming a signficant rewrite in the future, there may not be much of a safe harbor outside of yuck Java).
I too used to fight tooth and nail against co-workers to prove that Perl really wasn't that bad. Having been forced to code in other languages at that job though, Perl is starting to look as bad as everyone was saying.
pity.
Q: What do you think about American Culture?
A: I think it's a good idea.
(adapted from Gandhi)
100 < -s $filepath <= 1e6
is essentially equivalent to:
(100 < -s $filepath) && (-s $filepath <= 1e6)
except that the `-s $filepath' only gets evaluated once. We're supposed to be Wow! Neat! about that.
On the other hand, we are also told:
which may be cunning, except of course with wow neat multiway comparisons it is equivalent to ($a == $b) && ($b != NaN), which doesn't do the advertised job.Finally, lest we might suspect operators like < and <= are treated differently from == and != for purposes of this `feature', we are told:
Predict the ultimate (though probably not imminent) demise of multiway comparisons in Perl 6.
Perl5 tried to fix a lot of Perl4's limitations and turn it into a modern programming language, but the end result is rather iffy. It's a language with a bizarre object system grafted on top of the module system and lots of syntactic and semantic pitfalls for the unwary. Still, Perl5 has great libraries and a fast implementation, and I knew most of the weird features from Perl4. So I still use it, particularly when it has a library that does something I need.
With Perl6, the fun seems completely gone, and the endeavor just seems bizarre. Does a language really need a -//=- operator (I'm not making this up) for default-assignment-that-only-interprets-undef-as-u ndefined, as opposed to the existing ||= operator, default-assignment-that-treats-undef-0-and-the-emp ty-string-as-undefined?
My enthusiasm for Perl5 was already dampened, although I have probably written thousands of Perl5 scripts and CGI scripts over the years. But I think with Perl6, I'm going to jump ship. Perl isn't the only game in town anymore, and several other scripting languages now also have good libraries and are widely used.
The only thing I still Perl for is as a heavy duty scripting language. From what I can see Perl 6 may not correct the deficiencies of Perl 5. Perl 6 was also supposed to take away Perl's version of DLL hell. This library compatibility problem of Perl is the number one reason I switched to Java.
For the "real" applications, I discovered the readability of Java (and to a lesser extent C++) far outweigh the performance Perl *USED* to have over Java. Since the majority of my development consists of web-based apps, Resin and Apache running on Linux have no noticable speed disadvantage to modperl. And the readability and maintainability of the code is where the real benefits exist. Now the Perl fanatics will say something like "it's still 1% slower than modperl..", but the bottom line is maintainability and readability is worth the one or two percent differential.
My experience with Perl is that the larger the project the more spagetti code you get. I still use Perl to do quick admin type of scripts and utilities because most shells don't always have the power that I need.
Perl has its place but the readability of Perl is a definite minus. I remember the hours/days our Perl junkies used to spend trying to fix a problem that existed in a line or two of a Perl script. The writability was a plus, but several months later when business requirements changed,
trying to update the script so that it worked correctly was nothing short of a miracle.
I hated Perl4 because it was inconsistent and didn't make sense. Perl5 was MUCH better because there was a certain consistency and a lot of clever things were put in (example, using {} to create anonymous hashes is clever because {} reminds you of hashes, the => is a stringifying comma substitute which makes hash defs look good, but can also be used for other things, etc).
Now Perl6 almost goes too far! Some of that stuff is handy but excessive. Let's see..
// .. okay that's cool. I've wished for something like that many times. I hope it finds its way into Perl5. I also hope it comes in a unary version as a shortcut for defined() so I can write fun stuff like:
or^ .. uhh.. handy, but ugly and makes me think of pascal. There must be a better syntax. What's wrong with some kind of multi-argument "map" operator? And is this:
somehow better than this: ??_ underscore .. okay now this is too much. Just because dot is "industry standard" for dereferencing doesn't mean perl has to have it, the "->" syntax is clear to me. And now I'd have to put spaces around _? Yuck. Of course with the cool new scalar interpolator $(..) for strings I probably wouldn't use it as much, but still, that's too major a change I think.
The unary underscore to convert to strings is silly. The article even says that _@thingy is the same as "@thingy". Well, duh, then let's use the second one, anybody off the street could tell it had something to do with strings, but what does the first one do? In my mind, underscore means "placeholder", not "string". Get rid of this syntax please, put it back the way it was!
To add insult to injury, the article says that dot is optional/uneeded in many places except function calls. So they'd take it away and then make it mostly optional?? Why??
That whole thing with the Sigma summation operator was just ugly voodoo, especially the bit that specifies the precedence. Bleh, what's the point??? He defines the Sigma with a certain precedence, but then doesn't even make use of it in the script example. If you need special precedence, use parantheses!
What is a "higher-order function"? Apparantly it's an anonymous subroutine with placeholder variables...the syntax doesn't really make sense, why "$^"? That makes me think of the hyper-operators. Probably a "&" should be thrown in there someplace. How about beginning those variables with "$&"?
I think relying TOO much on punctuation is a bad idea. For one thing it becomes harder and harder to scan a script quickly looking for things. And if you start overloading symbols with all kinds of context-dependent meanings, it becomes impossible to remember what it means. For instance, using "+" to convert strings to numbers sorta makes sense, because plus has something to do with numbers. But it has nothing to do with converting strings to numbers, so people will probably forget what it means. I'd much prefer a "num" bareword.
Oh well, some cool things, and some things that make me wonder why bother? I think I'll stick with Perl 5 for a while (but I'll take the // operator in Perl 5).
Changing the meaning of the dot operator is pretty big, though. It'll take a while to get used to method calls without -> and concatenation with _.
Using a leading underscore as a stringification operator could be advantageous... especially when dealing with an expression that returns a list, like a hash or list slice, or a method call. There are lots of things that aren't easily interpolated into a string. Give that one a chance.
(And, yes, I understand typeglobs. :)
Higher order functions are functions that can be treated as values... passed to and from other functions. They're terribly handy.
I also wouldn't worry about excessive punctuation. If someone else doesn't already have plans to provide English.pm for Perl 6, I'll do it. It'll probably end up being handled the same way Ruby does it. Internally, everything's an object, and you can access regexp captures through methods or regexp properties, but there are also optional magic punctuation variables available for Perl afficiandoes or shortcut gurus.
The really big changes are the dot and the underscore. Most beginner and intermediate Perl hackers aren't going to notice many of the other changes.
how to invest, a novice's guide
This new language frightens me. I say that as a perl coder who plays with the old version for a living and makes it do some funky tricks already. Perl 6 is skating worryingly close to the edge at which line noise parses and runs.
There is no such thing as passing by value in Perl 5, and I doubt there will be in Perl 6. In Perl 5, @_ gets refs to the arguments. The common practice of saying:
...
sub foo {
my ( $this, $that ) = @_;
}
 
isn't only to give better names than $_[0] and $_[1] to the arguments; it's also to get values instead of references.
Would $a ^+= @b do what I want?
i.e. $a is the sum of all elements of @b?