The Fall Of Perl, The Web's Most Promising Language
fastcolabs.com
fastcolabs.com
Welp, now I officially feel old. Thanks!
In seriousness, though, this is not a very informative article. It essentially boils down to "I learned a little Perl after college, but didn't like the syntax. Then I went to grad school and found that everyone there was using Python, so I switched to that instead. Also, where's Perl 6 amirite lol."
Which is fine, as far as it goes, but it tells you more about the author's career path than it does about either language. And by doing so, it leaves out important elements of the story. Writing an article about "the fall of Perl" that only incidentally mentions PHP, for instance, is a big omission. Insofar as Perl has fallen, what it fell from is the position of leading language for building Web applications. PHP is what pushed it out of that position, not Python or Ruby. If you want to write an article about the fall of Perl you have to explain how that happened and why, but this article attempts neither.
I think the root of the problem is that the author is incorrectly generalizing from his own experiences. He mentions working in scientific computing these days; if you work in that field, and entered the workforce within the last decade, I can totally understand how it might look like The Story Of Programming Languages goes "once there was Perl, now there is Python, The End." But step outside that niche or that time window, and things look very different.
The overall trend is Perl died everywhere.
I personally think Perl's death was proper.
During Perl's upswing, it's various absurdities were all touted as virtues. The weird symbols and the ability to do amazing things with a single line were both proof that Perl was the language for the people who knew more than us. At the certain point, the emperor's cloth just faded and people wanted languages to accomplish things rather than to prove they were smart.
Perl has positives, Perl's weirdnesses have positives. But once it lost it's cachet, none of the tradeoffs between obscurity and power look good. And yeah, other powerful interpreted languages arose. But which still doesn't matter which one won because once the "magic", the reality distortion field, was gone, every other good interpreted language looked better.
Huh? Is that offering a false choice between total dominance and death?
> Perl has positives, Perl's weirdnesses have positives.
I am not going to generally argue for one language over another. Most languages have good and bad, and a learning curve to doing things right. Perl has a learning curve too, and while there is more than one way to do it, that doesn't mean that every way is equally maintainable over time.
When I look at languages I can do interesting things with, Perl is at the top of my list along with Lisp, Rebol, and Red. These languages have a degree of mutability in the language which allows you to do things that might otherwise not be particularly possible. There's a strong lisp heritage that runs through the entire set.
Now consider something like this:
package My::class;
use PGObject::Util::DBMethod;
use Moo;
with 'My::PGObject::SimpleRoleWrapper';
has foo => (is => 'ro', required => 1);
has bar => (is => 'rw', required => 0);
dbmethod foobar => (funcname => 'foobar',
funcschema => 'myclass');
dbmethod save_new => (funcname => 'save',
funcprefix => 'foobar_',
funcshema => 'public',
strict_args => { bar => undef });
This gives Perl a lot of power, and once the framework is done, learning to code Perl in the framework (with or without Perl knowledge) has an easy learning curve. The code is easily maintainable and it is robust.
I missed the camel's obituary.
I recently wrote a program in Perl which had to be delivered in two weeks. I don't think I could have delivered it on time with C or Python.
Saying Perl is dead, is like saying AWK is dead. I still write AWK programs sometimes.
Whatever's the right tool for the job.
Far from the truth, Perl is everywhere, what died is the hype.
(Note that under this definition, FORTRAN isn't dead—people still write new code in it, every once in a while, due to its mathematics libraries. Perl is "more dead than FORTRAN.")
Without revision to clarify your point, it looks somewhat like you had a statement you wanted to make (Perl is "more dead than FORTRAN.") and had to reach for some assertions to support it.
New people learn COBOL still, but they only do that if-and-when someone with an existing COBOL codebase has a problem with it, for which they're willing to hire and train up new programmers in COBOL.
For example, banks who needed their batch-processing code updated for Y2K-compliance trained a good few people in COBOL. But they weren't learning COBOL wIth the intent of writing new code in the language—just with the intent of maintaining old code. Effectively, they were treating the COBOL codebase as a Ball of Mud (http://laputan.org/mud/), where old components could be patched, but any new component should be written for a living platform, communicating with the Ball of Mud over an API instead of being sucked into it.
I'm asserting, here, that Perl is such a language—that the only reason new people learn Perl is to maintain a Ball of Mud written in Perl. From there, they may go on to become productive Perl programmers—but because they were only "born" into the Perl community because some company who had Perl-ers lost them and needed new ones, the language's adoption rate is effectively "below replacement," like a birth rate below 2.0.
In living languages, at least some people will learn the language on their own, because they think it will be useful for some task they'd like to accomplish. Perl is not one of these languages.
Under this definition, other dead languages include sh-derivative shell scripting (people only learn it because shell scripts that already exist must be modified), and anything to do with SOAP (it was stillborn; people only ever learned about it to deal with codebases that used it. Then, horrifyingly, they ended up creating more of those codebases.)
I've been hearing that same thing repeatedly since the past 10-12 years.
Yet that is never so.
Exactly true. PHP was the thing to use in 2001. At that time Ruby was rarely used for web purposes, and most Ruby libraries, while extensively documented, were mostly documented in Japanese with a tiny, incomplete English version with horrible grammar. And Python? Well, there was no Django, Flask, WSGI, SQLAlchemy, Pyramid or other frameworks/utilities that Python programmers enjoy today, and Python was rarely used in a web context.
Of course when you write code in a dozen languages you stop seeing the language after a while and just see the code. And at that point it really is all the same.
Fully agree. You start to look how language X exposes the CS concept Y, instead of just looking at language X feature list. A kind of meta level, if you will.
Up until last year, I did a lot of web development in Perl. Its strengths were CPAN & community, ubiquity and top-notch text processing. Its acquired taste was very elegant expressiveness once you grokked the grammar.
Then all the Perl leadership focussed on the black hole of Perl 6 which was solving a problem no one had but CS linguists. So Perl users like me felt there was no future in Perl. Perl 6 would have to be relearned for no tangible benefit so why not learn something new with a growing rather than stagnant/declining ecosystem? No one was forced to leave, but like a trap door, as soon as a Perl programmer learned something new, they were only going to continue to decrease their use of Perl.
The rise of Python and Ruby (and Ruby on Rails especially) and even PHP, were grave wounds to the health of Perl, but Perl 6 was the self-cutting that bled the community beyond the point of self-repair.
Perl has a grammar? In seriousness, the old aphorism that "the only thing that can parse Perl is Perl" didn't help Perl. The tooling lags behind that available for other dynamic languages.
Bulk of the effort is in developing MoarVM, which is likely to become a suitable replacement for Parrot. Documentation, Speed and standard libraries remain as open issues. Of which last I heard was Larry Wall was writing a Camel book equivalent for Perl 6. So its mainly speed and standard libraries.
I would give end of next year, by the time its ready for prime time.
I wish this claim wouldn't come up in every Perl article because that's a big part of Perl's perception problem. P6 is entering its 15th year of advocates claiming that it'll be ready in "about a year and a half".
If that claim is true this time, then it puts off people doing interesting things with Perl now as they figure they'll wait for a successor to look at it.
If that claim isn't true, then it puts off people doing interesting things with Perl now as the claim will change to be "about a year and a half from now" in another 18 months.
I'm of the opinion the only way to solve the chicken and egg usage problem is to convince a few people to be chickens. That's not going to happen without them trying it out. (I'm aware you've thought quite a bit on this issue).
2000 Python 2.0 released 1994 Perl 5 released
2008 Python 3.0 released 2000 – present[/b] Perl 6 "in development"
2013 — Perl 5.18 released
Is Perl 6 is more consistent(for lack of a better word) language ?
Not the right way of looking at it.
Perl 6 doesn't continue from Perl 5. Its more like a total redesign. Some even say, they are so different Perl 6 isn't even Perl(5) anymore- only common things being sigils, core philosophy and the author.
I can't obviously write a complete synopsis of Perl 6 in a comment. But its like what Perl 5 would look after 20-30 years in development + Lisp powers in C syntax.
Perl seemed to me just hack upon hack. You can see the progression. First there were no local variables. Then "local" was added which effectively pushes the current value on the some stack and retrieves that value on the way back, then later "my" was added to actually give local variables.
Similarly all the crazy special variables @_,$_, $a, $b, $&, $', $+, @+, @- %-, $^R, $., $/, $|, $\, $", $; etc etc etc. I'm sure someone out there really loves that stuff but to many it's one giant hack, disliked for similar reasons to PHP's disorganization.
On top of that it died at version 5 because version 6 never came out.
For web stuff, PHP at least provided a huge speed boost (over CGI, the typical way Perl was used) PHP also supported the whole shared host model much better than Perl/CGI. I'm not saying I like PHP. PHP's templating roots also made it more approachable by beginners. I'm only pointing out why for some use cases PHP killed Perl.
On the other side Python also killed Perl. Python seems like far less of a hack upon hack design. Python also has a comparable number of libraries, many builtin making it usually as easy to bang something out as Perl was.
> Similarly all the crazy special variables @_,$_, $a, $b, $&, $', $+, @+, @- %-, $^R, $., $/, $|, $\, $", $;
Of these the only four most Perl programmers should ever use are @_, $_, $a, and $b. The rest are great for advanced manipulations (probably along with the local keyword) but are best thought of as configuration tweaks to the runtime.
> On top of that it died at version 5 because version 6 never came out.
Perl 6 did come out. It just doesn't have that much of a community and has about the same relationship to C++ does to C. Perl 6 won't kill perl 5. Ever.
Perl is dead in some environments (and good riddance), but it is a very powerful development environment for others and I doubt it will ever die per se.
But yea, Python won.
Perl's embedding of regexes into the language syntax is a fantastic feature, as is the way captured groups can be assigned to a list. No other language comes close to making regexes usable. Javascript, which at least has a literal syntax for regex, is still awkward. And the other language I use the most, C#, has such a bad interface for getting captures that I get it wrong and have to look up the documentation EVERY SINGLE TIME I USE IT.
I would compare regex as an add-on library in most languages to be as awkward as OOP as an add-on to Perl 5 was. At least Perl has corrected that; besides Javascript, have any other languages taken steps to make regexes easier to use?
Perl hasn't really corrected that. Moose is an external library (with downsides, such as load-time last I checked). When it becomes part of the core Perl language, I'll consider Perl to have corrected it.
Being able to use Regex easily is a plus in my book. Yes they are lower than some dedicated string search or some state machine ad-hoc implementation, but you can document Regexes and they pack a lot of punch.
If a Regex is causing a concern in term of performance, then it may be time to review that code and optimise it, otherwise why even bother?
When people talk about Regex being bad and they say you can often use string manipulation instead they only talk about the most trivial uses of Regex.
As soon as you go beyond that, using a Regex is almost always going to be cleaner than spewing lines of codes and building state machines to achieve the same functionality.
(I don't think it is controversial that Python has a relatively simple language definition/grammar/etc; regex as language syntax would expand all of that quite a bit)
The one language which didn't for a very good reason was Rebol. The reason is that Rebol has different syntactic sugar for recursive descent parsing.
Do you really expect this to end well? There are endless flamewars raging across the Internet about the 'correct' way to place braces with both sides claiming that the other side's solution is 'uglier.'
> And no one will ever convince me that significant-white-space and not having block enders are good ideas
Insightful discussion doesn't usually stem from the phrase 'no one will ever convince me.'
> it makes refactoring and copy-pasting code hazardous
I see this bandied about a lot, but I'm curious if people actually run into this issue. I certainly haven't run into this issue, nor have I come across anyone who has had this issue.
A couple of points:
1) This comes across to me sort of like the arguments against git due to the user's ability to rewrite commits (e.g. "I can't use git because you can rewrite commits; therefore when someone fixes a bug they will rewrite the commit that introduced the bug rather than patch the current state of the repo"). Arguments that are theoretical, rather than practical. Similar to the other top-level poster claiming that significant whitespace will run into issues with all of the Unicode whitespace characters.
2) When you copy-paste Perl (or C, or Java, etc) code, do you not reformat that code anyways? I shudder to think of the code base where refactoring efforts rely on copy-pasting code without any sort of a consistent style since "it's between the braces, so we're all good."
3) This seems to be an argument that runs along the lines of static-vs-dynamic typing. One side argues that static-typing is "better" because you don't have to worry about type errors cropping up at runtime, since they are resolved at compile time. You're arguing that it's 'hazardous' to copy-paste or refactor code because you could mess up the indentation, but you don't have to worry about these things 'for free' when you have more concrete start- and end-block semantics.
Sure, but you don't have to worry about reformatting making code that was correct suddenly and subtly incorrect.
and
> invisible characters copied and pasted incorrectly to cause semantic errors
are two different issues. Reformatting doesn't insert (unexpected) invisible characters[1].
As to copy-pasting, this issue already exists in other forms with other languages. How long would it take most people to find the error here:
my $variable = “(＃｀д´)ﾉ”;
C:\Users\Mithaldu>perl -e " my $variable = “(＃｀д´)ﾉ”;"
Unrecognized character \x93; marked by <-- HERE after ariable = <-- HERE near column 18 at -e line 1.That being said, even with the helpful Perl error message, the less experienced developers may have issues trying to determine why Perl doesn't like their double-quote before they figure out what the real issue is.
I guess I should be clear, that I'm not hating on Perl. It's more that I see the "OMG! Semantic whitespace in Python!" argument as a bit of a red herring if that's your only reason for not using the language.
Yes, with Perl::Tidy and one keyboard shortcut bound to it. With Python I have to manually and very carefully block-indent the pasted fragment and then figure out how it fits into existing code. Even if there were a proper Python code formatter (hint: there isn't anything even close in functionality to Perl::Tidy) it wouldn't be able to figure out the code, since whitespace is significant. No such thing in Perl -- paste, tidy, rinse and repeat.
No need to do it carefully or manually. The indentation within the fragment will be internally consistent, as will the indentation in the existing code you're pasting it into. So you just have to figure out the difference in indentation level between the two and use whatever keyboard command your editor has (e.g. C-c < and C-c > in Emacs) to shift the whole fragment.
> Even if there were a proper Python code formatter (hint: there isn't anything even close in functionality to Perl::Tidy) it wouldn't be able to figure out the code, since whitespace is significant. No such thing in Perl -- paste, tidy, rinse and repeat.
Right, but in Python there is no such thing as reformatting. The information about the structure is already encoded in the indentation, so it's neither possible nor necessary to reconstruct it from other formatting characters.
In other words, whereas in Perl and C-like languages you would 1) edit the braces so that they're correct and then 2) automatically reconstruct the indentation to match the braces, in Python you simply 1) edit the indentation so that it's correct.
In my experience it's been a problem about five times in the last 10-15 years, but the conciseness pays dividends every single day.
Perl 5 is a mature language. There is a lot of effort at building Perl 6, but at this point it doesn't really look like Perl 6 will be a successor to Perl 5 (the metaphor now is "little sister"). It's so different, it is like learning a new language.
Now, I do a lot of programming in Perl. I have done some scripting in Ruby, Python, PHP, and more, but I always come back to Perl because the language is remarkably flexible. (Rebol is probably the second I frequently come back to, and Red looks promising.)
Predicting the demise of Perl is relatively premature. I don't think we will ever see Perl 6 supplant Perl 5. Rather these will become different languages (with a relationship similar to that of C vs C++).
Now you can write crap code in any language, and I just love how Python gives invisible characters semantic meaning (not), a problem that is likely to get worse as the number of whitespace characters continues to proliferate (not just plain spaces and tabs, but non-breaking spaces vs regular spaces....).
What perl has lost is the "let's quickly throw together an app" crowd. That crowd has gone sometimes to Python, sometimes to Ruby, and sometimes to Lua. From where I stand, good riddance. This is what gave Perl a bad reputation in the past.
To plug my own projects, right now I am working on a framework for delegating Perl object methods to PostgreSQL stored procedures.[1] At some point I may port the work to PHP and Python, but currently Perl is where this is really going for me. The thing is that such work is not applicable to the "throw together an app using an ORM or NoSQL fast" crowd, but it allows for some very sophisticated, powerful, and robust business tool development.
Additionally I have to plug http://cpantesters.org. This is a really really useful piece of the Perl community. I got a test failure report today for PGObject::Util::DBMethod failing to load in Perl 5.6.4. My first thought was "who the heck uses Perl 5.6 anymore" and my next thought was "I guess I had better start adding minimum Perl versions to my Makefile.PL."
[1] The two most important pieces are https://github.com/ledgersmb/PGObject-Simple-Role and https://github.com/ledgersmb/PGObject-Util-DBMethod
I know that people love to hate on Python's semantic whitespace, but this is the first time that I've seen someone argue that Python's lifespan is limited because we are about to enter a period of exponential growth in the number of whitespace characters.
Where do you feel that this growth in the number of whitespace characters is going to come from? Do we not already have a plethora of whitespace characters in the current Unicode standard, in addition to things like the vertical tab of yesteryear that languishes in the ASCII standard? How come we don't see any of these issues now, even with the number of whitespace characters that we already have at our disposal?
> The thing is that such work is not applicable to the "throw together an app using an ORM or NoSQL fast" crowd
Are you trying to imply that using an ORM is the sign of someone trying to "whip something together fast?" What are your feelings on DBIx::Class? Should those people who use it jump ship to some other language so that you can bid then "good riddance?"
I think the various Unicode whitespace characters are likely to gain more use generally. The big problem though is that whitespace characters all look alike and so you can't read and parse the way a computer does.
> Are you trying to imply that using an ORM is the sign of someone trying to "whip something together fast?" What are your feelings on DBIx::Class? Should those people who use it jump ship to some other language so that you can bid then "good riddance?"
Not really. ORMs can be used in significant applications and in fact a lot of people use DBIx::Class that way in Catalyst etc. I am referring specifically to the quick and dirty app crowd. You have PHP, Python, Javascript (via Node.js) and Ruby largely taking that role over. And that's fine. Perl is a wonderful language, but to write good quality, maintainable, robust code in it takes some work. But that work is well rewarded.
I'm curious what you expect these increased usage to stem from, and how you feel that it will inevitably find its way into source files.
> The big problem though is that whitespace characters all look alike and so you can't read and parse the way a computer does.
In general, the editor takes care of indentation for the programmer. What developer is going to add (e.g.) non-breaking spaces as an option for indententation in the development tool that they maintain?
If you're worried about copy-pasting, then that's already an issue in some places. I've had SQL break because the whitespace contained invisible characters due to an encoding issue during copy-paste, and PostgreSQL (IIRC, could have been Oracle) wasn't very helpful in diagnosing the issue.
Unexpected invisible characters cropping up anywhere are going to give you issues, Python or not.
I think the big problem is, that there are people out there, that think Python programmers have a huge urge to use non-standard whitespace characters in their source code.
> Perl is a wonderful language, but to write good quality, maintainable, robust code in it takes some work. But that work is well rewarded.
The reward for that kind of code is the same in all languages, but your statement implies, it's maybe better to choose a language, where it's not as hard as with Perl to write good quality, maintainable, robust code. Point taken.
It takes struggling with the ways of doing things in the language and seeing what works and what does not. Perl is no exception, except that there is no One True Perl way. Every Perl programmer finds his or her won way.
Something tells me most Python lovers take Perl as a very serious competitor. Else they wouldn't be writing articles like these.
Python's big rise came after hipster crowds got web frameworks written in Python. If you use hibernate or spring in Java, you can only come to love Python's web frameworks. But that time is long gone now. The crowd went to newer languages like Scala and Go. For all practical popularity purposes. Perl and Python are the very same these days.
If you are really worried about popularity. Lets talk of Python's falling popularity compared to languages like Go and Scala.
>>By the late 2000s Python was not only the dominant alternative to Perl for many text parsing tasks typically associated with Perl
When it comes to serious text parsing work, Perl is still the only practical alternative you have. Ever checked upon Perl's Unicode capabilities?
>>2000 – present[/b] Perl 6 "in development"
The development of Perl 6 didn't start in 2000. And Perl 6 and Python aren't even in the same league for comparison.
However the author completely misses the point. I can sit on top of a high priority production issue, just have a big log file. If all I have is that- Perl has the tools to help me get my job done in a couple of hours. Call me back, when Python can help me do that.
>>Perl 6 has been an ongoing development since 2000. Yet after 14 years it is not officially done, making it the equivalent of Chinese Democracy for Guns N’ Roses
Comparing Perl 6 and Python's progress is a bit ridiculous. Merely the ambition and audacity of what Perl 6 is aiming to achieve is what Python would like to in the next 20-30 years of iterative development.
Perl 6 is not your usual language which aims a different syntactical style for decision and iterative statements and then calls it progress. A simple tour of the Perl 6 spec can help you on that.
Both languages have their uses. I write almost all of my code in Python these days, but fall back to Perl for complicated bash scripting. Shell scripts in Python feel clumsy, while Perl is very well suited for that environment.
Python is great for other types of scripts though, I usually switch to Python when I need to interact with web services or databases (there are great libraries that make this really easy, Requests and SQLAlchemy).
As far as Python feeling clumsy for shell scripts, things like importing basic os functions:
import os, sys, shutil
if __name__ == "__main__":
File::Basename
Cwd <= where abs_path resides, for some reason
File::Path <= rmtree, etc
File::Spec
File::Spec::Functions
... etc ...Not once you've seen this: http://amoffat.github.io/sh/
Personally, I have done a little work in Perl, but I never really considered it as tool I would want to build a large app using. I have always argued however that Perl is an ideal replacement for shell scripts and I have wondered for awhile what an interpreter shell would feel like if it used Perl as the language rather than say Bash.
In any case, we use Perl heavily at Craigslist and are helping to sponsor the continued work on Perl6. I don't think it's nearly as bad as people seem to think. But time will tell, of course.
We use sphinx by indexing those documents, and attaching the geographies and industries as tags to each document. Whenever a user logs in, it takes only a few hundreds of miliseconds to get the latest documents he needs to see
That is definitely not a killer feature, if it ever was one.
I'm a Perl developer, who also spent a few years working primarily in Python. But, I currently don't see anything that could flip that switch. Perl 6 might have helped seven, maybe even three or four, years ago. Or, a Perl 5 that didn't stop nearly completely for nearly a decade might have helped.
I see some great things happening in Perl 5 development; it's spun up again in the past few years, and Perl 5.20 is going to be a great release with significant improvements that have been a long time coming. But, no one except Perl programmers are paying attention to new features in Perl 5. Even Perl 6, as incredibly interesting and novel as it is, doesn't really garner much interest anymore, except a brief, "Oh, is it done yet?"
I still find Perl extremely productive. Many of the elements people complain about are merely matters of taste (and I prefer the Perl way about as often as I prefer the Python way). But, even I can't see how Perl could become the new hotness again.
I'm becoming an oldtimer in this field, as well...not quite a greybeard, but my beard has some grey. And, most of the Perl conferences and meetups are populated by folks even older than me. That's no way grow a popular language.
also this isn't 1994, package management is now so so so much easier that 'installed by default' isn't nearly the advantage it used to be.
The alternate interpretation is that Perl needs a LOT of books to explain things due to its quirky syntax and myriad coding idioms, so there are simply more Perl books in circulation.
"Swiss Army chainsaw" is the correct quote (as can be verified by following the source link provided in the article).
Perl 5 is still under active development. The latest stable release was version 18.2, made in January. Perl 5 will continue to exist even when more people start using Perl 6. Also, Perl 6 is available and usable already.
I use Ruby now for most scripting, and it is also awesome, but a lot less mysterious.
PHP dates back to 1994, and (arguably) became a serious contender with the release of PHP 3 in 1998. PHP pushed out the then-dominant web programming languages ASP (a Visual Basic variant) and ColdFusion, along with Perl. At that time Python and Ruby were not on the web development radar.
PHP is not "arguably the most common language for web development": it's by far the most common. Much of that is due to WordPress, Drupal, and other PHP-based CMSs, but unlike Ruby and Rails, PHP had a large developer base before WordPress and Drupal.
The article also completely ignores JavaScript, which thanks to node.js is gaining web developer mindshare faster than either Python or Ruby, and may push PHP's share down.
[PHP also uses the hated $ to prefix variable names, but that hasn't slowed it down. PHP is not as pretty as Python or Ruby but it's a lot easier to read than Perl.]
Good Perl is quite readable, and bad PHP, well, you are a fortunate man if you have never encountered any, and a top-notch reader if you have and have found it easy to follow.
It's hard to target people with a 'harder' syntax even if it may be better for some particular reason. Once a person has learned one language it is more worthwhile to gain a more broad knowledge base in that one rather then invest time learning in another.
It's likely most people that learned perl didn't start with perl as their first language. At the time it what came with whatever form of unix they had and extended the scripting they did, but was not friendly. There was just a lack of alternatives at the time. Now, in an interconnected world with no shortage of better alternatives, there is simply little reason to invest any time in learning Perl.
I was a web developer working nearly exclusively in Perl during the time period the author describes. I understand the author's lack of a handle on the period as he was, as he describes, in middle school at the time. Me, I had a job and a family and I was an actual Perl programmer. Come at me bro.
That aside, the description of a transition of developers from Perl to Python just didn't happen the way it is described in the article. Or, to be fair, it didn't happen that way for me.
I worked on a team extracting data from a number of disparate data sources and presenting reports on the web - basically the idiomatic Perl task. We tried to bring in PHP for a bit but found it wanting. As our jobs evolved out from under us, each of us moved on from Perl. Reporting jobs were becoming largely obsolete and there was market demand for working in other languages elsewhere. Being the early oughts, most of the engineers I knew had at least a few languages in their repertoire.
Of the developers I worked with, I was the only one to pick up Python. I remember feeling like I wanted to work with a dynamic language where OO was more core to the language feature set. Ruby and Python were both viable, though less known, options. I don't remember why I chose Python over Ruby, but I did.
My colleagues went on to work in Java or C#. Over time, I did a bit of both as well, especially C#. One buddy of mine still does his personal and peripheral scripting in Perl. I've largely forgotten the language.
Back on topic, I simply did not see an exodus of developers from Perl to Python. It just didn't happen that way within my community. Jobs got phased out, new ones began, often with new tools.
Off topic, what I did see at the time was a large movement of COBOL developers to JAVA. I saw that as a genuine migration, in earnest, of developers who were facing obsolescence.
I don't see it coming back anywhere near what it was fifteen years ago. Too little too late.
The only thing I miss about perl is the regexes right there at the heart of things, but I'll trade those for scipy/numpy/cython/etc and come out the better for it.
1. CPAN is awful. The website itself is so bad that the "correct" way to browse it is to use the big brother "Metacpan". Metacpan is also very bad, they strayed too close to CPAN design. Navigating it is a pain, and most of the documentation is done very poorly because no one puts time into formatting their readmes. None of the modules are in github, the issue tracker is a nightmare, the links make no sense ( "Source (raw) Browse (raw)" ) - the website itself is poorly done.
2. CPAN has many modules, which sounds like a selling point. The truth is that many of the modules we have worked with have bugs and poor documentation, and almost all of them are unmaintained. The owners either gave up or actually died (this is an old language after all). There is absolutely no support for trying to do common tasks with CPAN modules. You can't Google for your error, you won't get a response on StackOverflow. Bug reports don't get answered because the ecosystem is a ghost town. This makes trying to do common tasks painful.
3. CPAN is just messy all around. There's not even a command line flag to find out what version of a module you have installed. You have to hack into its internals to figure out what versions you're running. Some modules are hosted in foreign countries that intermittently decide not to download. Builds have broken due to inability to download from a mirror. A "benefit" of CPAN is that modules are tested against multiple architectures for you. The reality is that these tests don't matter. The Perl developers I've worked with bypass the tests with CPAN by installing with --notest because it's faster, and more than once a module has failed to install because the tests failed. But the failure was either a false positive or had no noticeable impact on implementation, and there's no alternative and no one to respond to bug reports. The only known benefit of CPAN - automated test running, has never once proved helpful.
4. One point I like in this article is that Python makes the right thing obvious. Perl's "multiple ways to do things" is one of its bigger design flaws. It seems like Larry Wall (creator of Perl) has a no-one-likes-this-langauge-so-try-to-please-everyone-by-offering-every-way-to-do-it complex. It's all to the detriment of the language. I have to Google for how to iterate over a hash every time, because there's multiple ways to do it, and they all suck. I never know if iterating over a $hash is the same as iterating over a %hash or a \%hash. Or if I should be searching for "hash" or "hashref" or if I should be using a "list" or an "array" or a scalar or who cares. The multiple ways to do things only amounts to one asshole on the team will exploit some unknown feature of map to write shorter code, not document it, and no one can read it. Any efficiency gained from shorter code is lost to unmaintainability. Also, Perl is not efficient, so it doesn't matter.
5. The language itself is gross. Beauty is subjective, readable code is not. The prefixing of variable names with @, % et all makes dissecting code hard and Googling impossible. The tacking-on of modern functionality will slap you in the face repeatedly. See: references. References are one of, if not the, biggest design flaw in Perl. They were introduced as a tack-on to hack over it's shitty default data structures. They make reading and writing code confusing, overly complicated, and haven not once offered us any benefit. Perl's leaky abstraction over poorly implemented data structures is easily seen in references.
6. No really, the language is gross. It has magic built in, and the syntax is a nightmare. Everything is done with sigils (characters like ~!=@#$ etc). You get function arguments as @_ . You do a regex match with $string =~ /(capture)/. This will magically populate $1 through $n with capture groups. This is bad. To substitute a string, you do $string =~ s/a/b. This modifies the string in place. Try to Google for how to not modify the string in place. Seriously, try and Google for it. If you forget to include an even number of values in a list it becomes another data structure entirely. If you don't put a '1;' at the end of your module code it will fail to work (no, really).
7. Larry's personal beliefs stray into Perl too much. Larry is a well known Christian, and you must "bless" a reference, a keyword baked into the language. This creeps me out. It doesn't really matter, and I 100% acknowledge how judgmental I'm being, but it still is out of place in a programming language.
8. All of these reasons culminate to one point I just realized: Perl is a bad language for a team. It might be fine for one person to write code that will never have to be maintained or read to accomplish some dirty task. The "features" of Perl ruin it for a team environment. Feautres like its "flexibility", wheel reinventing to avoid buggy CPAN modules, unreadable features hidden in sigils, magic, poor documentation, and hacker culture make it a very poor choice for multiple people to work on the same thing.
This is the perspective of a relative newcomer (~3 months of Perl exploration). I'm not a Python advocate and I don't have a strong opinion of what other language you should use, but Perl has caused us many problems and we switched to Ruby early on because of them. Maybe if / when I learn more about it I'll have a different opinion of it. Right now though I agree with this article and seeing Perl go out the door is fine with me.
What I mean by that is that at first glance, Perl looks very similar to some other languages, but the difference in design philosophy means it often behaves in a different way than you would expect from Python, or even Ruby (which borrows quite heavily from Perl). I doubt you would jump into Lisp coming from C or Python without a good guide, because Lisp looks different. Perl doesn't necessarily "look different" (beyond sigils, but that's usually just waved away without thought), but it is different in many ways. In that respect, Perl can sometimes be harder to learn for someone who already has experience in other imperative languages, such as C or Python.
Your experience is so very different from mine (and that of everyone I know) that I'm not sure we're on the same planet. CPAN Testers provide near real time feedback on the patches made to Perl itself. That's the combined test suites of almost 130,000 modules for every commit to the Perl language and core libraries.
> CPAN is awful […] Navigating it is a pain […] the issue tracker is a nightmare
These are opinions. I cannot see any facts to substantiate the claims.
> most of the documentation is done very poorly because no one puts time into formatting their readmes
No, most of the documentation is the best among libraries in any programming language because everyone uses documentation templates and then fills in the details in copious amount. These templates have been honed over years, and the docs are regularly quality checked by automated services. It also helps that the documentation format POD is so so stupidly simple that it never gets in the way of work: a programmer spends all the time writing content, none on formatting.
> None of the modules are in github
All of the modules are in Github.
> the links make no sense ( "Source (raw) Browse (raw)" )
"Source" shows the module's source (HTML, syntax highlighted). "Browse" browses the directory structure of the unpacked distribution. The raw links are the plain text equivalents served by the API primarily for programmatic access. All of this is readily obvious by just following a link.
> many of the modules we have worked with have bugs and poor documentation
Unsubstantiated, no details.
> and almost all of them are unmaintained
CPAN freshness tells a different story.
> owners either gave up or actually died
There's a process in place for taking over maintenance. It is used a couple of times a month.
> There is absolutely no support for trying to do common tasks with CPAN modules
Wrong. Any common task has several modules.
> You can't Google for your error
Unsubstantiated, no details.
> you won't get a response on StackOverflow
Wrong. Unanswered quota is only 10%.
> CPAN is just messy all around
Same is true for any file archive. Show me a programming language where this is not the case. At least it's centralised, not strewn across the Web! On top of the archive, curated indexes such as http://p3rl.org/Task::Kensho exist.
> There's not even a command line flag to find out what version of a module you have installed. You have to hack into its internals to figure out what versions you're running.
Wrong.
$ pmvers Catalyst
5.90060
$ perl -MCatalyst -E'say Catalyst->VERSION'
5.90060
Then pick a mirror near you. http://mirrors.cpan.org/ The standard CPAN client does this automatically during first run.
> The only known benefit of CPAN - automated test running, has never once proved helpful.
Unsubstantiated, no details.
> It seems like Larry Wall (creator of Perl) has a no-one-likes-this-langauge-so-try-to-please-everyone-by-offering-every-way-to-do-it complex.
Wrong, this is because humans have different ways to think and preferences how to express themselves. The programming language works with the grain of the human mindset, not against it. http://c2.com/cgi/wiki?ThereIsMoreThanOneWayToDoIt
> I have to Google for how to iterate over a hash every time, because there's multiple ways to do it, and they all suck. I never know if iterating over a $hash is the same as iterating over a %hash or a \%hash.
Then you know less than a beginner in his third lesson.
⎆ my %hash = qw(a b c d); my $hash = \%hash
⎆ while (my ($key, $value) = each $hash) { say "$key => $value" }
a => b
c => d
⎆ while (my ($key, $value) = each %hash) { say "$key => $value" }
a => b
c => d
⎆ while (my ($key, $value) = each \%hash) { say "$key => $value" }
a => b
c => d
Only bash and Tcl free you from thinking about and selecting the appropriate data type.
> The multiple ways to do things only amounts to one asshole on the team will exploit some unknown feature of map to write shorter code, not document it, and no one can read it.
This is a social problem, and not the responsibility of the programming language or its designer. Anyone can write crap code in any language. Enforce code style and policy locally. Static analysis tools like http://p3rl.org/perlcritic exist. Apply them.
> Perl is not efficient
Perl remains the fastest of the scripting languages.
> Beauty is subjective, readable code is not.
Unreadable code is a social problem across all programming languages. This has nothing to do with Perl per se.
> The prefixing of variable names with @, % et all makes dissecting code hard
Wrong, sigils make the nouns stand out, just like capitalisation in written German. Both empirically make reading faster and comprehension easier.
> Googling impossible
Wrong. It is true that search engines drop sigil characters from the query, but the context words still find the result in the index.
> References are one of, if not the, biggest design flaw in Perl […] make reading and writing code confusing, overly complicated
Unsubstantiated, no details.
> haven not once offered us any benefit
Wrong, as references are the basis for objects (OOP).
> the language is gross. It has magic built in, and the syntax is a nightmare
Unsubstantiated, no details.
> You get function arguments as @_
Concept stolen from Shell, already remedied in version 20. Signatures have been available for years with modules.
> You do a regex match with $string =~ /(capture)/. This will magically populate $1 through $n with capture groups. This is bad.
Agreed, side effects are evil. That's the legacy interface and impossible to deprecate/remove. The expression will also return a list of the captures which you can then assign or mangle as you wish.
my @results = $string =~ /(capture)/
> $string =~ s/a/b. This modifies the string in place. Try to Google for how to not modify the string in place. Seriously, try and Google for it.
Yes, and?
g perl substitute return modification
my $new = $string =~ s/a/b/r
Wrong, a list is a list no matter how many elements.
> If you don't put a '1;' at the end of your module code it will fail to work (no, really).
Valid complaint. Again, it's too late to fix it because existing code needs to keep working, back-compat is serious business for perl5-porters. New projects with modern Perl just avoid the need for that last line: http://p3rl.org/true
> bless […] but it still is out of place in a programming language.
The word is religion neutral. Your biases show.
> The "features" of Perl ruin it for a team environment.
Unsubstantiated, no details.
When I come upon a Perl program that does 80% of what I need, and would do 100% when modified, I simply turn around and look again. I consider reading other peoples Perl code on the same level as firing up Hexrays to debug closed source Mips programs.