Perl far from dead, more popular than you think
royal.pingdom.com
royal.pingdom.com
I can think of two strong arguments against picking a less-discussed (dying?) language:
1) Anecdotally, the top 1% of programmers (the people you really want to work with) will go to the tools that make them the most productive. The reason there's so much hype around languages like Ruby is that it makes programmers feel more productive and happier. The kind of programmers that go online and talk about these things after hours and argue about minor semantics are the passionate ones, and the most likely ones to rock from 9-5.
A 2% increase in productivity matters to a programmer that already gets twice as much done as an average code-monkey.
2) One also has to look at what languages are being learned by new coders. Code today might need to be maintained in 5, 10, or 20 years (let's hope not...). If Perl coders are sparse now, what happens when you need to hire a contractor at 2am in 10 years? You don't want to pay for one with an obscure skill-set.
I'm a firm believer in choosing the best tool for the job, and not jumping on the 'newest thing' every time a new blub gets an endorsement from this year's DHH, but; ceteris paribus, I'd pick a language that's gaining momentum in the world, not losing it.
2) A language that is currently gaining momentum is not necessarily a language that will still have that momentum in 5, 10, or 20 years time. Perl popularity reached its peak years ago, then slowed down and has now settled and remained constant for a number of years. Given the kinds of mission critical applications that have been written and are still being written in Perl, with all my respect for Ruby (which I think is a fantastic language) I think it is a safe bet that in 20 years' time there will still be more Perl programmers than there will be Ruby programmers.
But, making bets about technology 20 years out is a risky game. 20 years ago, there was no Java (and now it has come and gone as The Next Big Thing), JavaScript, PHP, Ruby, or Python. Perl was just getting started and Haskell was mostly just a gleam in some academic's eye. All of those techs are still on upward trajectories to varying degrees, and some rose faster than others, and some (Haskell, for example) have only recently started to see a burst of activity and interest.
In other words, I don't actually have any idea what's going to happen in languages, but I suspect that in 20 years, it probably won't be recognizable as anything we're using today. Because the languages most used today for new projects did not exist 20 years ago. But, I do have a lot of reasons for believing that JavaScript will slowly, but inevitably, become a dominant language for new applications on the server-side, just as it has become the dominant language on the client-side for new applications.
Perl, Python and Ruby are quite similar scripting languages -- same paradigm, very similar niches. Modern Perl today is arguably in a good position for productivity (see Moose, CPAN, Best Practices book, Perl 6 getting ready for publishing, etc).
The reason we see the flame wars and hype seems to be competition; these languages fill the same niche.
Ruby looks quite nice and Python seems usable. But personally, I find the hype and language war mentality you see every time Perl etc are mentioned as distasteful. I would be embarrassed to be identified with that.
Edit: jrockway already did a good job of beating this horse to death, it seems.
I think you answer your own question here. Perl seems dead because the Perl articles have titles like "Perl's Not Dead". If a language's supporters have to argue for its very existence, the language can't be doing very well. And with many languages very visibly growing, not being dead isn't enough, if a language isn't growing, it can easily seem dead.
An article like "Why Is Everyone Excited By Perlfoo, The Latest Perl Library That's Transforming The World" would actually be a better argument that Perl had life in it.
You don't think a defensive attitude might have something to do with finding "Perl is dead/unreadable" trolls every time it is mentioned on the net? Including on HN.
I think of perl as a replacement for C. We're using it as a system language, doing things like running epoll event loops, sending/receiving udp packets, mmapping files, etc.
IMO perl, python and ruby are all great choices for a project. Perl seems to be unfashionable these days, but we picked it because it came out the fastest on the benchmarks for what we're doing, and being the oldest is has some of the deepest library support through CPAN. The pragmatic-vs-idealistic attitude of the community is also a plus for us.
Terrible article, it ignores so many of the issues that have directly led to Perl's downturn in popularity and just hand-waves that Perl is still alive and kicking. The phantom of Perl 6 has been a weight around the community's neck for years, and the incremental 5.x releases with unrealized promises of 6 have probably driven away many developers to newer, sexier languages, that can deliver a major release in under a decade.
Again, I know that this isn't a valid argument, but it's enough for me to focus on other languages when I'm toying around with ideas.
Did you know that Guido switched jobs in spring 2000 (not a typo) to work, in part, on Python 3000? Python 3 is older than Perl 6, and it's a much less modest project. Compare Perl 6 rules and grammars to anything Python 3000 invented, for example.
That said, I very much like what I've seen/heard of perl 6, and will certainly learn it once it's production-ready.
1. New Style Classes 2. Closures 3. List Comprehensions 4. Generators 5. Decorators 6. The With Statement
Those are just the big ones -- there are a lot of other changes as well as tons of library improvements.
In the meantime, Perl made five major 5.x releases, adding a ton of features, many of them inspired by Perl 6 and documented in "Milestones in the Perl Renaissance": http://www.modernperlbooks.com/mt/2009/07/milestones-in-the-... .
As far as I can tell, Guido's goal with Python 3000 was not to invent anything. It was to clean up the language in minor ways. That's well and that's good, but it's silly to compare that with Larry's goal for Perl 6.
Ruby: 5,978 Python: 9,802 Perl: 22,172
If Perl is dead, then what are Ruby and Python...
This results in:
"The total number of people that have ever used Ruby is greater than the rate of people switching to Perl."
"Clearly Perl is dead!! My decision to use Ruby is justified with mathematical fact!"
It would be amusing if people argued over colors and ice cream flavors in the way they argue over programming languages. "Chocolate is dead!"
Some options I've tried and what I didn't like:
Haskell is much faster and a better language in general, but just doesn't have enough usable libraries for writing web applications. (My first Haskell web application was an application that generated an image of the latest Twitter post from a user using a given hashtag. It went together quickly enough, but I didn't really feel like "wow, this was a great web development experience that has changed my life". I do feel that way about Haskell for text processing and system programming, ironically. It definitely beats Perl there. But for simple and complex web applications, Perl is much better.)
CL has the best development tools of any language, so I really wanted to like it, but it doesn't really have a coherent community. I started writing a web application in CL to allow clients to email us files, even when they were behind a firewall that blocked outgoing email and ftp (!). This didn't go too well; I really didn't like cl-who or html-template, and there were no other options. (People in #lisp agreed with me, but their advice was to "just write my own". The answer to every question about libraries on #lisp is "just write your own".) I started porting Template::Refine from Perl to CL (see template-refine and cl-template-refine on my github), so I could generate HTML. closure-xml and cl-stp are great XML libraries, BTW. The next thing I wanted was a dependency-injection framework. There were no libraries for that, so I had to "just write my own". cl-junkie is on my github (junkie, "dependency injection", get it?), but I got bored and didn't finish it. I ended up not needing the app anyway. Too much yak-shaving lets you get over the excitement of your actual idea, and leads to it never being done. With Perl I can get a working application before I am not excited anymore. (Then I get excited about cleaning up the libraries, and do that afterwards. Bootstrapping++)
Moving along, there is Scala and Clojure. Scala is a fine langauge, it really "gets" functional programming. Clojure is not to my liking. (And it's not the parentheses; I have a shit-ton of "production" Emacs Lisp lying around.)
These languages are both cases of the "oh, just write your own libraries" community problem. Even worse is the potential to reuse Java libraries. I don't see the point of using a nice functional language with overly-verbose libraries that are going to randomly throw NullPointerExceptions. Many other problems I have with Java carry over to Scala and Clojure if you use Java libraries. (Design pattern overload, extremely poor object system, no types that cannot be null, etc.)
(I know I said "bootstrapping++" above, and that you can bootstrap clean Scala/Clojure libraries off the messy Java ones. But it's just too painful for me. It's not boring, it's just pure pain.)
I use Scala for Android applications simply because there is absolutely no other option. (I couldn't get any Clojure code to compile, and I am certainly not going to use plain Java. I prefer Scala to both anyway, but obviously I would prefer various non-JVM languages to those.)
So then there are Ruby and Python. Both are basically Perl with very tiny superficial differences, so there is no reason to waste my time becoming good at those. (Similarly, if you are a Ruby guru, you will probably not be too excited to switch to Perl. Same language, except you aren't a guru anymore.) I think Perl's libraries are, in general, more extensive and more mature than Python or Ruby's. But for the beaten path, you will do fine with any. Ruby has this "Rails" thing that I hear is pretty popular.
One thing I've noticed, though, is that the Perl community is better at stealing from Ruby and Python than those communities are at stealing from us. DBIx::Class is significantly more advanced than any Python or Ruby ORM that I know of, KiokuDB is the only sane object database among those three languages, etc., etc. But Ruby and Python still don't have anything close. OTOH, Python's WSGI and Ruby's Rack are great ideas... so the Perl community now has PSGI and Plack. So you can see why I find it compelling to stick with Perl. Good ideas eventually migrate over here, and the community supports them.
Anyway, if I had a point, it's that there is no reason to disqualify Perl from "what should I write my new app in" discussions, except ignorance. Perl has its tradeoffs, but so does anything else available. (Don't let "I last used Perl in 1995, so Perl must still be the same as it was in 1995," ruin your next application development project!)
Write an algorithm (or app) in your favorite language of the three. Then port it to a different one of those three.
Now port to Common Lisp or Haskell, and see how your code feels different.
I find that Ruby/Python/Perl basically let you write the same program with different syntax. "$self->foo" instead of "@foo". I find that Haskell changes the way you actually program. Example: Nobody (except me) uses a type like Haskell's Error monad in Perl; they use exceptions.
(Similarly, look for a "web framework" in Perl/Python/Ruby. Perl has Catalyst. Python has Django. Ruby has Rails. They are all different, true, but the idea is the same. If three people each started the same project on those various frameworks, the end result, code-wise, would be very similar.)
As an experiment port this Ruby to Perl:
def each (arg,*more_args)
( [] != more_args ) ?
arg.each {|l| each(*more_args) {|r| yield [l]+ r }} :
arg.each { |r| yield [r] }
end
each( 1..2, 'a'..'c', 'A'..'D') { |args| puts args.join " " }
def fib():
fn2 = 1
fn1 = 1
while True:
(fn1, fn2, oldfn2) = (fn1+fn2, fn1, fn2)
yield oldfn2
g = fib()
for i in range(20):
print i, g.next()
sub fib() {
my $fn2 = 1;
my $fn1 = 1;
gather loop {
my $oldfn2;
($fn1, $fn2, $oldfn2) = ($fn1 + $fn2, $fn1, $fn2);
take $oldfn2;
}
}
my @g = fib;
for ^20 -> $i {
say $i, @g.shift;
}
I don't know enough Ruby to make heads or tails of the first example, though...
$point->missed
That said, I'm in agreement with your basic point. On the whole the scripting languages (including JavaScript) are much more similar than different.
I am talking major differences, things that are so fundamental that you can't really steal. Looking at Haskell, I see things like lazy evaluation, purity, static typing and type inference, etc. Very, very different from Perl.
In Scheme, I see the "call stack" as a graph of frames, not as a linked-list as in C. This is quite radical.
But in Ruby and Python all I see are different built-in functions, some with special syntax. (Generators, list comprehensions, etc., etc.)
I know Perl far, far better than I know Ruby or Python. But I can't easily reach for the abstractions in those examples within Perl.
I can. I hope you are considering CPAN as part of Perl, because "core perl" is a very, very outdated and broken programming language. I think I would even prefer Java!
Python has docstrings and list comprehensions and keyword arguments and generator functions and readable syntax. To me, these are all significant differences from Perl.
See also Eric Raymond's piece "Why Python?" at http://www.linuxjournal.com/article/3882
(There a few list comprehension modules on CPAN, but they are all implemented wrong. A correct implementation is not difficult, but I personally don't see the value and haven't bothered to implement it right.)
From http://linuxdevcenter.com/pub/a/linux/2001/11/29/ruby.html:
Stewart: I gather you had worked with both Perl and Python before creating Ruby. What bits of Perl did you incorporate in Ruby?
Matz: A lot. Ruby's class library is an object-oriented reorganization of Perl functionality--plus some Smalltalk and Lisp stuff. I used too much I guess. I shouldn't have inherited $_, $&, and the other, ugly style variables.
I upvoted for this. Perl is kind of the "English" of the programming world, picking up whatever useful artifacts from other ideas it can without being concerned over language or design purity. Perl's design concept is to use whatever's best - i.e. be agnostic and be pragmatic.
This has it's good sides and bad sides (just like English). Perl can be both easy to learn the basics of, but very tricky in advanced usage, and it suffers from the "hard to maintain" problem. But it can be a nice dense language that maps well to a reasonably logical thinking process (it's probably by semi-intention since L.Wall is a Linguist).
Perl 5 is certainly showing its age though.
Perl has had this stigma forever and the community has compensated in many ways; Perl Best Practices, 100s of Test:: modules, Moose, etc., so you actually have a pretty good chance of writing maintainable software. One feature I consider key to good OOP are "roles", and only Perl, Smalltalk, and Haskell really have those.
People like to repeat things they hear, but if you think about it, Perl is not at all unmaintainable.
But I've also choked when trying to work on trivial scripts I tossed together in a rush.
I've always found Python to naturally follow more maintainable code patterns -- and it seems really designed with a philosophy towards that goal. But I've always liked Perl better since the code flows more like how I think (at least in a write once kind of way).
We're pretty much agnostic about languages; we prefer dynamic languages, but not much beyond that. Our website is running on Drupal and several custom modules in PHP. We'll be adding those afore-mentioned web services via frontend PHP code, but the backend will be Perl. Haskell might make an appearance at some point in the future for concurrency work where performance matters, but for now, Perl is plenty fast and has reasonable concurrency mechanisms for our needs.
So, we're still cranking out tens of thousands of lines of Perl every year, and will be launching a couple of new products in the next six months also written in Perl.
But, I will mention that our products directly and easily support PHP, Ruby on Rails and Django deployments, but not Catalyst. And it's because we're simply not hearing requests for Catalyst from paying customers. Maybe the Catalyst developers are more old-school and don't trust a control panel (even one written in Perl), or maybe there's a helluva a lot more PHP and a handful more Ruby on Rails and Django developers out there (note that PHP developers using our software outnumber RoR and Django developers to a degree that makes the latter two practically noise in the signal). So, realistically, I have to agree. Perl is a niche language for new developments, but then again, so are Python and Ruby.
http://duartes.org/gustavo/blog/post/programming-language-jo... has some interesting trends. From what i see there, i'd say perl is probably still alive but slowly dying.
My hopes have been on parrot for perl. But after reading about the new perl version and its ridiculous new "features", i am convinced that perl will die when parrot breaks module compatibility with cpan, because noone will port modules, yet care for the new perl.
Did you read the linked article?
> i am convinced that perl will die when parrot breaks module compatibility with cpan, because noone will port modules, yet care for the new perl.
Look into projects such as Plumage, Blizkost, and Perl 6 proto.
There's also jifty (http://search.cpan.org/dist/Jifty/lib/Jifty.pm) which seems a little more magic-y (ie, rails like) than Catalyst or Mojolicious.
I have a hard time hiring developers that don't know at least a smattering of the Rubbish Lister.
Two that I'm aware of in the Los Angeles area are CampusExplorer and The Rubicon Project.
Perl 5 is used extensively to automate tasks at companies; for example, in the semiconductor industry. I've found that most of the engineers working in design are basically fluent in Perl, and choose it for anything serious. I've also seen TCL used, but that's mostly because so many tools support only TCL APIs. Python has caught on in some places, but it is still mostly appealing to pure software developers.
They show a steady decline in Perl activity over the last decade:
https://www.ohloh.net/languages/compare?measure=projects&...
Perl is the 5th most popular programming language on github (in terms of unique non-fork projects that contain some code in that language). It is ahead of Java and PHP, for example.
http://www.indeed.com/jobtrends?q=perl%2C+php%2C+python%2C+r...