Perl Is Undead 283
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.
$_ to that? (Score:3, Funny)
Congregation: $_
Pastor: $_.
Re:$_ to that? (Score:3, Insightful)
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.
Re:$_ to that? (Score:5, Funny)
Perl 6 is about love, care, tolerance and friendship.
Well, it clearly isn't about deadlines!
Re:$_ to that? (Score:4, Funny)
Perl 6 is about love, care, tolerance and friendship.
Well, it clearly isn't about deadlines!
No, it's about undeadlines!
I can understand you not bothering to RTFA, but at least you could RTFSubject! Some people... Sheesh!
Re:$_ to that? (Score:5, Insightful)
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.
sure you want to go with 'undead' ? (Score:4, Funny)
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.
Re:sure you want to go with 'undead' ? (Score:3)
What about "the rumor of perl's death has been greatly exaggerated?"
Re:sure you want to go with 'undead' ? (Score:2)
What about "the rumor of perl's death has been greatly exaggerated?"
And you heard it here on slashdot first.
Re:sure you want to go with 'undead' ? (Score:2)
What about "the rumor of perl's death has been greatly exaggerated?"
And you heard it here on slashdot first.
Yeah, its only Mostly Dead.
Re:sure you want to go with 'undead' ? (Score:3)
Re:sure you want to go with 'undead' ? (Score:5, Funny)
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?
Re:sure you want to go with 'undead' ? (Score:3)
[...] code [...] in sigs and comments. [...] Now it's, apparently, the worst thing [...]
They tried understanding their own sigs after some time.
Re:sure you want to go with 'undead' ? (Score:3)
There has been at least 2 huge shifts in culture in /. since I've been around and I think I was part of the 2nd wave that replaced the original /. crowd. I suspect a lot of the guys with sigs 200k and below were enthusiasts about Perl. In 2000 I would have called Perl my favorite language. By 2005 when Pugs came out I was a Haskell fan so the idea of a dynamic language with the fluidity of Perl having many of the powerful idioms of Haskell (what Perl 6 sort of has) was tremendous. A computer project that takes 14 years is unacceptably slow. We should have had Perl6 a decade ago. People in 2000 believed that in 2004 we'd be hearing that Perl 6 was ready and Perl 5 was legacy. That not having happened changed hearts and minds.
There is nothing irrational with opinions being guided by changing facts.
Re:sure you want to go with 'undead' ? (Score:3)
There never was something like a Perl kickstarter project where they put forward a "for $500k we can finish Perl 6 in one year". This is a two way street.
2005 eh? (Score:5, Interesting)
Re:2005 eh? (Score:3)
I always thought Perl 6's major problem was a lack of backward compatibility to Perl 5.
Re:2005 eh? (Score:2)
There's a Perl 6? When the fuck did this happen?
Re:2005 eh? (Score:5, Funny)
How about "Perl 6 is DNF's retarded cousin?"
Re:2005 eh? (Score:2)
yes but undead. DNF's undead retarded cousin.
Re:2005 eh? (Score:2)
Unfortunately Larry Wall and company don't have that excuse.
Re:2005 eh? (Score:2)
I don't think we're ever going to get as clear of an example of the second system effect as Perl 6.
I think R6RS might qualify as well. Damn those sixes...
Perl 6ers just can't get shit done. (Score:3, Insightful)
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.
Re:Perl 6ers just can't get shit done. (Score:2)
So what was C written in?
Re:Perl 6ers just can't get shit done. (Score:3)
> So what was C written in?
B, which was a stripped down version of BCPL [wikipedia.org], and then later C.
Comment removed (Score:3)
Re:Perl 6ers just can't get shit done. (Score:3)
C. At the beginning of the tool chain, there'll be a bootstrap compiler written in assembler, but full production C compilers are written in C.
Re:Perl 6ers just can't get shit done. (Score:4, Insightful)
You're implying that C-based interpreters are quicker and easier to develop, but that's patently not the case. Just look at the recent huge surge of LLVM-based JIT languages that have been developed extremely rapidly and in high-level languages. C is probably a poor choice now that good alternatives really exist.
Maybe the problem isn't the choice of language. Maybe the problem is that the designers were incompetent.
Re:Perl 6ers just can't get shit done. (Score:5, Informative)
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.)
C interprets (Score:3)
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
Re:Perl 6ers just can't get shit done. (Score:3)
- Perl 5 and earlier: An interpreter written in C.
Not exactly. The interpreter compiles the source files into a bytecode and executes it on a stack-based virtual machine: ahref=http://perlbin.sourceforge.net/perlcompiler/perl.internals.pdfrel=url2html-14852 [slashdot.org]http://perlbin.sourceforge.net...>
- Python: An interpreter written in C.
A virtual machine in C: http://www.troeger.eu/files/teaching/pythonvm08.pdf [troeger.eu]
- Ruby: An interpreter written in C.
A virtual machine in C: http://en.wikipedia.org/wiki/YARV [wikipedia.org]
Or in C++: http://rubini.us/ [rubini.us]
Or against the JVM (which is written in C++): http://jruby.org/ [jruby.org]
- Lua: An interpreter written in C.
A virtual machine in C: http://www.lua.org/doc/jucs05.pdf [lua.org]
- Tcl: An interpreter written in C.
A virtual machine in C: https://www.tcl.tk/community/tcl2002/archive/Tcl2002papers/kenny-bytecode/paperKBK.html [www.tcl.tk]
- PHP: An interpreter written in C.
Hey, you got one. However the they are currently revising the language to make it compatible with adding a JIT later: http://www.computerworld.com/s/article/9248637/PHP_keepers_plot_radical_revision_of_the_language [computerworld.com]
And Facebook has their own C++ VM: http://hhvm.com/ [hhvm.com]
- UNIX shells: Interpreters written in C.
Different problem space.
Comment removed (Score:2)
Perl6 vs. Perl5 (Score:3)
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 [perltricks.com]? Then use perl 5.20, and enable the feature. (although, I believe it's currently enabled via 'experimental [metacpan.org]', so people know they're enabling a feature that may change)
Re:Perl6 vs. Perl5 (Score:2)
Oh my God! Is PERL really competing for worst language with Brainf*ck? After reading the article on the operator mentioned, I can only assume so. I can't believe with all of the syntax backward-compatibility crap they've bolted on they couldn't just have cleaned up the syntax. Thus, my assumption is the only reasonable explanation. Or maybe brain damage... I hear you get that from PERL.
Re:Perl6 vs. Perl5 (Score:3)
No, it's actually more of a vicious cycle. Bad coders write bad Perl, which leads to brain damage, which results in worse code. If you have an array with five or six indices, unless you're doing some sort of borderline insane physics computation, you're already solidly in WTF territory. Most sane people try to limit their arrays to about two indices. Three is unusual. Beyond that limit, you should almost always be assigning explicit variable names to the components, and not working with them as arrays. And that limit applies to associative arrays and data structure chain references, too. If you're going more than about two or three steps out, there needs to be a named variable in there somewhere so that the code will be maintainable.
Re:2005 eh? (Score:2)
Come on it took ages for perl4 to die... This is normal.
Re:2005 eh? (Score:3)
Those things are happening or planned except for the version number change.
Tweaks to make complex data structures less of a nightmare: http://search.cpan.org/dist/pe... [cpan.org]
better integrate the object model: https://github.com/stevan/p5-m... [github.com]
"Undead" doesn't mean vibrant, though. (Score:4, Interesting)
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.
Re:"Undead" doesn't mean vibrant, though. (Score:3)
Re:"Undead" doesn't mean vibrant, though. (Score:5, Insightful)
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.
Re:"Undead" doesn't mean vibrant, though. (Score:3, Interesting)
Re:"Undead" doesn't mean vibrant, though. (Score:5, Interesting)
If only I could turn off indentation==scope. I would pay $20 for this ability (to work in every interpreter, not some special one off interpreter just for me).
Even *with* that limitation (and yes, I know a million people will respond saying it's oh so great and I just don't get it), I still think Python is pretty decent.. Though it seems to have (seemingly) superfluous colons in a few places, which reminds me of Pascal or BASIC.
Re:"Undead" doesn't mean vibrant, though. (Score:3)
Re:"Undead" doesn't mean vibrant, though. (Score:3)
pass is the equivalent of a nop, it has nothing to do with scoping. Have you ever read or written any python?
Re:"Undead" doesn't mean vibrant, though. (Score:3)
pass is the equivalent of a nop, it has nothing to do with scoping. Have you ever read or written any python?
According to every single example given on the python documentation page, pass is used to end a block. It get's even more hilarious when you try embedding python into (for example) html pages like web2py does (I've been using web2py hence my discovery that python actually has to have an end brace of sorts).
'Pass' is not a 'noop', according to the documentation; it's simply an empty statement serving only a syntactical function. In other words, had python had an end-brace the way it has a start-brace, 'pass' would not be needed. The only use for 'pass' in python is to serve as an end-brace.
Comment removed (Score:2, Insightful)
Yes, Perl is indeed dead and rotting (Score:2, Interesting)
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.
Re:Yes, Perl is indeed dead and rotting (Score:5, Informative)
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.
Re:Yes, Perl is indeed dead and rotting (Score:3, Insightful)
some people still write new COBOL too
sure, can write good stuff with it, but it is passing
Re:Yes, Perl is indeed dead and rotting (Score:2)
You'd be surprised how many software packages have a complete Perl under the hood.
Re:Yes, Perl is indeed dead and rotting (Score:2)
no I wouldn't, quite familar with that in both Linux and BSD lands
just last week had to install some nagios nrpe package that had some Perl library requirements, and it was hell first trying the one from repository, then a couple alternative CPAN ones, and finally finding the actual POS that would work.
Re:Yes, Perl is indeed dead and rotting (Score:3)
*ducks*
Re:Yes, Perl is indeed dead and rotting (Score:2)
Re:Yes, Perl is indeed dead and rotting (Score:3)
Same here. I am a freelance Perl programmer and for the past 12+ months have been very busy with coding in ... Perl. More so than when Perl was considered the "glue that holds the web together". And no, it isn't maintenance of old code.
A number of people who left Perl and declared it dead are the ones that couldn't program in Perl to begin with (never learnt the language, thought it could be learned by trial and error), and most likely still can't in whatever they consider fashionable right now.
Re:Yes, Perl is indeed dead and rotting (Score:5, Informative)
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.
Re:Yes, Perl is indeed dead and rotting (Score:5, Interesting)
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 [raid6.com.au] 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.
Re:Yes, Perl is indeed dead and rotting (Score:3)
String manipulation is the core functionality for all languages so this allows to compare languages fairly.
If that doesn't clue you in on how utterly full of shit he is, I'm not sure what will. I mean, Java Strings are immutable. This test is just about adding strings together. That's pretty much the worst possible case for trying to benchmark Java. So if you're coding Java and adding a bunch of strings together, you use a StringBuilder and not a String. Only you can go look at the source code, and whoever wrote it didn't. Not only that, but how much memory Java would use during the run would depend pretty much entirely on flags given to the JVM, because it would just keep eating up space copying the immutable String over and over until it was forced to garbage collect. And that's all just a quick inspection of the Java comparison. I am pretty confident without looking that that margin of difference between C and C++ is entirely due to pathological C++ code.
I mean really, if you think that your interpreted language is comparable to any major compiled language in performance, you're an idiot. Sabotaged test results (whether the result of duplicity or incompetence) don't change that.
Re:Yes, Perl is indeed dead and rotting (Score:5, Interesting)
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).)
Re:Yes, Perl is indeed dead and rotting (Score:2)
seeing a lot of system tools built in python now
Re:Yes, Perl is indeed dead and rotting (Score:3)
Like I said, I haven't seen python take over anywhere other than Google. That's a big claim to fame, surely. But, it's not as wide spread as it could or should be, at this point in python's life, IMO. It just doesn't have the momentum nor clear advantage (to non-language-geeks) over perl to push it forward fast enough to overtake perl.
I do like python, mind you. I just think it's stuck in the betamax / BSD niche (academically superior to its cousins, but stuck in second place for reasons that have nothing to do with its academic superiority ... because academic superiority doesn't win any races outside of academia).
Comment removed (Score:5, Informative)
Re:Yes, Perl is indeed dead and rotting (Score:4, Informative)
I moderated in this article, but this is something that I'd like to talk about for a bit, even if only anecdotal...
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)
Over the past 8 years my own usage of Perl in writing code has declined to zero. There has been a mentality change over the years in the shop I work in, and where we used to grab for Perl by default as a quick'n'dirty duct-tape & MacGuyver language, we now exclusively rely on Python. I think there are several reasons for this shift.
The most prominent one to me personally is that other languages have adopted CPAN-like repositories. I don't know about the statistics of numbers of modules, active development, number of commits, etc etc, and put bluntly I really don't care. Although these statistics are interesting into disseminating how active a language is to its developers, to me as a user of the language it only matters if a module is maintained and does what its supposed to do. The thing is, for most of the things I used to use Perl modules for, I now use Python modules, and can say "Well, it's good enough".
Our development teams composition has also changed. A lot of our older generation of programmers/admins have retired or switched jobs, and a lot of younger people were hired to replace them. The younger generation is definitely more familiar with Python, Ruby and other scripting languages than it is with Perl. The incentive for learning Perl has become a lot smaller. Perl was the de facto language for many when writing a CGI script, but then RoR and AJAX happened. While over time Perl adapted (think Catalyst and Dancer) other languages have adapted as well. Look at all the wsgi applications and frameworks in Python.
Our investment in Perl itself was more of the kind where we used a set of scripts to change data from format A to B at which point our Java and/or C++ code takes over, or some tools to deal with our logs, etc. The switch to Python for these tools was gradual (but quick) process, and we found ourselves not looking back. I can't really say that we were/are heavily invested in Perl or Python, but for day to day usage Python has completely taken over. Who knows where we end up in another 8 years from now?
Lastly, if you were to go around our shop, asking people what's new about Python 3 you'll get pretty much right answers. If you go around our shop asking people what's happening with Perl 6, you will get a blank stare. I remember clearly how Perl 6 was going to become the best thing since butter on toast, ... There was general excitement about it all, and then there was a whole load of ... well... nothing. We're 11-12 years further and there's still no sign of Perl 6. What the hell happened there?
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.
I don't doubt that Perl will be around for a whole lot longer. It has assembled a group of dedicated die-hard users and developers over the years, and in general it has a great community. There are older, more horrible languages that are still alive today, so I doubt Perl will be gone anytime soon.
However, while my entire post is anecdotal, I do think the Perl community is deluding itself a bit. The talk in the video (I actually listened to it in the background while working on something) mentions a lot of statistics that are interesting to the Perl developers and maintainers, but are hardly and indicator of usage or adoption. The more interesting part of the statistical talk was about the general decline of jobs available for scripting languages in favor of newer technologies, but even those statistics in general don't speak much about usage and adoption.
FWIW, may Perl be around a long long time. Having more tools at your disposal is never a bad thing.
Re:Yes, Perl is indeed dead and rotting (Score:3)
I remember clearly how Perl 6 was going to become the best thing since butter on toast, ... There was general excitement about it all, and then there was a whole load of ... well... nothing. We're 11-12 years further and there's still no sign of Perl 6. What the hell happened there?
Don't get me wrong about this particular thing... all of my commentary is about Perl 5. I think Perl 6 is dead on the vine. I think Perl 5 will probably be the final definition of the language. It will get refined, and bug fixed, but I don't think it will get the type of complete change that Perl 6 implies (not the current concept of perl 6, nor any concept of similar scope that might replace the current perl 6 concept). Nor do I think that that's a bad thing (for Perl 5 to be final definition of the language).
I'm also not saying Perl 5 is perfect. I just think it's "good enough"* for what it does, and for use in sysadmin type development (which is not just for quick and dirty duct-tape programming ... I've written pretty extensive projects in Perl), with a momentum that will carry it forward for more than a little while.
(* nor do I consider "good enough" to be a snobbish backhanded compliment ... I mean it more in the light of "the perfect is the enemy of the good-enough" -- "good enough" gets things done, "perfect" gets defined and redefined on a white-board for an eternity and never accomplishes anything other than a bunch of bloviating) (nor am I implying that that negative version of "perfect" applies to _any_ of the other languages being discussed ... I'm just saying, "good enough" is a good thing when applied to perl 5.)
Re:Yes, Perl is indeed dead and rotting (Score:2)
Maybe Larry is dead? For all we know he's just some chat bot trying to pass a turning test.
Re:Ruby is fast behind. (Score:2)
maybe in the americas that's true, not true elsewhere in the world *shrug*
Re:Ruby is fast behind. (Score:2)
There are developers who ride the wave of new languages (who appear to be surfing towards Go and Rust now that JavaScript has crested). In that respect, Perl has long since settled down, and Ruby is on the wave's trailing end. It could be said that now the hype wave is over, people can get real stuff done in the language.
Re:Yes, Perl is indeed dead and rotting (Score:2)
Nah, Rust is the new hotness!
"Undead"? Exactly. (Score:2, Insightful)
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.
Slashdot itself uses Perl (Score:3, Interesting)
Meanwhile, it's apparent that slashdot itself uses Perl e.g: http://slashdot.org/job_board.... [slashdot.org]
Always found it amusing (Score:3)
So Perl isn't Dead? (Score:3)
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."
Netcraft (Score:3)
But did Netcraft confirm it?
Personally I prefer "half-dead" or "quasi-dead". Does that make me a pessimist?
Only have themselves to blame (Score:2)
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?
Meh (Score:5, Insightful)
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.
Perl requires brains (Score:2)
Metaphysical query (Score:2)
Proof (with silly statistics) ... (Score:5, Informative)
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...
if it's not dead... (Score:2)
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?
There's nothing wrong with Perl ... (Score:5, Interesting)
... 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.
Re:There's nothing wrong with Perl ... (Score:3)
... 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.
Perhaps it's not Perl that died, but the philosophy of Perl - the need for a *wicked fast* scripting language to code up 1-100 lines of code gluing together entire systems. The philosophy of which is power, speed, massive flexibility (very very loosely typed language, you could demo complex data structure creation on the fly using the REPL) which empowered the lone programmer, not the IT department or enterprise software firm.
The diminishing of Perl is indicative of the wild wild web being tamed, and the Internet corporatized. A sad thing, but definitely predictable. I still use Perl once in a while (I'd say once or twice a year for a new compact script), but I never really share those scripts.
Perl isn't (un)dead: worse, it's moribund. (Score:4, Insightful)
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 isn't dead, it just smells funny. (Score:3)
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.
Perl's heyday in hell (Score:3)
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.
What is "Dead" (Score:4, Interesting)
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!
Re:What is "Dead" (Score:3)
I can't remember the last time a [major] web site or web framework was done in Perl.
Oh, I dunno, how about booking.com (about) [booking.com]? 'World's leading online accommodation provider' where 650K rooms a night are booked (they're owned by Priceline group, if that's a more popular brand where you live)?
A YAPC talk [youtube.com] by one of their employees says 99% of their code is Perl. Check out their dev blog [booking.com].
Re:It should be dead (Score:5, Insightful)
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.
Re:It should be dead (Score:2)
Comment removed (Score:2)
Re:It should be dead (Score:3)
A language that is expressive enough to allow you to write code that is concise and understandable (but no more concise. Cutting out verbosity is only good when it improves legibility) is going to give you enough of a dialect to make some truly twisted and illegible statements that are, nevertheless, still valid code.
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.
Re:It should be dead (Score:4, Insightful)
Re:It should be dead (Score:4)
Perl remember originated with short system automation scripts a replacement for Sed and AWK. It wasn't uncommon for a Perl script to be one line
perl -e... in a shell script.
And then of course a replacement for shell scripting. Perl handled 20 line programs wonderfully. But what works well at 20 lines doesn't work so well at 2000 lines. Perl took on new problem domains.
Re:It should be dead (Score:3)
You can write C-code obscurely too. But, somehow, Perl seems to encourage this sort of thing... 20 years ago my CS-professor dismissed Perl as a "write-only" language — since then my conviction of him being right has only grown.
I understand but disagree. Any language can be a write-only language if you don't care about maintainability. Then there are the wannabe gurus that save 3 lines of code not to shorten the program but to impress others. Even worse, there are people that criticise readable code for it being too simple. If you ever worked in a team of programmers with varying skills then you appreciate simple, readable code. You also will once you had to take over unreadable code.
Re:It should be dead (Score:4, Informative)
And another issue for me was this whole There's More Than One Way To Do It philosophy which I find extremely frustrating. Write a piece of code in 20 lines and show it on usenet. Somebody writes it in 10. Then another one pipes up in 3. Then the true Guru comes up with a one-liner that nobody can grok. And they all run faster. Maybe.
It also mean that when you read somebody else's code, you have to pattern that you can recognize. In C if I have to go through an array, you can bet there's gonna be a loop. In Perl, mystery, it could be any of multiple and rarely used constructs. The thing that made Perl popular at once was the integration of regular expressions, but we now have this in Bash =~, so why bother ?!?
Re: obfuscation example (Score:4, Insightful)
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.
Re: obfuscation example (Score:3)
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.
Re:It should be dead (Score:2)
While I do not particularly care for perl... shit programmers will write shit code in whatever language they are given. It isnt the language's fault they are shit programemrs. (though languages like perl are more than happy to give programmers as much rope as they would like)
My real problem with perl is that the fucking camel advocates bad programming style and hard to write code. I think snippets like yours come about because first time programmers read the camel and instantly became bad programmers. Larry effectively made people worship doing "neat tricks" as a style. It isn't the language, its the culture of lazy coding that the language grew out of.
Groovy, Python, and friends could have become the same pile, but at least they have examples and books that are written with style.
Re:Books like.... (Score:3)
A lot of best practices for Perl are good programming practices in general. Of course there are (plenty) of exceptions, but that's the case with other languages as well. One thing one wants to avoid is to program Python in Haskell or Pascal in C, for example.
As for hard to read (for a beginner) have a look at Haskell, for example.
Python's fame is that it "reads like pseudocode". That's nice, but utterly fails if a programmer has no good feel for algorithms. Pascal used to have the same fame. A few years back I had to reimplement a Pascal program into Perl. One of the pieces of code was 100+ lines. After some studying it turned out to be a variant of bubble sort. At the end few lines reversed the sort order (!). It could be replaced with a few lines of Perl. And no, not because I write short and cryptic code. The code could've been written way shorter in Pascal as well, even when implementing a sort manually.
Re:Modern Weak Languages (Score:5, Funny)
A hipster liked it before it was cool and doesn't now. A Perl hipster liked it when it was cool, and still does.
Re:Modern Weak Languages (Score:3)
In fact, I like it more now that it _isn't_ cool!
Comment removed (Score:2)
Re:Modern Weak Languages (Score:3)
That and the Perl community is good about taking upstream patches, has CPAN and a faster, cleaner implementation. Ignoring syntax, Python's got some ugly code in the implementation and it's touchy and irritating to port.
I actually got into Perl because I tried to port Python and Ruby. When you see what's under the hood, it really makes you love Perl. I've migrated from PHP to Perl for scripts and web stuff in the last few years and I find it much less frustrating. The problem is no longer how am i going to get this to work, but which CPAN module do I want to use to do it.