The anecdote goes that, during a meeting of Perl 5 Porters at The Perl Conference in 2000, Jon Orwant seized a moment to start throwing coffee mugs at a wall. (Jon leaves little to chance.) With the dot-com bubble bursting, fierce infighting on the p5p mailing list, and a language with lots of possibility but no galvanizing principle, Perl seemed in danger of stagnation.
Most people reading this know the punchline: a dramatic rethinking of what Perl is and could be coupled with a backwards-incompatible rewrite of the internals, intended to come out in sometime around the end of 2002. (Time will tell if a usable P6 ever appears.)
Legend has it that announcing "the next major version of the Perl programming language" announcement was as much about revitalizing the Perl community itself as it was about any technical achievement. Certainly Larry's desire to see a kindler, gentler, less fractious community has taken quite some time—but things have improved.
From the technical side, I could list improvements in release process, testing, documentation, usability, performance, library availability, and syntax, but that approaches the question from the wrong angle.
The most important question in July 2000 about Perl's future is still the most important question in July 2012 about Perl's future. That question is this:
Is it reasonable to write new code in Perl right now?
The answer depends on the domain and your preferences and the dynamics of your coauthors and many other factors. You could list a dozen, and they might match the dozen I could list. The specific answer and the reasoning behind that answer matters much less than the gestalt of that answer. Who is answering that question? Why?
To the extent that technical concerns (stability of the language, future maintenance possibilities, library availability, presence or absence of bugs) exist, the Perl community knows how to manage those concerns. We've done a credible job in many areas, and we've even blazed new trails in others. (We're still a tribe of syncretic polyglots though: for every mod_perl which gives way to Plack, a PPI spawns a Perl::Critic and an ithreads is better than a GIL but otherwise somewhat unspectacular. For every Moose, someone says "Don't Tcl and Lua all require you to do something similar?")
To the extent that human factors (availability of developers, credibility of developers, cost of developers, and whether that fixie-riding hipster would deign to give up his precious for a language with a working lexical model and an actual library system) exist, we haven't solved the problem.
The problem is, as usual, one of communication and visibility.
It's not that Perl is or isn't a credible language for writing important applications. (It is, and it's an order of magnitude better in 2012 than it was in 2000 as I see it.) It's that the perception of Perl is more important to people outside the Perl community than any technical factors.
Certainly the inability of Rakudo's developers to release anything that much of anyone cares about has hurt Perl—although deconstructing the Osborne myth is interesting. It's not the only reason Perl appears to have stagnated, but splitting the community and offering a hazy potential future for more than a decade didn't help, to put it lightly.
Perl circa 2000 struggled with the success of Perl 4, the ubiquity of Perl on Unix systems, and the CGI model of writing web applications. This meant a lot of people had seen a lot of awful chewing-gum-and-baling-wire monolithic code written and barely maintained. The good news is that a decade of focusing on things like comprehensive testing, coding standards, infrastructure, and a relentless sense of improvement to design and implementation have given people who know what they're doing a fine set of master tools to craft beautiful things.
(That's one reason I like the term "Modern Perl" and others like "Enlightened Perl" or talk about "The Perl Renaissance". If I wrote the same code in 2012 that I wrote in 2000, I'd be a terrible programmer.)
The better news is that even though a novice likely won't understand what a parametric role is let alone when to use it or why, he or she can still get stuff done with minimal ceremony and no fuss. (Sure, the resulting code will be awful, but at least one aspect of the programming world can be honest about novice code: it's awful. It's never not going to be awful, even if you teach them SML or Eiffel or Ada or Python. People who don't know how to program well won't program well. Embrace the tautology.)
If I were handed Moose, Catalyst, DBIx::Class, HTML::FormHandler, Dist::Zilla, Plack, and a few other tools in 2000, I would have deleted thousands of lines of code. Immediately. We have amazing technical features. We have a vibrant community. (Look at attendance rates at YAPC and growth rates of CPAN. We still have a growing community.)
These are all good things, but the coffee mug question and the answers are still relevant and important and vital.
(Note carefully: the question says nothing about "maintaining existing code". That concern is far different and the answer from a business perspective necessarily must consider things like opportunity and sunk costs.)
The answer isn't obvious. The answer isn't easy. (The answer isn't "Can someone throw some rounded corners and drop shadows and Lobster fonts on Perl web properties?") Then again, the answer isn't "Fork and rename" or "Buy an ad in an IT weekly rag" either. Part of the answer may be "Continue to improve the core and out-evolve everything else in any ecological niche possible, but the biggest part of the answer is this:
Build credible new things. Brag about them. Repeat.
Then again, some rounded corners on blogs.perl.org wouldn't hurt :-)
I agree actually. Write a blog post about your cool new module. Oh yeah, first write that cool new module. Something I need to do better is to add a github page to each of my github repos. Its really rather easy. For more complex stuff I am just starting to use octopress (see http://perl4science.github.com) which makes it really easy!
I really think that we should find a phrase though, something concise, to reply with whenever tries to FUD on Perl. I've been using "its not your Daddy's Perl". Like it? The next time anyone talks about spaghetti code or CGI.pm just ask, "Have you seen Perl lately? It's not your Daddy's Perl". :-)
You mention the issue with the Osborne Effect and given that I've been doing a fair amount of business research lately, I'd like to chime in on that. To give some background, the Osborne Computer Corporation was a hugely successful company that was producing "portable computers" (computer the size of small suitcases). The story is that the owner, Adam Osborne, announced the next generation Osborne computer and it was to be more powerful than the current computers. However, since they were not yet in production, orders for the Osborne 1 dried up and no one could buy the next generation Osborne, driving the company into bankruptcy.
Most tellings of this story focus on one of two variants:
The reality is far more complicated, but the one issue that no one disputes is that Osborne suffered a significant drop in sales after announcing the new computers that were not in production and thus could not be delivered. Absent the "Osborne Effect" and the ensuing cash shortfall, Osborne Computers may very well have survived.
Consider, today, the case of Nokia. When Microsoftie Stephen Elop took over Nokia, Nokia was still twice the size of their nearest rival and still growing (warning: incredibly long and detailed analysis). Then Elop penned the infamous "Burning Platform" memo, meant for internal use only, and it helped to gut Nokia. The "Osborne Effect" alone isn't enough to kill Nokia, but it had a huge hand in Nokia's slow, painful death.
I would caution people to not dismiss this effect casually.
I've heard it joked about, but since Perl 6 is going to be a distinct language, couldn't Perl 5.18 just be Perl 7 and let the Perl 6 community decide on a name for their new language AnakPerl or something?
If the Osborne effect is real in any sense, cannot it be combatted by delivering the goods? We have the goods! Perl5 is far better than when Perl6 was announced, as you well said. We just can't seem to tell anyone yet, because the people who don't know the story think that they should still wait for Perl6.
Linux recently went 3.0 without breaking backwards compatibility. Why wait? Perl 7 == Perl 5.18?!
This phenomenon occurs with car sales when the end of year model is discounted to move the stock - people know a new model is coming and will wait. Similarly, Apple lines up announcements with availability very tightly.
The efforts of freshening up the perl canon (and non-canon) websites are to be commended and supported. There is still much work to be done though! People might consider grant requests to spruce things up if design skills and time aren't available. I see a spiffy up to date website as being a fitting tribute to spiffy up to date code. (see also https://twitter.com/PerlDean).
Back to the 'build then brag' topic. It is daunting to write code then put together a really pretty website to back it up. Thankfully, there are lots of free web templates and github will create something presentable for you if you use it (or even if you don't, just take it and use it elsewhere!) Dist::Zilla has a Twitter plugin, hopefully plugins for Fresh(meat|code)[1] and other similar sites will emerge.
Posting your perl project to cpan is also a good way to get it out there. Though i have heard before that 'cpan is not a place for applications' - so i wonder if this is a wide spread misconception?
[1] apparently the API for fresh(whatever) is now gone. so i dont envy the person who whips up something in WWW::Mechanize or similar.
That idea's been brought up and debunked countless times. It's not going to happen and it doesn't solve anything.
Doesn't solve anything? I am not sure I totally agree even though I know what you mean. Perl 5.x.x ad nausea is really tedius.
...and yes, I know it will *never* happen.
The problem with Perl is the ecosystem it lives in.
Perl thrives in a terminal/command line environment. Yet between 80 to 90% of systems out there are MS Windows based. [http://en.wikipedia.org/wiki/Usage_share_of_operating_systems]
The "cmd" shell in MS Win sucks. Badly. So 80%+ of the people who we may wish to introduce to Perl have an OS in which it's painful to work with Perl - even before you visit CPAN and bump into compatibility issues.
Padre is a great start to working around the Windows' eco-system issues.
Even better would be some way of doing*:
# module causes all STDOUT to take place in a pop up box
use MSWin::STDOUT_In_a_box;
print "Hello, world\n";
Then the MS Win based newbie writes hello_world.pl, saves it, clicks on it in Explorer and up pops a native and familiar interaction.
* In MSWin the .pl is associated with whatever Perl you have installed, no !# needed.
My main issue with the Perl 6 "Osborne Effect" claim is that it presupposes a vast pool of people who (still, after 12 years) are holding off developing in Perl 5 until Perl 6 comes along.
Frankly, the numbers don't hold up. Interest in Perl 6 is vastly smaller than in Perl 5 and largely the interest is for different reasons, even among people interested in both.
Got to echo the closing statement of the article though: build stuff, write about the stuff, say why Perl made it easy/better/awesome. Give examples of how Perl made it easy/better/awesome.
Post that bragging somewhere where people will see it, get friends and other perl bloggers to link to it - as a community we just don't chatter as much as other languages or cross link between blog entries, we have a very hub-focused style of communication and apply "Don't Repeat Yourself" to our communications as much as our code. I'm as guilty as anyone else at this, I read stuff and think "that's cool" and maybe share it over Skype with a few friends, rather than posting to my blog about it.
Repost, reblog, share, whatever. It raises visibility and makes it more likely that when people search for Perl stuff, they see decent modern code, not crufty old code from the mid-early-90s.
Another way to think about it is Perl 5.16.0 == Perl5 version 16.0.
Toby, I know that. The problem is that people who don't know that, don't know that! They see Perl6 and say, I'll wait for that, assuming that Perl5 will be deprecated when Perl6 is ready.
Chromatic, I'm sorry I took your conversation the wrong way. You are absolutely right, the best thing to do is write good stuff and brag about it. I always try to blog entry at least whenever I release a new module or a new version with new features.