Exegesis 3 Released (Perl 6 Examples) 85
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.
"working" examples (Score:3, Funny)
How can these be working examples when Perl 6 does not even exist yet?
Re:"working" examples (Score:2, Informative)
man (Score:2, Insightful)
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.
Admittedly the syntax is getting out there (Score:3)
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.
MOD THIS UP! (Score:1)
pity.
Re:man (Score:1)
More and more, Perl seems to resemble APL.
The emphasis on one-liners, TMTOWTDI, VHL monadic or dyadic operators, and reputation as a write-only language.
Larry Wall seems to have the goal of evolving Perl into a natural language or something equally complex.
Non-ASCII characters seem like a mistake to me as well, Unicode support is far from universal and it introduces unnecessary complications, especially for parsing Perl programs.
At the very least, there should be some alternate form of ASCII representation, possibly similar to Morgan Stanley's A+ [aplusdev.org].
Most modern APL style languages use ASCII characters for precisely this reason.
If using a tool is too complex, people will look elsewhere.
Re:man (Score:2)
Perl is a language that stood out because of the way it came to be. It differs from others by the careful balancing of ideosyncrecy and shameless emulation. The guiding principles were always practicality ( making simple things easy) and linguistic metaphors ( $_ means 'it', @ is to $ as plural to singular, : is like the adverbial 'ly' in english, etc.).
The fact that Perl succeded so well is proof that these design principles were right, despite the legions of naysayers.
Now Larry Wall leads Perl into the unknown by trying a bolder iteration of the same principles. He may well fail, either because the world of computing has changed or because these principles have reached their ceiling. But he is doing the right thing. Innovation doesn't come from trying to keep everyone happy.
To all those naysayers, Perl 5 is there, stay with it and be happy.
Re:man (Score:1)
Still prefer scalars, I do. (Score:2, Interesting)
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.
Not by value... (Score:1)
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.
Re:Still prefer scalars, I do. (Score:1)
Nope, it's by constant reference (and appending an 'is rw' to the end of the variable name makes it non-constant reference).
horse? (Score:2, Funny)
Re:horse? (Score:1)
Some thoughts (Score:4, Insightful)
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 .
Re:Some thoughts (Score:5, Insightful)
Bingo. Perl has very malleable syntax, which is perhaps not as flexible as, say, SML, but still has had a philosophy of letting you rewrite good chunks of perl in perl. Perl6 is just adding to the potential confusion, letting you write code as twisted and evil as you want to. Besides, if you tend to write mathematical apps commonly
Re:Some thoughts (Score:3, Insightful)
Re:Some thoughts (Score:2, Interesting)
Well I'm also sort of leary about any Perl article that goes into talking about "Schwartzian Transformers". Say what?!
I think Perl 6 is starting to make me paranoid.
Re:Some thoughts (Score:2, Interesting)
Well I'm also sort of leary about any Perl article that goes into talking about "Schwartzian Transformers". Say what?!
Aw, c'mon. Schwartzian Transforms have been around for as long as Perl 5 has been.
my @output =
map { $_->[0] }
sort { $a->[1] cmp $b->[1] }
map { [$_, expensive_func($_)] }
@input;
A sort between two maps. Doesn't get much simpler than that.
Re:Some thoughts (Score:1)
Re:Some thoughts (Score:2)
Which is why I finally had to back away from Perl. Perhaps there are programmers who can deal with this kind of complexity and non-linear logic. I'm not one of them.
Well, I'm a special case -- I'm a lousy programmer who mostly makes his living documenting other people's code. But judging from the code I've read, a lot of other Perl programmers don't think that way either. They treat Perl as kind of a super-BASIC, and their code is full of hand-coded loops and other stuff the fancy Perl idioms are supposed to replace.
i hold my breath and... (Score:2, Interesting)
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
Re:i hold my breath and... (Score:2, Informative)
Use closures. Run perldoc perltoot , and then read the section Closures as Objects
Re:i hold my breath and... (Score:1)
i have and i do, though closures are somewhat slower and larger than blessed hashes. it would be nice to be able to effectively local'ise the accessibility/visibility of member objects to inside a class using a perl keyword, rather than changing an class' implementation, ie, using keywords like 'private', 'public', and maybe even 'protected'. likewise, it'd be nice to overload the 'my' and 'our' operators to mean the equivalent of my == object declaration, our == class (ie: 'static') declaration. i have to say i really like the look of:
class Me {
# class data
our public $Class_Total;
our private $Class_Increment;
# object data
my public $total; # this.{'total'}
my private $increment; # this.{'increment'}
}
dirty
Unfortunately you will probably get your wish (Score:3, Interesting)
Re:Unfortunately you will probably get your wish (Score:2)
Re:i hold my breath and... (Score:1)
wow, perl meets apl (Score:4, Interesting)
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?
Re:wow, perl meets apl (Score:3, Insightful)
I'd like to see something like this:
That makes sense to me at first glance..or maybe better something like this: which would be like taking one element from each list and passing them to the "subroutine" in the block. Anything would make more sense than ^- !Re:wow, perl meets apl (Score:2)
Re:wow, perl meets apl (Score:1)
@a = @b / @c;
now there you've got potential to extend the language.
My head... (Score:1)
I want to understand this, I really do, but I just don't. Sorry, Larry and Damien, I tried...
I wish Ruby would have come out in 1995 (Score:2)
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.
Perl6 multiway comparison requires telepathy (Score:3, Insightful)
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.
Re:Perl6 multiway comparison requires telepathy (Score:2)
Re:Perl6 multiway comparison requires telepathy (Score:1)
Hadn't noticed that `if ($a < $b < $c) { .. }' is
actually illegal in Perl 5. Would've expected it to follow C, where you can be sick with like `int cp = (c!=0); if (a <
b <= cp) { .. }' to say `a less than b implies (in the sense of modus ponens) that c is not zero'.
But, Perl didn't do that, so you can't say twisted stuff like that, so there's no loss to adding multiway comparisons to Perl 6. Wow, Perl is actually cleaner than something!
Re:Perl6 multiway comparison requires telepathy (Score:1)
Actually, it does, as Damian pointed out to me [develooper.com] when I asked about it [develooper.com] earlier today.
from the baroque to the bizarre (Score:2)
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.
yeesh, too much! (Score:2)
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).
It's Really Not Bad (Score:2)
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.
Scary (Score:1)
reduction with ^ (Score:1)
i.e. $a is the sum of all elements of @b?