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
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.
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.
Perl IS awkward and crazy. I've never understood the attraction to it. The few times I've had to dabble it in, it's just been frustrating, limiting, and ugly as hell. Bleh. I wish someone could explain it to me. I've had to do tons of scripting things, and frankly, after experiencing a ton of them in short order, I'd rather use the loathsome Vbscript crap than Perl. I once heard Perl described as a "write-only" language because it was so arcane and inscrutable. I'm not even sure about that. It just sucks.
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.
Think of Perl 6 regexes as something like a cross between traditional regular expressions and BNF grammars with hooks for good Perl integration.
That makes them weird, but it means that when your problem gets a little bit beyond what is doable with a traditional regular expression, you don't fall off of a complexity cliff. Instead of the current situation where regular expressions are great on small problems, then fall apart when you (say) want to check that parens are balanced (that one is doable in Perl 5.6, but not easily), they will scale anywhere from the kind of tokenizing that people currently do up to and including parsing something as complex as Perl.
And the ability to do this will be tested in the best "eat your own dogfood" manner by actually implementing Perl's grammar as a regular expression!
Quote from Apocalypse 5:
Phil
I really don't understand your point. I program in Perl since perl4, and I have always considered it:
* Ultra-good awk replacement, for one-liners
* excellent language for scripting, going where m/[ba|c|k]?sh/ can't go.
* (since perl5) nice OO-language for building GOOD programs, acessing databases, generating XML, HTML, and any-other-format stuff.
* it's got GOOD huffman encoding (things you do often are concise), and I hope it will become even better in perl6.
* it's NOT AT ALL write-only. take a look at the CPAN modules. they are readable. i can read AND understand them, easily. try it out.
regards,
--H.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
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
In most ways, regexen will be less complex than ever, yet more powerful. Read Larry's rationale for changing them and let us know how he's wrong -- his reasons made a lot of sense to me.
The problem is that there is a shitload of utility and cgi perl that will be broken if the perl on the server is upgraded. In some cases, like at ISPs, the code belongs to lots and lots of people that are totally unconnected from the administration of the site, so updating it becomes a nightmare. It's probably going to mean running two versions of perl (fortunately, perl doesn't take up a lot of space in /usr :-P ) and having to invoke it with version numbers... the normal messy drill.
I'm sure that the changes will be great, but it's hard to get too excited since, I must confess, the current system didn't seem so horrible to me.
5 years after it's released, every regex library in existence will be compatible with the Perl 6 way of doing things, so you might as well start learning them now.
Obviously I will learn the new syntax. And I will update my scripts to work with perl6. Etc. Etc. The thing is, it looks like perl is going to be taking back a lot of the time it saved me in the past. Once I've paid that cost I may be able to forget about it, but at this point I'm looking at having to add something really tedious to my to do list. And it's not like I have a lot of thumb-twiddling time I can steal from...
And here I thought Solaris was backward for not having embraced perl earlier than Solaris 8. Maybe it will turn out that they were [unintentionally, I'm sure] smarter than I thought...