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."
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
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.
Hmm PHP. Talk about a language that breaks things between versions! #include behavior was changed between two revision numbers!
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