The phrase "love me, or hate me, but don't ignore me" is a serious marketing mistake, in any context. It's a transparently selfish cry for attention. Rather than offering something great to the audience, you're trying to win pity points by subtly accusing them of poor judgement: You should be paying attention to X, but you aren't!
Believe me, if people wanted to pay attention to your project, they would find a way to do so. And if your project is being politely but firmly ignored, and you're not getting the message, it is not the audience's problem. They've responded to your message. That response is somehow not getting through to you.
Perl needs no more criticism. Even the criticism of Perl is old news. Yegge's essay, cited elsewhere on this thread, is five years old. I suspect he has little to add to it, and neither do I. I'm glad Perl's users are happy and productive, I was really grateful for it ten years ago, and I have seen nothing that makes me regret my decision to stop using it.
The phrase "love me, or hate me, but don't ignore me" is a serious marketing mistake, in any context.
OK, but don't think that one blog is the voice of the Perl community. One blog shows the opinion of one blogger; nothing more. Amazingly, "the Perl community" does not have one single voice, as it consists of tens of thousands of people all over the world.
(Also, if blog noise was a good measure of langauge popularity, it would be clear that the most popular programming language right now is Go.)
Believe me, if people wanted to pay attention to your project, they would find a way to do so. And if your project is being politely but firmly ignored, and you're not getting the message, it is not the audience's problem. They've responded to your message. That response is somehow not getting through to you.
One thing I've learned from social news sites is that this is not correct. People mostly want to find ways to justify their insecurities. If they don't know very much about programming, but pick language X, they will hang around people that like language X and that say good things about language X. Then they feel smart by association, and since they have lots of friends saying lots of good things about language X, they can feel good for "making the right decision". Being down on language Y and language Z also help reinforce that feeling. If language X is unpopular, then they're clearly in the so-much-smarter-than-everyone-else majority. If language X is popular, then it's clear that it's the best. If it weren't good, why would it have so many users?
And so on.
These are not technical arguments, they are just emotion. Confusing them with technical arguments is quite silly.
Yegge's essay, cited elsewhere on this thread, is five years old. I suspect he has little to add to it, and neither do I.
It's worth noting that Perl has changed significantly in five years. All of that criticism has resulted in many major changes in how people use Perl, such that the criticism is probably no longer valid.
But of course, people like to recycle that criticism because They Picked Something Else, and drunken rants from five years ago make them believe that Something Else is the right choice.
(I am not sure how valid it was five years ago, actually. It was more a criticism of Amazon's hiring practices, or perhaps a note about how poorly managed the programmers were. I would love to write an essay about how bad Python is, because I have seen some absolutely horrible Python code... but I realize that it's bad because it was written by someone who didn't know how to program, not because Python is intrinsically bad.)
Have a look at MooseX::Declare and MooseX::MultiMethod then - the ability to add syntax to the language combined with a stunningly flexible, extensible metaprotocol is a huge win.
About the only object system I can pull similarly beautiful tricks in is CLOS. python and ruby don't even come close.
Oh, and before somebody yells "but but it's a library", that's a good thing - it means the syntax and semantics can be changed without needing to produce a new incompatible interpreter version. Ruby 1.9 and Python 3 have both run into adoptions problems because of compatibility issues, whereas the Perl5 language v10 (and soon v12) don't/won't have nearly the same adoption problems because we focus on enabling libraries to improve the language rather than on baking in additional features.
Not that there aren't advantages to shoving things into the compiler and VM directly, but I'm not sure I believe that in this case they outweigh the advantages of keeping things as libraries.
Actually guilt works as a marketing device, but only for the short term. Guilt marketing might force someone to buy a particular brand, but it doesn't change one's attitudes toward the brand overall.
Perl has been my startups' secret weapon, and I'd rather the competition didn't know about it.
Perl let us deal with large volumes of data, at high throughput (there are several ISPs, Universities, and fortune 500 which use our product to protect their mail infrastructure from DDoS and Spam). At a former company it let us collect, parse, store, audit, and make predictions against millions of web hits per day, in close to real time, with cheap infrastructure. Perl has been solidly stable - it just runs - keeping our ecommerce infrastructure making money.
It has had few security issues over the years. It has had few backwards incompatibilities between versions over the years. As a component of our products, it's given me relatively little pain in performance, reliability and security.
Development wise, I can't count the amount of time we've saved over the years thanks to not having to reimplement something because it's on CPAN, with a sensible license, with doumentation, tests, and in an easy to find and search location. As for code quality, Perl has great support for testing, support for automating code review (Perl::Critic), and a community of developers that are constantly making things better - but without breaking things that worked in the past (Moose has done amazing things for refactoring ugly OOP code, and you can use it with any of the other older OOP stuff).
I use it because it works well, seldom breaks, and causes me less hassle than anything else I've tried (C, Java, Python, PHP, Ruby). I've spent serious time with this language; I've maintained ugly old code from 10 years ago, and giant million++ line projects written in it. It has warts, sure, but what doesn't? I don't care; it's reliable. Big jobs, little jobs - it gets the job done. And that, to me, is more important than high minded ideals about aesthetics and purity.
Strangely, the investment bank I used to work at relied heavily on Perl, without most people even realising it. A huge volume of live rates information formed the basis for a large number of Seriously Enterprise Applications, all with architecture groups and best practice gurus and all that stuff. What was ironic was how the rates got into the bank: six instances of a single Perl script that almost noone knew about, connected to the Reuters Market Data System. And the reason that it was so poorly known was simple: it was cronned to start and stop at particular times during the day, and in the four years that I was there, it went down once, when the box it was on suffered a hardware failure.
Funnily enough, a few more people knew about it after that, whereupon I got funding and contingency hardware thrown at me until I could confidently tell the powers that be that a box failure would be followed up by immediate failover and a whole bunch of alerts being generated.
Overall, I think that's where Perl does a really good job: in holding stuff together. While the Rubyists and Pythonistas are arguing over who's got the better language, Perl hackers are just getting stuff done.
This thread gives me serious deja vu. It seems like every time someone says they like Perl, the exact same arguments usually show up in duplicate. Someone posts Yegge's "I hate Perl" article. Three or four clever souls post something like, "I ditched Perl 100 years ago and never looked back". Then chromatic comes along and says something not-negative about Perl, and someone else asks him for conclusive proof.
Anyway, I can't find words intense enough to describe how I am feeling right now, but it seriously disturbs me. It feels like the Universe is recursing on itself, and I am in two of the Universes at the same time. I had to check the date on the comment three times before I believed that it was real. Then I had to do some tests to make sure I was not dreaming. I can't breathe under water right now, so I figure I must be awake. But I can't believe it. This. Again.
I agree that a lot of Perl bashing is thoughtless. And ideology when it comes to programming languages is just stupid.
I'm sure there are plenty of cases where Perl is the best tool for the job. I know it's very good for large quantities of string parsing, for one.
You seem to know a thing or three about Perl- do you have advice on other cases where it's the best tool to use? I think that might be the most effective form of countering the arguments you dislike, and it would be very practically useful too.
Your life moves forward one second at a time. And if a project is part of your life -- if you visit it every day, and follow it closely -- it also moves one second at a time.
But to the general public, the apparent flow of project time is defined by its managers. Time is measured in milestones. Major book releases. Major new adopters of the project. Major upgrades. If you want time to move forward, you need to clearly define and communicate your milestones, to give the community something to rally around and synchronize on, to provide news hooks and talking points and historical points of reference. If your project has fuzzy milestones, it will feel stuck in time.
It's storytelling. People don't want stories to move in real time. They want plot points. Time moves nonlinearly in a story. Nobody has the time to actually live through every single minute of somebody else's life.
This is why companies issue press releases, novelists and filmmakers put out sequels (a sequel helps sell more copies of the original), and software publishers keep releasing upgrades (each upgrade bumps up sales, if only because it gives news agencies and potential customers a reason to check out the product again.)
If Perl feels like it's stuck in time, it's because the community stopped time nearly a decade ago. They blocked future major releases of Perl 5 by assigning the name "Perl 6" to something else, a move that makes the invention of New Coke look like marketing genius, and which perhaps explains why -- although Perl 5 is said to "be much better than it was five years ago" -- none of the featured books on books.perl.org are much less than five years old, and many of them are nine or ten. New ideas are sold by new books, and new books are sold by version upgrades. Just ask the Pragmatic Programmers, who will presumably come out with the fourth edition of Agile Web Development with Rails in five years when Rails 3 ships. If Rails 3 doesn't ship, nobody will bother to revise the books, because the revisions won't sell well -- not as well as they will when they are coordinated with the news push around Rails 3.
Anywa, back to Perl. Perl 6 was announced in 2000. Then it didn't ship. Then it didn't ship some more. And now it looks as if the whole idea of shipping Perl 6 on a specific date is being deprecated:
Big news from the current Perl conference YAPC Europe 2009 here in Lisbon is that Rakudo (star) will be released in spring 2010. Rakudo is Perl 6 on Parrot, which is an equivalent to the JVM or CLI.
Is that an official Perl 6 release? Well, it is the nearest to official that you will see. The Perl 6 team are keen to point out that there will be no such thing as a official version, just different implementations
So perhaps Perl 6 will never officially begin, just as the Perl 5 described by the Camel Book (last revised nine years ago) will never officially end. And so I fear it will be deja vu all over again.
I loved perl for a long time before I started using python and, quite frankly, I don't intend nor see the need for ever having to use perl again. I respect perl for what it is and what it has enabled me to do, but when better tools come along I don't hesitate to move on.
I'd pay more attention to those frameworks if you'd say why they're interesting. I consider python/ruby/perl to be sibling languages. You only really need to know one as your primary language and then steal ideas from the other two. Node is interesting because it solves a problem: efficient long polling setup in a language I know.
Why Ruby over Perl then? The ruby peoples have great taste in designing mini languages: e.g. sass is amazing in a why-couldn't-I-think-of-that way so I pay attention to them. The best thing I know of coming out of the Perl community is the people (Michael Bayer is my hacking hero for SQLAlchemy).
SQLAlchemy's nice - wherever DBIx::Class and SQLAlchemy developers are gathered at the same conference, there will be beer, and there will probably be cursing other ORMs for not understanding what a database in. Later in the night, somebody will say "we should all use ActiveRecord instead - because it unlocks all the power of MyISAM on MySQL 3.23" and then we'll giggle incoherently for a few minutes before getting another round of drinks in.
SASS is absolutely beautiful. I think Perl5 with Devel::Declare is a better internal DSL host than ruby though - consider MooseX::Declare - you simply can't bend the ruby compiler sufficiently to do something like that to my knowledge (or Piers Cawley and others wouldn't have moved from ruby back to Perl5, I don't think ...)
Which would be the same Steve Yegge who also said:
'As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl.'
So if his essay on the state of the art in Perl5 years ago scared you off, presumably the fact he's now noticed that we're (a) moving forwards (b) a happy, pragmatic and effective community will make you go look at it now?
There's even a new www.perl.org recently released (next big project - improving learn. ...)
That's a real pity. I like Steve, but his essay demonstrates a severe lack of understanding of at least two fundamental features of Perl, namely context and lists.
Ohloh is a ... very web 2.0-y thing. Which means a lot of perl projects don't get registered, since we're not as whole an amazingly "woo! random social stuff! must register now!" community. I tried to redress the balance, discovered Ohloh's indexer had a bug that threw away half the history of my projects and thereby made them look much less actively developed, reported it twice, got ignored, and gave up.
Plus Perl5 generates a lot more search.cpan.org searches than google searches during normal use - we don't generally hit google very much because it doesn't have the information we need. So I could argue that CPAN's been getting better and Python and PHP have continued to fail at having an equivalent. And I'd be making just as much of an unfounded guess as both you and the article attuhor are by guessing web search volumes matter.
Of course, http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... shows Perl5 and python and ruby all losing ground, but the other two significantly faster. I'm sure if I tried I could find you plenty more statistics that look good for Perl5 but don't really prove anything :)
If you do Google Trends searches for "perl programming", "ruby programming", "python programming", and "php programming"; you'll notice that they all show a downwards trend.
So I think there is something deeper here than "everyone is moving away from Perl".
I avoided Perl up until about six weeks ago, when one of the best coders I know selected it for something we're working on. If it was anyone else I would have overruled the choice, but it turns out he was right.
It's an unmitigated disaster of a language, as a whole, but if your needs are a "scaffolding language" that can script something together quickly and you're using a lot of regex, I have to admit, it's a great choice.
It's an unmitigated disaster if you use it wrong - or at least if you use out of date techniques.
This is also true of C - consider things like scanf and other chunks of stdio that are preserved for compatibility but no developer in his right mind would use for new code.
Applications Perl5 written using MooseX::Declare and friends (see Task::Kensho for a good start at "and friends") is a much different thing to the high speed line noise-ish scripting perl that was the commonest sort a decade ago.
Any language that needs advocacy has already lost. Good languages are adopted by people because they solve problems better than other languages. It is a market place of sorts. As soon as you feel the need to advocate a language you are actually advocating what you use, instead of letting the language speak for itself.
The net effect of all this advocacy is possibly even negative, the more you try to ram a programming language down peoples throats the less inclined they are to give it a shot because they already have a negative experience before even trying it.
Languages with an open and welcoming, real-world problem solving oriented community tend to benefit from the people using it and talking about using it. Those that simply hawk a language as 'great' and keep on hammering on its strong points are missing the point here.
One of the reasons perl lost out not only to python but even to PHP is because it has a stigma attached to it of being (very) hard to maintain.
That may be more of a reflection on perl programmers than on perl though.
One thing I would like to know: why hasn't anyone else duplicated CPAN?
I don't know Perl, but I've had to pull things from CPAN to make a Perl script work and I was impressed.
At the moment I'm running parallel Python code on many different machines and it's a pain to make to sure that all the right packages are installed. I'm sure that something like CPAN would have helped.
CPAN is a community project, I doubt that anyone could create an equivalent for another language, it would almost certainly have to be grown as the original was.
I'm a non-perl guy working in a very Perl heavy company, so hatred of it is quite well justified, and based on discussions with many of my coworkers, it seems the Perl community doesn't want to understand why the rest of the world has moved on and has no interest in Perl anymore (resulting in this kind of bullshit "please, please, please pay attention to me!!!")
--The language sucks - yes it does. Usually the KISS principle is thought of as a good thing, except in the Perl language where nothing is ever simple or straightforward. There's 10 ways of doing every single little thing, and no two developers do it the same way. It is not a language welcoming of new developers, so as more schools and companies switch/abandon, I can only imagine it declining further.
-- it offers nothing new or exciting to most developers. If you're starting a new project or company and you already know another similar language (say, Python), Perl has nothing to offer. While it was innovative new 10-15 years ago, most of the good has long been assimilated in other languages.
-- real world perl sucks. a standard line amongst Perl monks is "you can do that in Perl!". Exceptions, objects, web frameworks, clean code, etc. You name it, you can do it in perl. Except in the real world, hardly anyone ever does, so Real World perl is as terrible as people fear. Python's strong community standards, OTOH, pretty much make sure you're almost always writing decent code.
As an example, I picked up both Django and Catalyst over the last year. With Django (python newbie), I immediately picked up decorators and started using them - both the built-in ones and my own. Its simple - just syntactic sugar for a function wrapper.
Catalyst OTOH, tries something vaguely similar using method attributes - except their are neither as powerful nor as simple/clear and despite many years of perl experience on the team, few people had seen them used, used them themselves, nor did they have a solid idea of how they work.
My point is, when you make something simple and accessible, it'll get used. When all you do is repeat "you can do that" and wave your hands about, you'll get ignored and eventually forgotten.
I work with this fellow so keep in mind there's history here between us on the subject. :)
"the language sucks" -- Is very much in the eye of the beholder. Perl works the way I think just as jQuery does. As for not being welcoming, I think you'll find perlmonks.org to be a huge welcoming community.
"it offers nothing new" -- I'm sorry, but if you already know Python or Ruby why would you switch anyhow? There's a big time investment in becoming really good at a language. No reason to switch when you have languages that can just get things done. I'm not even sure what you mean by "new". Perl is 22 years old now. Python and Ruby are both around 15. What's new here? I also find this "new" comment hilarious in light of the Python feature freeze. Things like Moose and Catalyst are new(ish) to the Perl community and they're doing great things. Further, CPAN is expanding at a huge rate, more than ever before. There's ALWAYS new stuff there.
"real world perl sucks" -- Real world code sucks period. And I do clean code. There are standards in Perl and they do evolve. You need to engage in the community a little as I think everyone should with their languages.
What is fairly obvious to me is that Python fits very well with how YOUR brain works. Perl fits very well with how MY brain works.
Just because it don't jive with you, doesn't mean it doesn't jive with others.
The Perl5 community does try and listen to the rest of the world. Unfortunately many of the people we'd like to be listening to make the sort of comments you just did rather than providing constructive criticism that we can effectively address.
The reason for shouting "pay attention" is that many people aren't even bothering to look because they're still stuck with an image of Perl5 based on ten year old information, and we'd at least like to be hated for what we are now rather than what we were back at the end of the last century.
If that upsets you, you're welcome to continue to not pay attention - but we've been getting lots of useful feedback from the people who have and so far as I'm concerned that makes it all worth while.
I've always been put off by the impression that the semantics of Perl consists mostly of edge cases. For example, the discussion of error handling here:
Which is why, if you're starting a Perl project today, you turn on warnings and strict, you choose between TryCatch and Try::Tiny and you seriously consider adding autodie to the mix.
It's extremely easy to pick up poor practices in Perl5 that make the language appear to be unsound even though it can be used extremely elegantly.
You might want to have a look at the libraries that are part of Task::Kensho to get a better feel for how 21st century perl is supposed to be written - at the very least, you might find some ideas to steal for your "sound" language of choice :)
[+] [-] mechanical_fish|16 years ago|reply
Believe me, if people wanted to pay attention to your project, they would find a way to do so. And if your project is being politely but firmly ignored, and you're not getting the message, it is not the audience's problem. They've responded to your message. That response is somehow not getting through to you.
Perl needs no more criticism. Even the criticism of Perl is old news. Yegge's essay, cited elsewhere on this thread, is five years old. I suspect he has little to add to it, and neither do I. I'm glad Perl's users are happy and productive, I was really grateful for it ten years ago, and I have seen nothing that makes me regret my decision to stop using it.
[+] [-] jrockway|16 years ago|reply
OK, but don't think that one blog is the voice of the Perl community. One blog shows the opinion of one blogger; nothing more. Amazingly, "the Perl community" does not have one single voice, as it consists of tens of thousands of people all over the world.
(Also, if blog noise was a good measure of langauge popularity, it would be clear that the most popular programming language right now is Go.)
Believe me, if people wanted to pay attention to your project, they would find a way to do so. And if your project is being politely but firmly ignored, and you're not getting the message, it is not the audience's problem. They've responded to your message. That response is somehow not getting through to you.
One thing I've learned from social news sites is that this is not correct. People mostly want to find ways to justify their insecurities. If they don't know very much about programming, but pick language X, they will hang around people that like language X and that say good things about language X. Then they feel smart by association, and since they have lots of friends saying lots of good things about language X, they can feel good for "making the right decision". Being down on language Y and language Z also help reinforce that feeling. If language X is unpopular, then they're clearly in the so-much-smarter-than-everyone-else majority. If language X is popular, then it's clear that it's the best. If it weren't good, why would it have so many users?
And so on.
These are not technical arguments, they are just emotion. Confusing them with technical arguments is quite silly.
Yegge's essay, cited elsewhere on this thread, is five years old. I suspect he has little to add to it, and neither do I.
It's worth noting that Perl has changed significantly in five years. All of that criticism has resulted in many major changes in how people use Perl, such that the criticism is probably no longer valid.
But of course, people like to recycle that criticism because They Picked Something Else, and drunken rants from five years ago make them believe that Something Else is the right choice.
(I am not sure how valid it was five years ago, actually. It was more a criticism of Amazon's hiring practices, or perhaps a note about how poorly managed the programmers were. I would love to write an essay about how bad Python is, because I have seen some absolutely horrible Python code... but I realize that it's bad because it was written by someone who didn't know how to program, not because Python is intrinsically bad.)
[+] [-] mst|16 years ago|reply
About the only object system I can pull similarly beautiful tricks in is CLOS. python and ruby don't even come close.
Oh, and before somebody yells "but but it's a library", that's a good thing - it means the syntax and semantics can be changed without needing to produce a new incompatible interpreter version. Ruby 1.9 and Python 3 have both run into adoptions problems because of compatibility issues, whereas the Perl5 language v10 (and soon v12) don't/won't have nearly the same adoption problems because we focus on enabling libraries to improve the language rather than on baking in additional features.
Not that there aren't advantages to shoving things into the compiler and VM directly, but I'm not sure I believe that in this case they outweigh the advantages of keeping things as libraries.
[+] [-] mahmud|16 years ago|reply
http://www.sciencedirect.com/science/article/B6V7S-45K1JKH-B... (Abstract, article behind pay-wall.)
[+] [-] mock|16 years ago|reply
Perl has been my startups' secret weapon, and I'd rather the competition didn't know about it. Perl let us deal with large volumes of data, at high throughput (there are several ISPs, Universities, and fortune 500 which use our product to protect their mail infrastructure from DDoS and Spam). At a former company it let us collect, parse, store, audit, and make predictions against millions of web hits per day, in close to real time, with cheap infrastructure. Perl has been solidly stable - it just runs - keeping our ecommerce infrastructure making money.
It has had few security issues over the years. It has had few backwards incompatibilities between versions over the years. As a component of our products, it's given me relatively little pain in performance, reliability and security. Development wise, I can't count the amount of time we've saved over the years thanks to not having to reimplement something because it's on CPAN, with a sensible license, with doumentation, tests, and in an easy to find and search location. As for code quality, Perl has great support for testing, support for automating code review (Perl::Critic), and a community of developers that are constantly making things better - but without breaking things that worked in the past (Moose has done amazing things for refactoring ugly OOP code, and you can use it with any of the other older OOP stuff).
I use it because it works well, seldom breaks, and causes me less hassle than anything else I've tried (C, Java, Python, PHP, Ruby). I've spent serious time with this language; I've maintained ugly old code from 10 years ago, and giant million++ line projects written in it. It has warts, sure, but what doesn't? I don't care; it's reliable. Big jobs, little jobs - it gets the job done. And that, to me, is more important than high minded ideals about aesthetics and purity.
[+] [-] dannywoodz|16 years ago|reply
Funnily enough, a few more people knew about it after that, whereupon I got funding and contingency hardware thrown at me until I could confidently tell the powers that be that a box failure would be followed up by immediate failover and a whole bunch of alerts being generated.
Overall, I think that's where Perl does a really good job: in holding stuff together. While the Rubyists and Pythonistas are arguing over who's got the better language, Perl hackers are just getting stuff done.
[+] [-] known|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
Anyway, I can't find words intense enough to describe how I am feeling right now, but it seriously disturbs me. It feels like the Universe is recursing on itself, and I am in two of the Universes at the same time. I had to check the date on the comment three times before I believed that it was real. Then I had to do some tests to make sure I was not dreaming. I can't breathe under water right now, so I figure I must be awake. But I can't believe it. This. Again.
[+] [-] paulbaumgart|16 years ago|reply
I'm sure there are plenty of cases where Perl is the best tool for the job. I know it's very good for large quantities of string parsing, for one.
You seem to know a thing or three about Perl- do you have advice on other cases where it's the best tool to use? I think that might be the most effective form of countering the arguments you dislike, and it would be very practically useful too.
[+] [-] mechanical_fish|16 years ago|reply
But to the general public, the apparent flow of project time is defined by its managers. Time is measured in milestones. Major book releases. Major new adopters of the project. Major upgrades. If you want time to move forward, you need to clearly define and communicate your milestones, to give the community something to rally around and synchronize on, to provide news hooks and talking points and historical points of reference. If your project has fuzzy milestones, it will feel stuck in time.
It's storytelling. People don't want stories to move in real time. They want plot points. Time moves nonlinearly in a story. Nobody has the time to actually live through every single minute of somebody else's life.
This is why companies issue press releases, novelists and filmmakers put out sequels (a sequel helps sell more copies of the original), and software publishers keep releasing upgrades (each upgrade bumps up sales, if only because it gives news agencies and potential customers a reason to check out the product again.)
If Perl feels like it's stuck in time, it's because the community stopped time nearly a decade ago. They blocked future major releases of Perl 5 by assigning the name "Perl 6" to something else, a move that makes the invention of New Coke look like marketing genius, and which perhaps explains why -- although Perl 5 is said to "be much better than it was five years ago" -- none of the featured books on books.perl.org are much less than five years old, and many of them are nine or ten. New ideas are sold by new books, and new books are sold by version upgrades. Just ask the Pragmatic Programmers, who will presumably come out with the fourth edition of Agile Web Development with Rails in five years when Rails 3 ships. If Rails 3 doesn't ship, nobody will bother to revise the books, because the revisions won't sell well -- not as well as they will when they are coordinated with the news push around Rails 3.
Anywa, back to Perl. Perl 6 was announced in 2000. Then it didn't ship. Then it didn't ship some more. And now it looks as if the whole idea of shipping Perl 6 on a specific date is being deprecated:
http://darkeside.blogspot.com/2009/08/perl-6-gets-release-da...
Big news from the current Perl conference YAPC Europe 2009 here in Lisbon is that Rakudo (star) will be released in spring 2010. Rakudo is Perl 6 on Parrot, which is an equivalent to the JVM or CLI.
Is that an official Perl 6 release? Well, it is the nearest to official that you will see. The Perl 6 team are keen to point out that there will be no such thing as a official version, just different implementations
So perhaps Perl 6 will never officially begin, just as the Perl 5 described by the Camel Book (last revised nine years ago) will never officially end. And so I fear it will be deja vu all over again.
[+] [-] gcheong|16 years ago|reply
[+] [-] grayrest|16 years ago|reply
Why Ruby over Perl then? The ruby peoples have great taste in designing mini languages: e.g. sass is amazing in a why-couldn't-I-think-of-that way so I pay attention to them. The best thing I know of coming out of the Perl community is the people (Michael Bayer is my hacking hero for SQLAlchemy).
[+] [-] mst|16 years ago|reply
SASS is absolutely beautiful. I think Perl5 with Devel::Declare is a better internal DSL host than ruby though - consider MooseX::Declare - you simply can't bend the ruby compiler sufficiently to do something like that to my knowledge (or Piers Cawley and others wouldn't have moved from ruby back to Perl5, I don't think ...)
[+] [-] mhansen|16 years ago|reply
[+] [-] mst|16 years ago|reply
'As I've done for a great many other programming languages, I've bashed on Perl's technical weaknesses at length in the past. To my continued amazement, the Perl folks are the only ones who never get upset. They just say "Haha, yeah, boy, you're right, it sure is ugly. Heh. Yeah, so, um, anyway, I'm going to get back to work now..." It's awesome. I've gained so much respect for them. It's almost enough to make me go back to programming in Perl.'
So if his essay on the state of the art in Perl5 years ago scared you off, presumably the fact he's now noticed that we're (a) moving forwards (b) a happy, pragmatic and effective community will make you go look at it now?
There's even a new www.perl.org recently released (next big project - improving learn. ...)
[+] [-] garnet7|16 years ago|reply
That said, another satisfied Perl user here. :)
[+] [-] chromatic|16 years ago|reply
[+] [-] glyphobet|16 years ago|reply
Fact check:
http://www.google.com/trends?q=perl&ctab=0&geo=all&#...
Perl has been losing ground, while Python and PHP gain ground, for almost ten years:
http://www.ohloh.net/languages/compare?commit=Update&l0=...
[+] [-] mst|16 years ago|reply
Plus Perl5 generates a lot more search.cpan.org searches than google searches during normal use - we don't generally hit google very much because it doesn't have the information we need. So I could argue that CPAN's been getting better and Python and PHP have continued to fail at having an equivalent. And I'd be making just as much of an unfounded guess as both you and the article attuhor are by guessing web search volumes matter.
Of course, http://www.tiobe.com/index.php/content/paperinfo/tpci/index.... shows Perl5 and python and ruby all losing ground, but the other two significantly faster. I'm sure if I tried I could find you plenty more statistics that look good for Perl5 but don't really prove anything :)
[+] [-] jrockway|16 years ago|reply
So I think there is something deeper here than "everyone is moving away from Perl".
[+] [-] Mithaldu|16 years ago|reply
Absolute number of jobs for each language.
[+] [-] david927|16 years ago|reply
It's an unmitigated disaster of a language, as a whole, but if your needs are a "scaffolding language" that can script something together quickly and you're using a lot of regex, I have to admit, it's a great choice.
[+] [-] mst|16 years ago|reply
This is also true of C - consider things like scanf and other chunks of stdio that are preserved for compatibility but no developer in his right mind would use for new code.
Applications Perl5 written using MooseX::Declare and friends (see Task::Kensho for a good start at "and friends") is a much different thing to the high speed line noise-ish scripting perl that was the commonest sort a decade ago.
[+] [-] jacquesm|16 years ago|reply
The net effect of all this advocacy is possibly even negative, the more you try to ram a programming language down peoples throats the less inclined they are to give it a shot because they already have a negative experience before even trying it.
Languages with an open and welcoming, real-world problem solving oriented community tend to benefit from the people using it and talking about using it. Those that simply hawk a language as 'great' and keep on hammering on its strong points are missing the point here.
One of the reasons perl lost out not only to python but even to PHP is because it has a stigma attached to it of being (very) hard to maintain.
That may be more of a reflection on perl programmers than on perl though.
[+] [-] systems|16 years ago|reply
I would agree if you say that Perl is getting the bad type of advocacy, or that those who are advocating Perl are not doing a good job!
Ruby get a lot of "good" advocacy, which sound like ... "Hey I did X in Ruby, Ruby is awesome, Ruby is teh SHIZNET!"
Python normally get this type of advocacy, "...hey look how you can do the same X in Python, but now its better"
Perl's advocacy, sounds like "...Perl is not dead!", which I agree sound like a scary statement to make!
But anyway, all languages get some sort of advocacy! Perl is actually late in the advocacy game, I guess this is why it so far gets the worst kind.
[+] [-] Raphael|16 years ago|reply
[+] [-] pdcawley|16 years ago|reply
[+] [-] phillipadsmith|16 years ago|reply
[+] [-] wynand|16 years ago|reply
I don't know Perl, but I've had to pull things from CPAN to make a Perl script work and I was impressed.
At the moment I'm running parallel Python code on many different machines and it's a pain to make to sure that all the right packages are installed. I'm sure that something like CPAN would have helped.
[+] [-] billswift|16 years ago|reply
[+] [-] pdcawley|16 years ago|reply
Oh, hang on, that came first didn't it? Forget I said anything.
[+] [-] martythemaniak|16 years ago|reply
--The language sucks - yes it does. Usually the KISS principle is thought of as a good thing, except in the Perl language where nothing is ever simple or straightforward. There's 10 ways of doing every single little thing, and no two developers do it the same way. It is not a language welcoming of new developers, so as more schools and companies switch/abandon, I can only imagine it declining further.
-- it offers nothing new or exciting to most developers. If you're starting a new project or company and you already know another similar language (say, Python), Perl has nothing to offer. While it was innovative new 10-15 years ago, most of the good has long been assimilated in other languages.
-- real world perl sucks. a standard line amongst Perl monks is "you can do that in Perl!". Exceptions, objects, web frameworks, clean code, etc. You name it, you can do it in perl. Except in the real world, hardly anyone ever does, so Real World perl is as terrible as people fear. Python's strong community standards, OTOH, pretty much make sure you're almost always writing decent code.
As an example, I picked up both Django and Catalyst over the last year. With Django (python newbie), I immediately picked up decorators and started using them - both the built-in ones and my own. Its simple - just syntactic sugar for a function wrapper.
Catalyst OTOH, tries something vaguely similar using method attributes - except their are neither as powerful nor as simple/clear and despite many years of perl experience on the team, few people had seen them used, used them themselves, nor did they have a solid idea of how they work.
My point is, when you make something simple and accessible, it'll get used. When all you do is repeat "you can do that" and wave your hands about, you'll get ignored and eventually forgotten.
[+] [-] whiskeyjack|16 years ago|reply
"the language sucks" -- Is very much in the eye of the beholder. Perl works the way I think just as jQuery does. As for not being welcoming, I think you'll find perlmonks.org to be a huge welcoming community.
"it offers nothing new" -- I'm sorry, but if you already know Python or Ruby why would you switch anyhow? There's a big time investment in becoming really good at a language. No reason to switch when you have languages that can just get things done. I'm not even sure what you mean by "new". Perl is 22 years old now. Python and Ruby are both around 15. What's new here? I also find this "new" comment hilarious in light of the Python feature freeze. Things like Moose and Catalyst are new(ish) to the Perl community and they're doing great things. Further, CPAN is expanding at a huge rate, more than ever before. There's ALWAYS new stuff there.
"real world perl sucks" -- Real world code sucks period. And I do clean code. There are standards in Perl and they do evolve. You need to engage in the community a little as I think everyone should with their languages.
What is fairly obvious to me is that Python fits very well with how YOUR brain works. Perl fits very well with how MY brain works.
Just because it don't jive with you, doesn't mean it doesn't jive with others.
'Scuse me. I have a mod_perl2 handler to write.
[+] [-] mst|16 years ago|reply
Which is why we've been working on http://search.cpan.org/perldoc?CatalystX::Declare.
The Perl5 community does try and listen to the rest of the world. Unfortunately many of the people we'd like to be listening to make the sort of comments you just did rather than providing constructive criticism that we can effectively address.
The reason for shouting "pay attention" is that many people aren't even bothering to look because they're still stuck with an image of Perl5 based on ten year old information, and we'd at least like to be hated for what we are now rather than what we were back at the end of the last century.
If that upsets you, you're welcome to continue to not pay attention - but we've been getting lots of useful feedback from the people who have and so far as I'm concerned that makes it all worth while.
[+] [-] danbmil99|16 years ago|reply
[+] [-] jamii|16 years ago|reply
http://www.yosefk.com/blog/what-makes-cover-up-preferable-to...
[+] [-] pdcawley|16 years ago|reply
[+] [-] zephjc|16 years ago|reply
[+] [-] lele|16 years ago|reply
[+] [-] jrockway|16 years ago|reply
[+] [-] mst|16 years ago|reply
You might want to have a look at the libraries that are part of Task::Kensho to get a better feel for how 21st century perl is supposed to be written - at the very least, you might find some ideas to steal for your "sound" language of choice :)
[+] [-] seldo|16 years ago|reply
[+] [-] trezor|16 years ago|reply
[+] [-] StrawberryFrog|16 years ago|reply