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.
As a Perl programmer whose colleagues occasionally encourage me to switch to Python, can you tell me a little more about what you see to be the uses of each, and why Python feels clumsy for scripting?
My bash scripts usually deal with files and text processing. Bash and Perl are great for that, especially Perl when I need a little more structure. Perl is more performant than Python for these tasks.
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
and:
if __name__ == "__main__":
don't make it feel like the best language for the job.
While I agree that Python seems more clumsy for shell-type scripting, Perl has most of the 'basic' OS functions scattered all over the place, not in a couple of comprehensive libraries. E.g.:
File::Basename
Cwd <= where abs_path resides, for some reason
File::Path <= rmtree, etc
File::Spec
File::Spec::Functions
... etc ...
Perl missed out on the hype-bubble of the web 2.0 craze which shot Python and Ruby to the top of the charts in the early/mid 2000's. But it wouldn't surprise me if Perl was "rediscovered" at some point sort of like how JavaScript has experienced a renaissance since Node and the much-improved runtime engines showed up.
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.
given the relatively small number of new programmers is an actual advantage for us: increased salaries. i don't know the actual reason why, but we have students who, after 3-4 weeks of perl training are thrown in production environment where they fix bugs and implement features on par with our senior devs. It might be because they are very smart, or because the language is actually simpler to learn than it looks at first sight. And the production environment that I'm talking about is a very complex web app from an architectural point of view: it has mysql, memcached, the authorization of documents is done through sphinx search engine, we're using dbix class as an orm and catalyst as a web framework, etc
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.
Yeah, basically there are 100k+ users in DB and 800k+ documents. Each document is filed under one or more geographies and one or more industries. Each user is entitled to access one or more geographies with one or more services. The SQL queries, besides that they have very complex where clauses, are very slow.
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's always been true, throughout the rise of PHP, Python, and Ruby. Now, Python is as widely available (actually moreso, if you're primarily considering the major Linux distributions, where many of the system tools are in Python).
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.
> I first heard of Perl when I was in middle school in the early 2000s.
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.
I disagree. A long list of the things that replaced Perl in various applications obscures things rather than revealing the basic trend.
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 });
What this would do is create a class with two properties (foo and bar), and two methods. The methods are delegated to stored procedures, and properties mapped into procedural arguments by name (the second example overwrites $self->bar with undef). I have created a class that does something with only declarative code. The code is neat, clean, understandable, and predictable. Again I could build something like this in Rebol or (once there is Pg support) Red, and this sort of thing could be done in Lisp too.
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.
If the life of a language can be measured in how many people are learning it for any reason other than to maintain an existing code base written in it (an arbitrary definition, but I think a common one), then Perl is roughly dead-as-a-doornail, in precisely the same sense as, say, COBOL is dead.
(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.")
Are you talking about new people learning language, as you state, or people writing new code in a language, as your example implies?
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.
The intersection of the two sets: new people learning the language, who are learning the language in order to write new code in the language.
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.)
PHP is what pushed it out of that position, not Python or Ruby
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.
In my opinion, they buried the key point... the dead end of Perl 6.
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.
Perl6 is pretty awesome in that regard. The grammar specification is written in the language itself[0] in a single file using the language's rules[1] feature. Perl6 is an amazing language, but it is hampered by a runtime that is currently too slow, a bad public perception, and a tiny community.
I don't think Perl 6 is a dead end. Far from it. From what I know is that its nearly feature complete. A small set of features remain, but those are only like what should be added for completeness sake.
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 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 agree with this as well, but from the other side. Giving out timeframes based on volunteer schedules in an industry that is already famously known for not hitting release times is not really useful. I think it's more useful to say "Perl 6 is already useful for many tasks, feel free to download one of the implementations and take a look. If you find it lacking in some area, let us know and maybe we can fast-track a solution for that." IMO that's not only more accurate and truthful, it's also much better way to draw in potential users.
Yes, predicting schedules based on volunteer effort is much more difficult than predicting schedules based on paid developer effort. Your proposed wording is a lot friendlier, but it doesn't match my experience with the project. (However, I've already written far too much on that subject, so I won't bore everyone again.)
Well, I know it's in use in a few places now (I personally know someone using it at Google's engineering as a tool to retrieve and collate information, utilizing the newer async features), but of course there are still many rough spots. Whether it fits the bill for that person will be highly dependent on what they need.
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).
I'm by no means a perl expert having only written maybe 10k lines of Perl but ...
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.
Perl was the first scripting language I really learned when I was an intern at Sun. I read the whole Camel Book my first couple weeks there. I had an awesome sysadmin mentor that was a Perl guru, and when I asked for help he would give me mysterious one-liners that did powerful things, simply saying "use this". I had little idea what I was doing at the time, but it was awesome.
I use Ruby now for most scripting, and it is also awesome, but a lot less mysterious.
Hmmm... This article strikes me as relatively missing a few things.
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."
> 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....).
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 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.
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 think the various Unicode whitespace characters are likely to gain more use generally.
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 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.
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.
Writing good code in any language is remarkably time-intensive to learn. There are any number of ways to mess up code and the coding patterns and antipatterns are different in any language.
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.
A few days ago I was at a Half Price Books store. Something which struck me at the moment was that while there were probably 20 Perl books (some of them duplicates), there wasn't a single Python book. I took it as in indication that Perl is in decline and people are unloading their personal perl library and nobody is buying the used ones; meanwhile, people are holding on to their Python books and ones which show up get snapped up.
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.
In terms of expressiveness I think Python falls closer to Java than Perl. People make fun of Perl's sigils but I think Python's magic underscores and 'self' everywhere are much uglier in a verbose way. And no one will ever convince me that significant-white-space and not having block enders are good ideas, it makes refactoring and copy-pasting code hazardous. And I don't understand why every language hasn't added Perl's native regex syntactical sugar, it's a huge win for many problems.
To your last point about regexes: I think the general idea is to discourage their use, at least as a default. It is so easy to use them in Perl that they are used way too much, e.g. when you could do a regular (and faster) string search.
That's a lousy reason to not include them. Cars are used to much and people really should walk and bike and take the bus more, but we're not about to make cars more difficult to use because of that.
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.
But isn't that a crime of premature optimisation?
Perl's integration of Regex makes them easy to use and they fit naturally in the language, a lot more than in most implementations.
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.
It's more a matter of different design taste than it is an optimization.
(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)
> People make fun of Perl [...] but I think Python's [...] are much uglier
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.
I don't understand this analogy, unless either C or Haskell allows invisible characters copied and pasted incorrectly to cause semantic errors. (I've used both Haskell and C for non-trivial purposes and can never recall that to be the case.)
C:\Users\Mithaldu>perl -e " my $variable = “(＃｀д´)ﾉ”;"
Unrecognized character \x93; marked by <-- HERE after ariable = <-- HERE near column 18 at -e line 1.
That may be, but this thread seems to be "Python is a language with serious deficiencies because whitespace!" If that's the case, then people are pitting Python up against all other languages, not just Perl.
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.
> 2) When you copy-paste Perl (or C, or Java, etc) code, do you not reformat that code anyways?
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.
Yes, you have to think a bit more when reformatting Python, but it is worth it as you never get the missing brace problem that you can get when moving Perl blocks around. Its enough of a benefit for me.
The point is: I don't have to think at all. Reformatting code with Perl is a matter of a save hook in the editor or a pre-commit hook in your VCS. No thinking necessary, it just works.
> 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.
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.
Perl to Python convert here. At first I hated the whitespace, but when I went back to Perl, I moved some code about and "lost" a brace. You never get the unmatched brace problem in Python.
I used perl as my go-to general purpose language for years and years until I joined a python team in 2004, now the only thing I use perl for is as a sed replacement. The perl6 stuff just killed all its momentum dead, and then it seemed to drop off the face of the earth.
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.
It seems the perception of Perl 6 as a long delayed update to Perl 5 is a serious problem for the languages. Perl 6 is not really the next version of Perl 5, it is more like another language.
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.
When I came out of Google I could see the Python features that endeared it to Googlers (although I expect Go to replace Python pretty much everywhere there eventually). Blekko is a perl shop and it certainly felt a bit strange, but having gotten acclimated I can see the appeal. Every now and then I come across some really idiomatic perl and find it mind bendingly opaque, but for the most part I can code up a quick script in it faster than I ever could in Python.
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.
> 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.
Languages that target and reach large numbers of beginners tend to do well. PHP tends to be the primary example, but BASIC and all forms of it continued by Microsoft are another. When any newb can sit for a few minutes with your language and a HOWTO and make a functioning (web)app it has a chance to be successful.
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.
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.
I'm going to take a moment to vent about Perl. My company was experimenting with it as an alternative to Ruby based on the enormity of available CPAN modules.
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...
I can't help but think if perhaps you have decided to learn it, rather than explore it, maybe your opinion would be somewhat different.
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.
The only known benefit of CPAN - automated test running, has never once proved helpful.
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.
Troll harder, greenhorn. (account "metsgrets" created 7 hours ago)
> 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.
> Some modules are hosted in foreign countries that intermittently decide not to download. Builds have broken due to inability to download from a mirror.
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) { ...
Yeah, I don't understand why people want to hate on perl for no reason. Perl people don't generally hate on other languages much (maybe aside from Java and PHP).
>>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.
Contrary to popular belief Perl is still very much alive and healthy. Sure, it has baggage, but so does any language that kept evolving for decades. If you want to know what Perl really looks like these days take a look at the Modern Perl book (http://modernperlbooks.com/books/modern_perl/) and Mojolicious web framework. (http://mojolicio.us)
I understand that this is written from an academic point of view and focuses on scientific computing, but writing "upstart PHP grew in size to the point where it is now arguably the most common language for web development" is a serious understatement.
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.]
"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.
I'm not sure why every Python lover has to be Perl troll. No seriously. The author is clearly a Python fan boy, and he can very well write a good technical article to illustrate Python's goodness. I'm sure we all can appreciate that. But you don't have to troll Perl endlessly to do that. Besides all that, I've been hearing this Perl is dead thing since what, 10 years? If that was really the case Perl should not only have died, but should have even been forgotten from our very memories.
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.
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.
100 comments
[ 6.4 ms ] story [ 178 ms ] threadBoth 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:
and: don't make it feel like the best language for the job.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.
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:
What this would do is create a class with two properties (foo and bar), and two methods. The methods are delegated to stored procedures, and properties mapped into procedural arguments by name (the second example overwrites $self->bar with undef). I have created a class that does something with only declarative code. The code is neat, clean, understandable, and predictable. Again I could build something like this in Rebol or (once there is Pg support) Red, and this sort of thing could be done in Lisp too.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.
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.
[0]: https://github.com/perl6/std/blob/master/STD.pm6
[1]: http://en.wikipedia.org/wiki/Perl_6_rules
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).
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.
I use Ruby now for most scripting, and it is also awesome, but a lot less mysterious.
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.
"Swiss Army chainsaw" is the correct quote (as can be verified by following the source link provided in the article).
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.
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:
[1] I guess I should specify "if you are using a decent editor".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.
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.
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.
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.
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.
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.
https://news.ycombinator.com/item?id=7220167
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...
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.
> Some modules are hosted in foreign countries that intermittently decide not to download. Builds have broken due to inability to download from a mirror.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.
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.
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.
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.
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.