Slashdot Mirror
Perl Is Undead
Ptolemarch writes At the Yet Another Perl Conference beginning today in Orlando, the first keynote squarely blamed Slashdot for starting the "Perl is Dead" meme in 2005. Let's be clear: if Perl was ever dead, it must now be undead. If you can't be at YAPC, you can still watch it live.
Whatever it is now, it should be dead. For the simple reason that Perl allows this kind of code:
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=( $m=(11,10,116,100,11,122,20,100)[$_/16%8])$t^=(72,@z=(64,72,$a^=12*($_%16 -2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h =5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$ d=unxV,xb25,$_;$e=256|(ord$b[4])
It doesn't have to be like this. All we need to do is make sure we keep talking.
some people still write new COBOL too
sure, can write good stuff with it, but it is passing
I don't think there's a second-system effect going on with Perl 6. Every two or three years some new team has come along and tried to implement it, only to totally fail and produce nothing usable. These people didn't implement Perl 5, so I don't think we can say that Perl 6 is a second attempt for them.
These Perl 6ers have just continually done stupid shit with half-assed virtual machines and intermediate languages, rather than getting real work done.
For fuck's sake, just look at the approaches that have always worked in the past:
- Perl 5 and earlier: An interpreter written in C.
- Python: An interpreter written in C.
- Ruby: An interpreter written in C.
- Lua: An interpreter written in C.
- Tcl: An interpreter written in C.
- PHP: An interpreter written in C.
- UNIX shells: Interpreters written in C.
The lesson should be crystal-fucking-clear: write an interpreter in C. That's all the Perl 6ers need to do, but for some reason they just won't do it.
No more Parrot. No more crap written in Haskell. No more stupid intermediate languages. The Perl 6ers just need to cut out the crap, and do things right for a change.
Most of the scripts/programs that I still use that are written in perl, truly are 'zombie processes', waiting to be put out of their misery.
the only permanence in existence, is the impermanence of existence.
I agree that this (truncated) example is terrible, but it's clearly obfuscation for obfuscation's sake. If you manually insert whitespace and newlines, the above example is easy to read except for a few deliberate obfuscation techniques like hard-to-follow operator chaining and nested assignment.
Most modern languages allow operator chaining, so things like "$t ^= $c ^= (...) " are not a problem with perl per-se. To make this more readable, all you have to do is decompose it into its component operators, following the rules of operator precedence: "{ $c ^= (...); $t ^= c; }". Most modern languages also allow nested assignment, so things like "if ((@a = ...)[20] & 48)" are allowed. Again, if you want to make it more maintainable, you can write it as: "@a = ...; if (@a[20] & 48)". Once we've removed those types of issues from your example, you're only left with issues related to lack of pretty-printing (includes the fact that nobody but Larry Wall truly understands perl's operator prededence rules), and some surprising things that happen because of implicit variables and dynamic scoping.
IMHO perl's greatest fault is that there is no round-trip-capable pretty-printer. If Perl shipped with a pretty-printer, and if that pretty printer included an option to explicitly parenthesize operators and insert omitted implicit variables, then people could use the tool to read and understand poorly-written perl-snippets, and the only real fault left would be the fact perl uses dynamic scoping by default.
One of the biggest problems with Python is that you can't email people code without it fucking with the formatting.
Any language design that relies on whitespace as being important is brain-dead.
Most of the time you're maintaining code you're maintaining bad code, though, and it's pretty rare that I run across a perl program with "use strict" turned on. But if I don't see it, I at least know what I'm up against. The newer languages need a similar "A bad programmer wrote this" flags.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Comment removed based on user account deletion
The people of Perl 6 are tolerant and accepting.
That's quite a broad brush you're painting with there.
Discrimination and hatred have no place in the modern world.
Agreed.
Perl 6 is about love, care, tolerance and friendship.
Now I think you're getting carried away... I thought it was a multi-purpose scripting language, not a big hug.
All traction was lost when Perl 6 became some amorphous goal, and nobody gives a damn any more. Personally, I think this is a shame -- but I've found Python and Ruby to be more-than-acceptable replacements. (Honestly, I think Ruby is the cat's pajamas, aside from regex speed on 100+ MB logfiles.)
So... does Perl wish to make a comeback? It really would be fairly easy:
1) Have Larry Wall take the reins well-and-truly again.
2) Give a timeframe for a for-real reference release of Perl 6. Not this sort of wish-wash "everything that says it's Perl 6 *is* Perl 6" thing. Choose *one* of the projects, and have it be the reference against which all others are measured.
3) Give direction and make it public. While associated clearly with #1, merely taking the reins won't do the job -- it has to be clear that Perl is *GOING* somewhere, and not just stagnating. And this has to be made known.
There are plenty of sysadmins who learned Perl when it was 5.x, and who have fond memories of it. Give them something more than memories to work with, and you may well go somewhere. As it is? I just couldn't be bothered to care. Gimme Ruby.
Perl 6 ...
Anyone else miss Perl 3 & 4?
Personally, I think Perl jumped the shark at Perl5.
As a better awk/sed/bash, I think I've never seen a tool as good as Perl4. But then Larry decided it had to one-up C++ in some sort of "what's the worst possible way to glom on some confusing fake-OO-wrapper around a language that's main strenght was being not-OO" contest.
If knocking braces off is "halves your work out of the box" then you are programming wrong.