Perl 5 Is Dying
use.perl.org
use.perl.org
Perl 5 is obviously on the way out and Ruby/Python are coming in. But they're just passing by each other headed the opposite direction right now. The stigma Perl has just makes it seem worse than it is objectively.
Today Perl 5 is still a very reasonable choice IMHO. I'll switch to Ruby or Python full-time at some point. If Perl 6 ends up being better at some point I'll switch to that. We used to have to choose between C++ and Java and Perl. Perl was so much nicer. Now we have to choose between three languages that are all heaven by comparison. I don't really care which "wins" because I will no matter what.
Tossing aside this obviously flawed TIOBE thingy (Delphi, wtf?) I see no evidence of this. CPAN contributions are accelerating, not flat-lining. Perl's domination over Python and Ruby in the corporate environment continues.
I don't share that feeling and I don't see any hard evidence of it. By all reasonable metrics perl continues to grow.
If you're not already good at something, of course it's easy to say something else doesn't work or isn't any good.
This has improved with mongrel_cluster and (more recently) Passenger, but the memory footprint for a Rails application continues to be an issue, even relative to other dynamic languages.
Interpreter level threads and multi-process based techniques have tended to be common approaches in both various Perl and Ruby projects I've worked with.
For a good summary, watch Steve Yegge's presentation, "How to Ignore Marketing and Become Irrelevant in Two Easy Steps". (http://blip.tv/file/319044/)
Marketing is often what developers brush off as "the other stuff" without really understanding it.
Agreed. Trying to convince programmers to not write it off entirely (such as in the presentation) is a step in the right direction.
FWIW, I think a few languages (Python, for one) have actually been marketed reasonably well.
http://www.indeed.com/jobtrends?q=python,+perl,+ruby,+php...
The numbers say what most people know: that set of four languages contains 1 that is mature and 3 that are growing. One of them is growing fairly rapidly relative to where it was when the data set started out.
I used to do Perl and now work in a Python shop, and the only Perl feature I really miss is closures (as opposed to Python's hobbled-by-design "lambda" construct).
A few years ago, Perl had twice as many projects as Python; now it's almost even.
Of course, I'd rather code Python usually.
From the PyPI front page: "There are currently 5256 packages here." According to cpan.org, the CPAN is up to "14749 modules" -- dunno how many distributions that makes though.
That said, I think you can still be responsible and use Python instead. ;) Might take you a few more keystrokes though.
we've had 90% complete python tools rewritten from scratch in perl because perl is so superior.
disclaimer: i'm a recovering ex-sysadmin
What about Python was getting you stuck at 90%?
There are tens of thousands of Ruby developers and hundreds (if not thousands) of companies making significant amounts of money, all backed by Ruby.
Who says Python programmers are all jerks?
That they're cold, humorless perfectionists who alienate new and prospective users?
That they have inferiority issues because they're not as popular as they are right?
That they occasionally lapse into self-parody?
And of course competition is good.
And I don't think the community alienates new users, on the contrary I find it very helpful.
I think they had to either deliver perl6 a few years ago, or not doing it at all and continue to improve perl5. But in this situation, many people are just not willing to invest into perl and are looking for the greener pastures.
I would guess that VB is maybe used by Excel users who write little scriplets for their Excel sheets, but rarely by programmers.
It is like saying "PCs and cars are the most popular products in the world", since I am not interested in cars, I simply don't care. I only care about the popularity of PCs. The data is correct, but it is irrelevant to me.
Sure, it's always possible to set up the selection criteria ("only language used by companies I like") such that the answer will be what you expect - but how is that valuable?
But if you define competing as "what language should I learn in order to get a job" then yes, they are competing.
PS: I know, and have used, both in different jobs, so it's not really competition because you can do both. But if you are only going to learn one, then yes, they are competing.
No language can be called "successful" if only 100 internet startups use it. Look at languages that are used in the real world, and don't artificially limit your selection process.
I might be OK with making the criteria: languages used for new programs (rather than languages in use for a useful product). I'm not sure what their criteria is though.
Maybe by numbers horses and mules are still the most important means of transport in the world. Doesn't mean that I should worry about buying a horse now.
If a car company thinks they are in the car business and not the transportation business they will go bankrupt as soon as new technology arrives.
Actually - that pretty much is happening right now. Car companies are selling "the experience" of driving a car, they are selling prestige, and looks. They are not selling transportation (just watch car ads).
That can work fine, and did work fine, until people don't have money for prestige and looks, and just want transportation. And then the company goes under.
So pretending any language that can't be used on a web server does not exist is not a good idea.
Specializing in certain languages is OK obviously, but don't start thinking the others "don't count".
I like Ruby and think it's a very fine language. I've implemented a couple of small projects in Ruby, and had fun with it. I find it as readable and writable as any language I've used. But, I'm confident I could accomplish almost any task I would ever need to accomplish faster in Perl, and the result would run faster, smaller, and more reliably. The same is true of Python, though to a lesser degree (though some of the problem features in Python are more uncomfortable for me...closures, in particular), but at least it has some Unicode support built in (or bolted on with reasonable competence), and the VM tends to be closer to the speed of Perl than Ruby.
Python 3.0 did just spring into existence while we were having this discussion, and it finally has proper Unicode support. So, there's one less reason to choose Perl over Python.
If Ruby has Unicode support in 1.9, and 1.9 were widely available, then I guess that'd be true of Ruby as well. But, I just went to the Ruby website and it looks like 1.8.7 is the Ruby version available. It doesn't have Unicode support, does it?
However, Ruby 1.9 has been around for about a year now (considered a "development" release) but Ruby 1.9.1 will become the "production" version of Ruby when it's released in the next month (yeah, I know that makes no sense). The current preview releases are pretty spot on though - so we're in a transitional phase. Ruby 1.9's performance is also somewhat better than that of 1.8.
On the 1.8 front, Ruby 1.8 has had what's called KCODE for years now, which enables Unicode support for various bits and pieces (primarily regular expressions). More info on this here: http://blog.grayproductions.net/articles/the_kcode_variable_...
Granted, the leading Perl 6 implementation is still a little over a year away (though Parrot hits 1.0 in March, which is a pretty cool milestone in and of itself), and I imagine Ruby 1.9 will be widely available long before then.