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.
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.
Meanwhile, Perl 5 being phased out of system building / admin tools and web frameworks. Even Perl 5 is dying.
Not for me, I write new Perl 5 code all the time. Get some real useful work done with it too.
Shall we drag out all the other obfuscated code contests and judge all languages guilty by the most heinous crimes committed with them? Remember that C and C++ give us Windows.
Perl 5.20 was just released and "represents approximately 12 months of development since Perl 5.18.0 and contains approximately 470,000 lines of changes across 2,900 files from 124 authors."
That doesn't seem to bad to me, but I'm not sure how that number of core release authors compares to other languages like Python or Ruby.
What's the difference between a hipster and a Perl hipster?
A hipster liked it before it was cool and doesn't now. A Perl hipster liked it when it was cool, and still does.
Meanwhile, Perl 5 being phased out of system building / admin tools
Really? what's replacing it? (genuine question ... I haven't seen anything that really fills that niche as effectively nor as completely)
Perl 5 is still charging full steam ahead in every sysadmin group I've been around. I know there are python advocates out there, but I have only encountered ONE major IT shop that is completely (or nearly so) python driven (and it happens to be Guido's employer -- hardly a good example). Other than that, the most I've seen is _some_ python but _mostly_ perl in any IT shop.
Sure, language-geeks have been talking about what other language has done a better job of being "a language" for at least 10 years ... but really, anything you can say negatively about perl can be said about bourne shell programming. And, yet, not only did bourne shell dominate *nix sysadmin and package install programming for 25+ years, but it is _still_ being done out there, by some backward luddite sysadmins. Perl has only been dominant in the sysadmin space for less than 15 years ... I wouldn't be surprised if it lasts at least another 10 more. And, really, since it lacks many of bourne shell programming's problems, it'd be reasonable to expect it to keep going for a lot longer than that. Especially as perl 5's evolution continues to slow down and become more stagnant (creating a consistent and stable programming layer ... which has not been true through the entirety of perl 5's lifespan -- there were a few major hiccups there as various sub-systems were refined or changed).
(to be clear, perl 5 has _existed_ for more than 15 years, but it didn't become really dominant as a sysadmin language of choice, finally eclipsing bourne shell, until the very late 1990's or early 2000's ... probably about the time that y2k issues wiped out anything too old to have/support perl, and the last of many *nix vendors and most linux distro's being sure they included perl in their boilerplate installation, pretty much removing bourne shell's one major claim to fame (ubiquity).)
More telling is how utterly fast Perl is compared to the other languages. I've run most of the sample files from this language shootout and had remarkably similar results to what they list there.
The Perl version performed on par with the C and C versions, and it's growth/memory usage stayed pretty consistent throughout. The other languages were horrid. They took much longer, and their memory usage grew significantly during the run.
I use Perl still when doing scripting tasks. I love Perl, always have. I don't, however, necessarily think it's the right choice for building a medium to large web-based application any more. Sure the performance is there, and there are some great frameworks like Catalyst and Dancer, but to me, they still feel a bit antiquated to some of the other technologies I've used. Plus installing tons of CPAN modules can get a little trying at times.
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.
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?
Slashdot reminds me of the townspeople in "The Simpsons" the way the majority opinion changes.
It wasn't that long ago that Perl was a darling, loved by all, with indecipherable code flowing freely in sigs and comments. Many even seemed to take pride in creating and sharing the most obtuse code imaginable.
Now it's, apparently, the worst thing ever that no one in their right mind would use for even the most trivial task.
Oh, Slashdot. When will you build a monorail?
Required reading for internet skeptics
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
... 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
Perl 6 is about love, care, tolerance and friendship.
Well, it clearly isn't about deadlines!
Ezekiel 23:20
Writing a virtual machine in C is dead-simple. It's just a loop over a table of opcodes. You can even get fancy and thread your dispatcher (that is, replace your loop conditionals with direct jumps to the next instruction handler), making it nearly as fast as JIT'd code because the CPU can pipeline all your virtual instructions.
In fact, writing a virtual machine is arguably easier than writing an AST (abstract syntax tree) interpreter (which is what Perl5 is), because it's an elegant abstraction that cleanly separates areas of concern.
If you can't write a VM in C than you're definitely not an experienced programmer. And if you think using LLVM to write an interpreter is easier, than you're just... I don't even know what... totally out of touch and have no clue how this stuff works.
The VM isn't the problem. It's all the bells and whistles. The typing and object system. The FFI system. Garbage collection. Perl6 is a complex language, and they tried to bury too much of that complexity at the virtual machine layer. Or at least, they got tangled up in it.
They couldn't use existing interpreters because at a minimum they wanted sane string prototype with a proper understanding of Unicode, something Java, C# and other systems lack. Perl 6's NFG (normalization form G) is a thing of beauty, but to make it fast you have to put it at a low-level. As for why they got hung up on all the other stuff, I don't know.
To see what a fast, practical, feature-rich, and state-of-the-art (non-experimental) virtual machine looks like, I would recommend Lua's VM. It's about as simple as you can get and yet remain widely useful. It's completely written in portable, ANSI C (1989), it's several times faster than Perl, Python, Ruby and most other non-JITd interpreters, and the bytecode dispatcher is basically a giant switch statement inside a loop--very easy to read and work backwards through how the typing system works. (It could be made even faster by threading the dispatcher, but to remain concise and performant--without a mess of function pointers-- would require using a non-portable construct like computed gotos. Although the only C compiler I know of which doesn't actually support computed gotos is Visual Studio.)
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.