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.
Congregation: $_
Pastor: $_.
It means that the uninfected humans have to shoot it in the head. Or stake it through the heart. And quickly, before things get worse.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
I don't think we're ever going to get as clear of an example of the second system effect as Perl 6. If you asked me back in 2005 if I thought it was going to take more than a decade for the next Perl version bump, I would have said no way. Now I'm wondering if Larry and company shouldn't just ditch Perl 6 and come out with Perl 7, that is basically just Perl 5 with some tweaks to make complex data structures less of a nightmare and better integrate the object model, plus some tweaks around the edges like the implicit /x switch on regular expressions.
I read the internet for the articles.
Maybe Perl isn't completely "dead", but it sure as fuck isn't as vibrant of a scene as it once was.
In the 1990s, Perl was THE BIG THING . It was cool. It was trend-setting. It was what let average programmers and sys admins become superheroes, and it let good and great programmers and sysadmins become ABSOLUTE GODS .
Knowing Perl was what got you jobs. Knowing Perl was what let you get the hard work done fast. Knowing Perl was essential. If you didn't know Perl, you were SHIT IN A URINAL .
Perl's got some fierce competitors now. Python can do everything Perl can do, but with a way cleaner syntax. Ruby isn't as capable as Perl or Python, but it has a religious aspect to it that makes some hipsters go absolutely batshit crazy for it. Perl just can't compete against them.
Yeah, Perl isn't dead, and there are a lot of people who still use it today. But let's not kid ourselves, it's not the 1990s. It's not the GLORY DAYS OF PERL , when it ruled the roost.
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.
Larry killed Perl, 14 years and counting and still no Perl 6 production release.
Meanwhile, Perl 5 being phased out of system building / admin tools and web frameworks. Even Perl 5 is dying.
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.
I've watched Perl die out over the past 15 years, and I'm seeing the exact same trend happening with Ruby. But with Ruby it's happening a lot faster. Ruby was adopted faster, and it's being discarded faster. People have lost patience with its shitty performance, and especially the shitty, shitty people involved with its community. Everybody is tired of dealing with shithead know-it-all Ruby hipsters who write horrible code. In fact, I would not be surprised at all if I'm still dealing with Perl 5 code 20 years from now, when nobody is still using Ruby, but everybody still remembers how shitty Ruby code and Ruby programmers were.
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.
So a few years ago, a bunch of people decided that there was no point in waiting for Perl6, and started back porting the features they liked into Perl5.
And to deal with the whole issue of the Perl6 syntax not being compatible w/ Perl5, they've added 'use feature' where you can tell it which features to enable. (or specify a version number to turn on a whole bunch of things)
So, you want postfix dereferencing? Then use perl 5.20, and enable the feature. (although, I believe it's currently enabled via 'experimental', so people know they're enabling a feature that may change)
Build it, and they will come^Hplain.
It probably has lost popularity because all of these newbies can't handle a more powerful language, and have to go back to basic like languages. I could do lots with little code in Perl. Python looks like a BASIC with some c and perl features.
Meanwhile, it's apparent that slashdot itself uses Perl e.g: http://slashdot.org/job_board....
Especially considering that the Linux job market is red-hot, and almost all Linux sysadmin job listings I see list Perl as a wanted skill. What exactly causes a language to be declared dead, anyway? Would you say that Fortran or Cobol are dead? Because they are still going strong in their respective niches.
Perl may not be "dead", but it's dead to me.
Does Deprecated mean ANYTHING? I used to write Perl programs, some 20 years ago, it was the thing. I wrote thousands of lines of KSH scripts too at that job. Perl it got replaced by a different tool, not that the new tool is better, but because it was new, just like KSH, CSH and BASH are no longer the tools of choice.
As you young whipper snappers exit my lawn, I offer you the following tidbit of knowledge : "Learn from what happened to Perl, and learn as many tools as you can. Where it's not the tools that make the programer good or bad, having the right tool in your toolbox can make a good programer a great one. Be the great one."
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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.
Comment removed based on user account deletion
But did Netcraft confirm it?
Personally I prefer "half-dead" or "quasi-dead". Does that make me a pessimist?
If you post as Anonymous Coward, don't expect a reply.
Comment removed based on user account deletion
Betting the farm on Parrot and then waiting *years* to start implementing the Perl 6 spec is what killed it. Besides, around these parts we wait for Netcraft to confirm. We haven't succeeded in killing off the *BSDs yet have we?
I am becoming gerund, destroyer of verbs.
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?
so I'm not surprised
Comment removed based on user account deletion
Comment removed based on user account deletion
Do the definitions of the terms involved stipulate that anything that was genuinely dead in the past, but is, in some way, no longer considered as dead anymore necessarily be considered undead?
File under 'M' for 'Manic ranting'
Perl has no reason to exist.
And no, not everything is a tool with the right application domain. Somethings are just plain trash.
mod_perl is a major issue for my company. Apache httpd 2.4 has been out for 2 1/2 years and there is still no mod_perl release. The release of Apache httpd 2.4 was no surprise. It was in beta as 2.3 for around 3 years before 2.4 came out.
There is something you can cobble together from svn, but the mailing lists are nearly dead and what you can cobble together from svn is not ready for production with Mason, at least from what I have experienced.
We're trying to get rid of all of the Mason and mod_perl stuff and replace it with something modern (PHP and Javascript frameworks), but it works acceptably with Apache httpd 2.4 for now. Perhaps this framework would have been updated if it weren't for Perl 6 becoming abandonware. Now that I'm thinking about Mason, that stuff is dead as a doornail. No activity there, either.
Perl is still good for what we used it in the pre-web mass commercialization days, throwing together a quick script, but Perl has lost its way otherwise. I would never deploy Perl with a new project on the web.
As for me, I'm a language generalist. I've been programming for closing in on 30 years, so I learn what I need. Perl has almost completely lost its utility and is becoming to me like COBOL or FORTRAN, just a niche language or something legacy you have to support.
Witch hunters see witches everywhere. All I saw up there might have had something to do with religion, but then again I don't do Perl.
Is it dead? Well, some quick scripting can tell us the truth, using Bash and of course Perl.
On my Ubuntu notebook and main machine:
sudo find /etc /bin /sbin /usr/bin /usr/sbin -type f -executable -exec file -b "{}" \; \ /script/; /(shell|python|ruby|perl|bash)/i ) {
| perl -MData::Dumper -nle '
next unless
if (
$types{$1}++
}
else {
warn "Other: $_\n"
};
END {
print Dumper(\%types);
}'
Output:
Other: a /usr/bin/make -f script, ASCII text executable
Other: a nickle script, UTF-8 Unicode text executable
Other: awk script, ASCII text executable
$VAR1 = {
'perl' => 283,
'python' => 104,
'bash' => 1,
'Ruby' => 3,
'ruby' => 9,
'shell' => 602
};
On a server:
Other: a /bin/dash script, ASCII text executable
$VAR1 = {
'Python' => 36,
'Perl' => 139,
'shell' => 267
};
Looks very much alive. Unless of course, Perl realized what it was calculating and cheated and made it's own numbers up on the fly...
Comment removed based on user account deletion
Comment removed based on user account deletion
If Perl really isn't dead yet, could we please put it out of its misery and shoot it? Then drive a stake through its heart, burn it, encase the ash in cement, and then bury it in a silver urn, just to make sure that it will never, ever come back?
... it's just the way people use it.
Perl was designed as a powerful, flexible, loosely typed scripting language for munging text files and streams, and that's exactly what it is.
It's great for those scripts that you write for a particular task and never use again after the few days it was necessary. It's also good for writing glue code on occasion, to tie the inputs and outputs of other applications together, and when shell scripting just won't quite cut it.
The trouble was that it was such a useful scripting language people started writing applications in it. Then they had to jump on the object-oriented bandwagon, which was done clumsily. Sort of like gluing a dog to your horse so it can fetch. And yes, it can be difficult to read, but it doesn't have to be.
Use Perl for the tasks it was originally designed for. If you're going to write real applications, use a more appropriate language. Don't kick your dog because he can't sing.
Never trust a man in a blue trench coat, Never drive a car when you're dead
"I don't think we should blame the language for being powerful enough that an evil programmer can be unfathomably evil, if it also enables a just programmer to be eminently understandable"
Why not?
Other language designs restrict an evil programmer to be only ordinary orc-level evil, and not unfathomably balrog evil.
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.
Just my personal experiences. Back in 90s I was working for BBN Planet, in a group monitoring network traffic within AS1 (which is *us*). I have inherited a set of tools written in Perl which I had to maintain. Prior to that I had some moderate experience with Perl. So, when I started going through the code, I've found it sufficiently obfuscated to give me a head ache. I guess my predecessor was one of those "Perl kids who like to have fun", not understanding that production environment means, among other things, readability and maintainability. OK, fine. Roughly at the same time the administrator of multiple machines running that code (I think it was Solaris) decided to move from Perl 4 to Perl 5. That broke lots of scripts. So I decided to save time, found out what the functional specs were (from those who actually used those tools) and rewrote lots of the code just from the scratch. Because I was under some serious time pressure, I didn't care too much about either readability and maintainability either. Just to get something out of the doors, and - let my successor suffer just as I did.
Well, BBN Planet, as we all know, is a history, but Perl, unfortunately, isn't. At least it is steadily loosing ground to Python and for reason. Cheers.
C written in BCPL
Later C written in B
Later C written in NB
Most popular modern C interpreter whose key components written in CIL (an artificial object oriented assembly)
2nd most popular modern C interpreter whose key components are written in llc & lli
Good comment. You should get an account.
Because of the lack of new projects being done with it. I can't remember the last time a [major] web site or web framework was done in Perl. It seems like the whole "ruby on rails" fad is over, but even things like Django (Python), .NET, Java, PHP, and even stuff like "Go" have stolen Perl's Thunder on the Web front.
Well what about as your standard workhorse for script kiddies? Seems like Python has cleaned Perl's clock. For me - I've been a die-hard Perl guy for 10 years. The past couple years, I've worked with many different technologies such as 2d/3d CAD projects, Blender (3d adnimation), Inkscape (2d illustration), GNU Radio, OpenStack (cloud), and even Amazon AWS [libraries]. You know what was the striking commonality to all of these? They were done in Python.
Tiny exception was in the last case (above - Amazon AWS libraries) had several different language options but had *NO* Perl options whatsoever. So the language that was once so revolutionary because of the abundance of CPAN libraries available for it starts to not have newer libraries built/ported to it. Furthermore, binding stuff to Perl can be difficult. So much so that most modern distros will make their own "Perl library" [RPMs] - and one of the reasons being is that a standard CPAN module installation won't work due to problems linking/binding/building across all these different environments with very different prerequisites. Most third party Python stuff I have acquired is most often "native python", and works across all types of exotic platforms - even on iOS and Google App Engine.
As for me - I had to switch away from my beloved Perl over to Python for the aforementioned reasons. There are still several things I miss very much - the abilities to so easily spawn and fork "helper" processes, the ease it which it integrates regular expressions, how it can manipulate files, etc. All these things *can* be done with Python, they're just integrated into Perl much better IMHO.
It seems like Perl 6 was supposed to use something similar to Java's "JVM" microcode interpreter. This could have been a possibility to run Perl in embedded sandbox-type environments (like parking meters and smartphones), but it never happened.
So, I do believe Perl is dead. I miss it for what it was, what it is, and what might have been!
Perl6 should be renamed Rakudo, it has nothing to do with Perl5, it's not even the same syntax!
and it's confusing for someone going from Perl5 to Perl6.
It's like if Python4 changed it's syntax to Ruby for "fun".
Perl6 should have been Perl5 with C++/Java style/syntax class period, no more @ISA=qw{}; crap.
We moved to PHP5, I only used Perl5 for quick scripts, prototyping, fancy bash on steroid, one liners and code generator nowadays.
Like OMG! http://preshing.com/20131219/b...
Perl Programmer for hire
Encourage? You fill up your shopping cart also while standing in the check-out line? It's the programmer who decides what to (ab)use.
Perl Programmer for hire
You mean books like Perl Best Practices?
Perl Programmer for hire
http://preshing.com/20110822/p... http://preshing.com/20110926/h...
Perl Programmer for hire
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.
The language itself moderately encourages unreadability, but I think the language itself is not the only problem. Even with pretty printers, there's a separate problem in that the perl community tends to even more strongly encourage language efficiency over code readability, and encourages leveraging the language's most powerful, but least readable syntax. That can't be pretty-printed away. In fact, in my experience self-taught perl programmers start off writing fairly readable code, if for no other reason than its easier for themselves to read their own code that way. But the more they encounter other perl programmers and other examples of perl code written by others, the more they degenerate into increasingly less readable code. Its not exactly the language itself causing that, but rather an amplification effect where its small encouragement influences a larger programming community to loop around and reinforce jettisoning syntactic candy for pure efficiency (and lose readability in the process) among its members.
You could say Perl is the tool that the Perl programming community uses to make more Perl programmers, molded in their image of absolute conciseness as one of the higher abstract goals of perl programs.
None of those dynamics have ever occurred in a Python shop?
The second half of the nineties was a bad scene for code readability all around, or did you somehow not notice the Herman Miller office furniture bubble?
There was a lot of Perl written during this era. Perl was the only language that could keep up with the Vogon rapture of all things brick and mortar. The ferryman threw in the towel, auction off his ferry on eBay, bought two cords of dynamite (mail order), and simply diverted the river. Pretty much everything was still where it had been, but traditional commerce was all on the other side now.
My development platform circa 1996 was NT 4, on a P6 200 with 32 MB of EDO system memory, a 640 MB disk drive, and a good quality 17" Dell CRT. It was tolerable, but hardly coding nirvana. The world was shifting under my feet almost daily: Linux, BSD, 2000, LBA, AMD64, SATA, DDR, broadband, Mozilla, Google, DVI, PHP, Python, Ruby, C++, STL, and not an open source version control system worth a crock of shit for love nor money.
I wonder why my coding standards at the time did not optimally favour my future self in the mid 2000s with my CoreDuo workstation, 4 GB of ram, 200 GB of disk space, and twin 19" monitors.
Do recall the little puzzle with the sliding digits 1-15 in a 4x4 grid? Trying to get any significant piece of glue code to run on NT and Linux and able to survive unscathed a major upgrade of each was a lot like that. Or have you blacked it out? Many ugly lines of code were written because the tiles were sticky. In the stupidest possible ways. And it was all going to be Ruby next year anyway. Whatever language you were working in was next up against the wall after the demise of B&M (if any wall could still be found). Soon the Wall was up against the wall, but I digress.
Programmers were in such short supply that vast numbers of people were coding in languages they only pretended to know. Have you forgotten that, too? If Visual Basic had been a better scripting language, Perl would have come out the other side better loved.
The great thing for the smart young programmers about becoming trendoids is that it helps to insulate them from the ugly job of cleaning up yesterday's bubble's giant mess.
[Off-Topic]
I've been a daily visitor for 14 years as of next month. I made an account once, but I use unique random passwords for every site, and it's way too much trouble to open my password vault just to login on a site where I can comment anonymously. (Nevermind that I usually spend at least half an hour editing and previewing my posts.)
Just a bit curious, when I went to youtube for that video there was a list of several ASMR videos lined up on the right, presumably as "related". So just what is the relationship between Perl and ASMR? Or maybe Larry Walls speaking brings out the tingles in some people?
Perl just works. In a subtle way. Perl is easy to think in. It's easier to write the same software in Perl than any other language. Other languages require you jumping through hoops to express what you want to express. I always reach for Perl first when I need to write something, if possible, because I know I can write it easier and more naturally. I'll get the job done quicker.
Perl 6 has been the best thing that ever happened to Perl, because it made Perl 5 a stable, "long term" release which we could keep using. Python, for example, destroyed itself by breaking its own language from release 2 to 3. The stability of Perl 5 means the language didn't get broken by people trying to improve it, and it helped create a stable platform for Perl.
... at about that same time JavaScript was declared to be on its last legs, (Java applets were going to bury it), and COBOL was declared moribund over 40 years ago. Meanwhile, every proclaimed "natural language" phenomenon has proven too cumbersome for actual production.
Perl is just like Jesus!
YAY Perl! Zombie party at my house!
- Zav - Imagine a Beowulf cluster of insensitive clods...
I'm pretty sure you can perplex the reader with gibberish in BASH as well.
You don't use your password much your browser remembers on /. for a long time. Besides after 14 years you could just pick an easy to remember password and use that.
Perl has got to be one of the WORST programming languages ever designed -- all those dollar signs to make up for bad syntax design. I thought C++ was bad, but C++ is syntactically a thousand times more sensible than Perl ever was. Even a syntactically obtuse language like Scala is better than Perl.
Now can somebody *please* go and kill that abomination called Python?