Slashdot Mirror
Apocalypse 5 Released
Simon Cozens writes "The Apocalypses are Larry Wall's explanation of the design of Perl 6. In Apocalypse 5, Larry turns to redesigning regular expressions. He set out to intentionally 'break' a lot of the regular expression culture we're all used to, and these are the results - and they're mindblowing."
Why do we always have to keep changing regex [and many othe things]. Isn't enough that we have to learn one format for almost every language. Sure, there are perhaps easier ways to express certain logic situations, but over all, do we /need/ another regex format?
He set out to intentionally 'break' a lot of the regular expression culture we're all used to
I hope he can break "Don't go there" and "Talk to the hand" There are many others, but this would be a good start
---"What did I say that sounded like 'Tell me about your day?'"---
So, when Perl 6.final is released, will the release notes be called "Apocalypse.Now"?
--
If you moderate this, then your children will be next.
The new perl 6 regexes are crazy. They seem "weird" and awkward compared to the perl 5 ones... but then again I thought the same when I started learning perl (at version 5.6).
/x to allow for easier reading of code and allow for comments inside the regexes. Some of the new features make the regexes a bit longer to type, but in general they are significantly smaller. There's also a much better and more consistent use of different types of brackets. Not having to look at the end of the regex to understand the whole thing is going to be great. I hate having to skip the regex to look a the flags first.
:o) I also wonder what the speed of the interpreter is going to be like compared to perl5. Hopefully faster :o)
A lot of this makes a lot of sense however, especially the default
Brilliant I think. I can't wait for it to come out. I hope they make a perl5->6 translator though
Good job Larry, Damian et al.
Something to make the code that little bit more unmaintainable. That keep those PHP whores on their toes :->
For instance there is now OO COBOL but the only people that use it are COBOL programmers who are stuck, perhaps because of their company's dictates, perhaps by choice, with COBOL. In the same way perl may be heading towards irrelevance wrt "mainstream" language. I've written commercial perl in the past, it was a pain then and it's still a pain now. The thing is that now there are alternative languages in the same space (python, ruby etc., php for web side) that do the "perl thing" better than perl.
Perl was great, it introduced many people to programming, just like COBOL did. But now it's time to move on. To move on to languages that learnt from perl, that improved on it, that don't have to drag around a syntax and culture that values neat tricks and trying to guess what the programmer really meant over providing the needed building blocks and letting you build code that does what you say, not what it thinks it heard you say. Or even, dare I say it, to move on to languages outside the perl family for some programming and choose the right tool for the job for a change.
I'd prefer to think of this as provocative rather than a flame, there is a difference you know.
development.lombardi.com
Wherre I work I'm almost the only non-cobol programmer. We are developing modern data wharehousing solutions, for huge amounts of data, using mainframes , DB II and COBOL. /Java 1.4 system.
Cobol has been arround for such a long time that it is known good solution, the same thing applies for Perl and CGI.
Would you trust you life on an App writen in VB, or a large C++
C++ is to complex for everyday usage, sure it's got great performance and flexability, but one of it's downfalls.
VB is just a glorified scripting language, with loads of bugs and much crapness, i should know i've been [had to] using it for 7+ years.
Java just insn't mature enough for anything decient.
So were left with Perl, Cobol and the like
thank God the internet isn't a human right.
Can I suggest that you read ...And Now for Something Completely Similar by Damian Conway.
It's just that version 1.4 has just started to add maturity to Java i.e 1.3 java was a bit hmmm.. imature, 1.3 fixed a lot of things, 1.4 has beefed Java up a lot so 1.5 or so would be Matureish. ie. Most of the bugs and incosistancies should be ironed out.
The same thing is happening with linux, 2.6 kernel is starting to get maturity features in it, so by that reason 2.8 or 3 should have ironed out the bugs/inconsistancies in the maturity features.
(linux is however great for custom applications)
thank God the internet isn't a human right.
So now Perl regexs are going to be completely different from every other language and more complex than ever... wonderful.
I certainly hope that someone is going to be maintaining Perl 5. I certainly cannot see the Perl community moveing en masse to Perl 6, or whatever they decide to call it.
Conformity is the jailer of freedom and enemy of growth. -JFK
...is if Cmdr Taco is going to upgrade slashcode to Perl 6 and what he thinks of all this re-write of Perl.
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
...that the active half of this Perl (5) powered site is completely screwed up at the moment? Improve languages all you want, it's still no substitute for decent sysadminning ;)
However, I would like to think that there is some happy medium between those two extremes. Coming from a C background, Perl has historically treated regexes as servants. True, Perl has treated them as trusted servants, letting them move about in Perl society better than any other C-like language to date. Nevertheless, if we emancipate regexes to serve as co-equal control structures, and if we can rid ourselves of the regexist attitudes that many of us secretly harbor, we'll have a much more productive society than we currently do. We need to empower regexes with a sense of control (structure). It needs to be just as easy for a regex to call Perl code as it is for Perl code to call a regex.
We've been discriminating against the poor regexes for too long. We need to represent them who are unable to represent themselves. Stop Regex Exploitation Now!
I hope somebody's going to write some automatic conversion tools because going back to one even a few days later is a hairy experience indeed.
Guess you haven't seen txt2regex? It doesn't support Perl 6 yet - but it supports about 20 languages at this point so I think you can reasonably expect to see more in the future :-)
Cheers,
Toby Haynes
Anything I post is strictly my own thoughts and doesn't necessarily have anything to do with the opinions of IBM.
I've asked this elsewhere. Ruby was designed with respect to perl, but all the same keeping to the principle of least surprise (which perl does not adhere to). Now, with Perl starting to look like a grown-up, mature language, what will the major differences between Ruby and Perl be?
Stop the brainwash
He seems to be putting a lot of emphasis on embedding Perl inside regexps; while this will make them more powerful and allow you to do more complex things using them, it's increasing coupling between Perl regexp and Perl itself; I don't see the PCRE library and other similar libraries being able to keep up.
Although he mentions he wants regexp to be taken more seriously as a tool for other languages, increasing coupling like this would seem to be a very poor way to go about it.
The new-style regexp's reuse a lot of syntax from the standard regexps; the meaning of many common constructs have changed completely, but I can see it being difficult to actually notice the difference until you've already parsed part of it and gone "Uh?" a few times. And you're not just going to be able to forget about the "old-style" regexps.
Personally I can't help but feel that Larry is the wrong person to make such large changes to the core regexp concepts; they're used heavily in languages other than Perl, but Larry is natuarally doing it in the context of Perl and to hell with any other language. For something so otherwise platform independent, I think this is a bad way to go.
my ($x) = /(.*)/ my $x; / $x:=(.*) /
# may now bind it inside regex
This is a feature that I hope is carried over into the scripting languages I use (PHP, Python).
My first impression was that they may as well embed AWK in the regex engine.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Larry is mistaken if he thinks this is going to be in any way benefitial. All this does is change the syntax and add yet another layer of difficulty to what is already a mess.
1) This isn't any easier to read. I've been programming since 1985 and went through more programming languages and idioms than I can recall, and regex is the only system I have attempted to learn and met with complete failure. If regex is to be redesigned (and despite my inability to learn it, I don't think it should be broken), at least make it comprehensible.
2) This creates a giant rift in regex, with multiple, mutually incompatible versions across operating environments. What works on system A may not work on system B. Some vendors may choose to implement these extentions, and some may not. This is a disaster. Though regex may not have been completely compatible across systems up to now (and to be honest, I have no idea how compatible the various regex implementations are), adding yet another dialect can be nothing but bad.
this guy has been doing some interesting work on the regex engine. he's added functionality so that you can have recursive regular expressions without the clumsy postponed subexpression ("(??{...})") mechanism. on the one hand, it's far less readable that way, but on the other hand, you don't have to predeclare a variable for every production rule in your grammar.
and the current system is even more convoluted since the postponed subexpressions are evaluated in the environment in which they are checked, not where they were declared. this means that all variables referenced when you built the regex have to be in scope when you use it. that's a restriction i'd like to do away with, although i'd rather see it done by making postponed subexpressions support closures.
as i recall there's also an rfc for perl 6 on the perl site to make a stack-based regex engine rather than stat-machine-based, so that it could support CFGs, but i don't think it specified how it would work syntactically.
#define F(x) int main(){printf(#x,10,#x);}
F(#define F(x) int main(){printf(#x,10,#x);}%cF(%s))
I've read comments by Larry to the effect that Perl is great at writing lexers but not parsers. If you look at some of the later examples (around page 11) it's clear that he's trying to make Perl regexes powerful/clear enough to parse Perl. They remind me of yacc/bison, which makes sense.
I still disagree with the parent flame, but I think Mason really does a service handling at least the CGI tasks. On the sysadmin front, I have no idea, since Perl is my hammer :}
What is your Slash Rating?
Yeah, and by the last few Apocalypses, Larry will have shaved his head and gained a lot of weight, and he'll sit in the darkness muttering half-profound, half-obvious statements about language design. And Damian Conway can play the Dennis Hopper role, the drugged-up photographer/court jester :) But who gets to be Marlowe/Willard?
:)...
ObDisclaimer: I really like both Apocalypse Now and Perl, but they seem uncannily similar now that I think about it -- that great epic attempt to render the human condition, that falls well short (but at least tries
deus does not exist but if he does
Provoking a flamewar is still considerably different from provoking thoughtful discussion. Saying "Perl sucks, let's find a new language" is a flame. Saying "I think language X better serves the purposes Perl addresses" is thoughtful and provocative. See the difference? Unfortunately, the parent thread came down on the "Perl sucks" side of things...
What is your Slash Rating?
As a Java geek, I was going to reply to your post much in the spirit of this thread, but you are completely right.
Freedom is the freedom to say 2+2=4, everything else follows...
Just get the damn thing written, make it flexible enough for us to rewrite perl in perl, and kick this lazy-ass camel out the door before my grandchildren ask me when perl6 is coming out!
... great, so move on already, regexes are not the final word in pattern matching.
I don't want more powerful regular expressions. I want a more powerful pattern-matching syntax, one I can compile down to an opaque object with a bit of syntactic sugar, then use in place of a regex. I want a parser sub-language like SML or parsing primitives like haskell. Regular expressions are now turing complete thanks to perl
And what's more -- all this you're doing Larry, it's anti-hacker. It's top-down, it's engineered, it's ivory-tower theory that might sound neat and no matter how zany your presentation is, you are living in the rareified atmosphere of a language designer, and now you are starting to think that way, dispensing wisdom on The Right Way To Do Things from on high. Yes, inventing Just The Right Way to give people 1E+255 ways to do things is still looking for the perfect that's the enemy of the good, because once we have the foundations to improve on perl6, we will do it, but only if we have something to work with. It doesn't all need to be done up front.
Your extended regexes can be done as a library solution. Stop ending the world and start living in it.
I've finally had it: until slashdot gets article moderation, I am not coming back.
If Perl 6 isn't backwards compatible, they do the same Microsoft does with Visual Basic .net: make programmers switch to other tools.
A good language can introduce new features without changing the basics. This is why PHP got so popular so fast.
What's the point? Java, C, C++, COBOL, Mantis, VB, you name it...even Ada. The point is not whether something is bad because it has become such a widely used language that it has legacy code dating back to a few generations, but whether it serves a useful purpose.
/.) will argue that COBOL or FORTRAN or what have you is obsolete because it isn't the latest, sexiest language. That's not a valid argument. COBOL finds uses in every day environments that maintain our IT infrastructure...in places most people wouldn't even notice.
People (especially on
The same thing goes for Perl. It may not have the newness of Ruby, and it may have code dating back to release 4 on web servers the world over, but that doesn't mean it is dated or that it is time to scrap the language.
One of the nice things that Perl has going for it is the modularity. You go to CPAN, download a new module, and all of a sudden, your toolbox has a whole new tray of useful tools that save you from re-inventing the wheel. These tools let you perform system administration tasks, provide CGI applications with ease, or handle back end tasks. It is more powerful than shell scripting and more flexible than C/C++/Java.
As much as I'd like to think you're being reasonable, it seems to me you've made a blanket, baseless statement. If you want to provide some evidence that your point of view has merit, I'm sure we'd all be interested. In the meantime, you're likely to be dismissed as a troll....
What is your Slash Rating?
So Perl 7 will be the last major revision. In fact, Perl 7 will be so perfect, it will need no revision at all. Perl 6 is merely the prototype for Perl 7. :-)
The biggest problems with Perl are its uglified, glued-on OO capabilities and its general legibility.
You can do some decent OO with it, yes, but you'll do some language hacking to get there. You can also write some nicely legible Perl code (I try to), but most people don't bother.
Perl5 is going to be around for a long time... a whole lot of code has been written in it, and much of that code is critical due to Perl's usefulness as a glue language and for web programming. So a lot of people are locked into Perl5, at least, for maintaining existing code.
But Perl6 is going to address some of the major problems with Perl5; I expect its adoption rate to be high.
Quote from Apocalypse 5:
Phil
I heard of it back in 2000, and nothing cince.. one of the core developers was working on a mini-perl for embedded systems and I have bee neagerly waitong for it but ..... nothing.. no small perl that takes up very little space...
Anyone have any clue as to it's progress?
Do not look at laser with remaining good eye.
For what I've read in the past, it has always been the plan to ensure backward compatibility by defaulting to parsing Perl5-style syntax. Said another way, one must explicitly specify that a program is Perl6. This is a good thing, and a feature I'm counting on. There's quite a bit about Perl6 I'll probably not use very much. All I really need Perl for is a glue language. In fact, if I were to replace some chomp()'s with chop()'s most everything I've ever written will run under Perl4. I'm not quite as l33t as some although anyone can read my code. Needless to say, I don't post to perlmonks.org very much. :-)
I don't think Wall will make everyone go back and re-write old code. That would be a grievous mistake.
(Note: I haven't read the latest Apocalypse because perl.com seems to not be responding. If Wall has said anything to the contrary, then things have changed from what I've read in the past.)
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
It's not that perl is akward. It's a language that lets you code in a number of different styles. It gives you the freedom to code your own way. This does reduce readability, but it greatly increases speed of coding. If others need to read your code, just set up style guidelines.
I use perl for just about all scripting I do on my system. Just a moment ago, I had to read an html file over http, but there were no line breaks. I just needed to get one piece of information, so I did this:Sure it's unreadable, but it did the job. If I'd been writing CGI, I would've been more verbose since terse perl code can be difficult for even the author to understand by reading it.
perl gives you lots and lots of freedom. This is not a bad thing, but it is dangerous. Other languages force you to work in one way.
Think of a bike. A bike w/ trainig wheels makes it hard to fall over, but your agility is reduced. perl has no training wheels by default. You can write really nasty code that works but is unreadable. Perl is anything but limiting.
If you want more structure to protect you from yourself, try running perl the -w option and put "use strict" in your scripts. If you want pretty built-in identifiers, try "use English"
I've been coding for so long that the restrictions built into many other languages just get in my way most of the time. I like the way perl never gets in my way.
t'nera semordnilap
I can't get to the apocalypses, or anything on perl.com, from two different sites. Is there a mirror anywhere? Is nothing sacred?
Ahem. *cough* There's nothing useful in this Apocalypse. Go read something else, so I can read it.
Maybe the state's highest function is to grind out insoluble problems. (Zelazny, Hall of Mirrors)
You're totally right, and the perl community agrees with you. For example, on page 3 of the apocalypse, Larry Wall states that perl has too much historical baggage. But that's exactly why they're redesigning it for perl 6.
It's up for debate whether python, ruby, PHP do perl better than perl, but it's true that they all took the good things out from perl5 and left out the bad things. They're doing the same with perl 6. In addition, some extremely bright people are working on it that have had a lot of experience with designing and extending languages. If you read the apocalypse, it's amazing how Larry Wall has shed all of his preconceptions and leanings towards older versions of perl. They're taking the good stuff out of every language and fusing it together in a very colaborative way. And I'm convinced that the resulting perl6 will be a language to be reconed with.
I have fought my way through basic Perl Regexes and for some strange reason have come to like the language for it's sheer obtuseness. The person who made the crack "Perl - $Just @when->$you ${thought} s/yn/tax/ " wasn't joking.
/[bla]*/ or /\Qbla\E*/ or something completely different?).
What I see as a real problem for Perl6 and Larry's vision is that other languages have, as he noted, copied Perl5 Regexes and it has more or less become a standard as it is. Those languages are not going to change their implementations of Regexes in a hurry, especially Java which has just aquired it, and this will lead to a schism because, as powerful as Regexes are, they are not for the faint hearted and no one, and I mean no one, wants to learn two different ways of doing them.(Do I use
I can almost guarantee that this is going to hurt the Perl community because many will simply stay with Perl5's way of doing things because of compatibility and habit and I think Perl6 will have a hard time finding a large audience.
I know it's too late to convince Larry otherwise, but I think he should have left things the way they were in the Regex world. My analogy is to human languages. I learnt German years ago, which is more complex grammatically than English but at the same time much more structured and with far less exceptions. None the less, an amazing amount of people speak English and like it because of it's amazing flexibility and ability to enable even a poor speaker to be understood, despite thousands of exceptions in spelling and grammar.
I consider myself a hard-core Perl regexp user and these changes look pretty cool and very appropriate. They fix a lot of the annoying add-ons in Perl's current regexps (if you've ever written a big fat regexp with lots of (?..) stuff you know what I mean). Being able to easily name captured text is probably the most useful feature. In fact Perl 6 is starting to look pretty nice all around. I'm still going to have a problem with "->" becoming "." and "." becoming "_" but I guess I'll survive.
What would REALLY be cool is if I could use some Unicode characters (for instance from the "General Punctuation Block") as the regexp metacharacters.. I didn't see anything about this in Larry's (very long) document, and I'd imagine it wouldn't be very popular since many of those characters look too much like the ASCII versions, but it would be useful.
One thing that strikes me as interesting: languages like PHP and Ruby have inherited features from Perl (for instance PHP has a "Perl regexps" feature, and it uses "." for string concat).. will these languages change so they can be more like Perl6?? Otherwise I think that would leave PHP as the only language where "." is string concatenation (yeah I'm really hung up on that dot, humor me).
Looking forward to Exegesis 5.
Reading through this Apocalypse, I gained two strong impressions:
2. It is going to be a lot more manageable for me to program a parser I need in Perl 6 than it has been in Perl 5, because (i) regexes can now be laid out readably and (ii) clean reentry into Perl for stuff that is better done in Perl than in regex.
1. For all the common little applications of regexes things are going to be much the same or easier.
I suspect a lot more than me struggled to really get into some of the kludges added in Perl 5 in an attempt to provide useful functionality, so the Perl 6 approach of being willing to break backwards compatability where appropriate is going to produce a language which is much better while still being unmistakably Perl.
One key to all this is that Perl 6, through its regex parsing power as much as anything else, will be able to seamlessly deal with Perl 5 syntax when you need it to.
-- Our systemic servants do not good masters make.