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.
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.
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.
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."
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.
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).
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.
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