Two Paths Diverge

Why are Puppet and Chef written in Ruby?

Because Rails was a sufficiently easier onramp for simple database-backed web programming than Java and sufficiently cleaner than PHP.

I'll let you ponder that for a second, until you're no longer composing angry responses to this article. When you've convinced yourself that that's indeed correct, the next paragraph is one blank line away.

I've oversimplified, of course. Luke Kanies (creator of puppet) told me directly that he wrote Puppet in Ruby because he wanted to learn Ruby. (I won't claim that Adam Jacob told me anything similar, but I can believe it.)

If Rails was Ruby's killer application in 2005 and 2006, Rails brought new attention to Ruby, and that new attention brought Ruby to new places. The Internet will certainly debate whether Rails is Ruby's primary driver right now, and the Internet incessantly debates whether Ruby or Python or Perl or shell or whatever is better or more popular or more fashionable for non-Rails tasks such as administration or automation, but in 2011 your eyebrows don't automatically raise themselves when you run across an automation tool written in Ruby as they would in 2005 or 2004 or 2001.

The sudden popularity of Rails brought a second wave of popularity for Ruby for non-Rails.

I suspect you don't see the same popularity for command-line PHP because no one adopts PHP because it's better than something else. People adopt PHP because it's easier than everything else.

(I also don't know how to characterize Node.js, except that Netscape tried it back in the '90s and it didn't work, and it reminds me of the AOLServer dilemma, except that Node.js has a little more shiny for some reason. Maybe a JIT and something resembling a working module system will do that for you. Then again, Perl 5's second wave came because system administrators already had a pretty decent language for system administration, and isn't it easier to write web programs in this than in shell or C? (I own a book about web programming with the Korn shell. I am not making this up.))

Again, I'm thinking about Perl 6 and writing about something else, just to focus your attention on the principle, rather than the thing itself.

Conventional thinking during Perl 6's beginning claimed that Perl 6 would be the natural evolution of Perl 5, just as Perl 5 was the natural evolution of Perl 4. The RFC process demonstrates this—we want a better object system! Better threading! Improvements here! Improvements there! More consistency! Fewer edge cases!

Even the early talk of Parrot and Ponie bore this out. At some point, Perl 5.12 was to run in Parrot, and the two languages would merge together.

Some people are happy that didn't happen. I admit I don't understand their view, but I'm honest enough to admit that they may have a point. I want a language with a great object system, with malleable control flow, with macros, with native grammars, with optional typing, with an optimizing compiler, with better garbage collection, with a great native interface, with serializable bytecode, with proper language introspection, and with finally and ultimately function signatures, and, yes, access to the CPAN.

I don't have 14 years of legacy code to worry about, in part because I have App::perlbrew, but in part because I run my code on the latest stable releases of Perl 5 as they come out.

Maybe Perl 5 will gradually become Perl 6 over the next decade or so and solve that problem, but I have to write and deploy code on October 14, 2011, so that doesn't really help right now.

Maybe I'm wrong, but I think we can safely discount Perl 6 as becoming popular by being a better Perl 5. Some people might use it that way, and that's great for them, but the use cases for which that's possible are very limited right now, and there's no obvious critical mass with which to improve the situation. That's the source of great disappointment to me, but it is what it is.

If you're looking for the pragmatism of Perl without some of the language flaws of Perl 5 but with access to the CPAN, Perl 6 isn't it right now. That's what I wanted, and that's exactly what I don't have, and that's disappointing.

There is another path.

I first used Ruby in late 2000 or early 2001. Dave Thomas told me about this Rails thing in August 2004. Rails took off in January 2005. While I don't believe that the web will eat all software ("The script on this page is taking a long time to recompile your IDE. Would you like to stop it or continue waiting?), Rails did offer those poor plebes in the J2EE and PHP worlds something far better than what they had.

As long as people are willing to invest their time and energy in developing Perl 6—with the full knowledge that it's very unlikely to be the natural successor to Perl 5 in Perl 5's niche without dramatic changes in the ecosystem—there is a chance that Perl 6 can stand out in front of the next revolution (or the next, or the one after that, or...) and be sufficiently better at something that the ancillary effect is popularity for other tasks.

Thing is, you can't easily predict what that will be or when and especially why. You can't optimize for that based on user feedback.

Even so, I trust Larry's instincts and good taste. I believe him when he says he believes it's possible to avoid Worse is Better and, for once, get a Better is Better cycle.

Yeah, I'm frustrated and disappointed that eight and a half years of working on Perl 6 and Parrot haven't produced software that I can use productively. (Sunk costs. What can you do?) Sure, they've produced dramatic improvements in Perl 5—improvements so fundamental that we use them every day and can barely remember the world without them—but they haven't produced the kinds of revolutionary improvements the language needed in 2000.

Yet I can still write great software in Perl 5, and I haven't come across anything better in gestalt.

I hate the phrase "Perl 6 is just a research project for Perl 5", because it's silly and wrong. (If it were true, Perl 5 would do a much better job of actually borrowing features from Perl 6, rather than surface syntactic polish applied over rickety and fractured semantics). Yet I think the best way to explain what Perl 6 is, as it stands today, is as a revolution in search of a cause.

It's a good language, even great in a lot of ways. I look forward to using it, even though I'm not going to find the problem for which Perl 6 is the world-moving fulcrum. Hats off to the unreasonable people who do.