I've spent most of 2011 focusing on my business. Sure, I write heaps of code, but I direct most of my attention to figuring out how I can build a sustainable business which produces value and wealth.
Eric Ries's the Lean Startup contains a great deal of wisdom (and his Build chapter is the best non-code metaphor for test-driven design that I have encountered). In particular, he argues that the only way to figure out what customers are willing to pay for is to try to sell them something. The best predictor of why people will give you money is what people give you money for.
Yet you're here to read about Perl and programming.
My rant a couple of months ago about Why My Side Project Doesn't Use Perl 6 came from deep frustration. After eleven years of development and more than a year after the long-awaited Rakudo Star ("finally ready for early adopters!") release, it was incredibly frustrating to discover that, even as someone with commit access to the entire Rakudo stack from specs to tests to Parrot to NQP to PCT to Rakudo itself, the whole thing just wasn't ready for me to use even in a simple side project.
The biggest users of Perl 6 (via Rakudo) code right now are, as far as I can tell, Rakudo itself (via a stripped-down bootstrapping mechanism), a single blog written in Perl 6, and Rosetta Code chrestomathy examples.
Yet I'm not here to bury Perl 6.
I've been thinking about how, if Dart is not the language of the future, what the language of the future might be, and what Larry says about evolution versus revolution.
Arc turned out not to be the language of the future either.
Gradual improvement is well and good, and it's starting to serve Perl 5 pretty well. The ability to shed cruft and mistakes and poor designs holding back future improvements (a real metamodel! slimmer memory footprint! JIT! safe exceptions! function signatures! multiple dispatch! safe sandboxing! cheaper and easier parallelism! implementations on other backends!) is crucial.
Feedback makes that happen.
Sure, you can predict that a project which relentlessly focuses on one and only one hot thing (Write a blog in 15 minutes! Manipulate DOM elements on the client! Deploy a dynamic web page just as easily as writing HTML!) will have a success, but real revolutionary success comes from making a new niche, like web development in 1994.
As much as I'd like to argue that you can iterate your way to a revolution through carefully gathering and considering real user feedback, I don't know that that's the case.
I worry that once you release a programming language with minimum viable utility, you ossify early decisions of design and implementation such that you can't quite yank the floorboards out from underneath any users you have, lest they stop being users and stop providing feedback.
Somehow you have to balance the desire to preserve an existing community with the need to attract new members to the community, and that may be the hardest problem in programming language development.
If you read Dan's Parrot post-mortem, you see those two tensions. Parrot's two biggest technical failings from the start were writing the wrong code and keeping it around. The revolution of Pugs wasn't that Haskell is magic or that all Perl needs is the superhuman effort of a superhero (though Audrey certainly gave it her best shot), but that there is no substitute for working code.
Parrot doomed itself for a decade because there was no serious working Perl 6 implementation for years. (There were three half-hearted attempts, each a rewrite of the previous.) Parrot lumbered along implementing things it thought Perl 6 might probably need without getting real working feedback by actually running Perl 6 code. (Dan's been out of Parrot longer than he was in Parrot, and some of that wrong code is still around, because you can't yank the foundation out from under people's houses without some structure and warning and planning.)
Yet I'm not here to praise or bury Parrot either.
If I'm right that normal people adopt languages to get stuff done, you have to take a pragmatic approach. Make something radically better at getting something revolutionary done, and you have a chance.
(PHP is radically better at making simple web pages than just about anything else, even though the language itself is just about the worst thing imaginable. Similarly, Java is radically better than C++ because of garbage collection and a break from the PDP-8 type system of C, and also it was cheaper than Smalltalk, at least until Oracle bolts a coin slot onto the JVM.)
In conclusion, I don't know.
On paper, Perl 6 is a nicer Perl than Perl 5.
In practice, none of its implementations reach the Minimal Viable Utility stage for me, a fairly normal and fairly positive early adopter. I don't know if that's good or bad for Perl 6.
It's good in the sense that it gives Perl 6 freedom to experiment to find its revolution. It increases the technical possibility that it won't fall into the "Wow, that's all Python 3000?" or "Arc? Scheme with some renamed builtins?" or "PHP 5 is the new PHP 6" or "That's all the better they could do with Go?" or "17,000 lines to write 'Hello, world!' in Dart, and they misunderstand OO so badly that they think Java interfaces are a good idea?" trap.
It's bad in the sense that I'm not sure that any of the big three Perl 6 users right now are representative of the kind of revolution Perl 6 needs—plus after eight years of trying to get something useful shipped, it's hard to work up the motivation to donate even more time and effort toward that always nebulous someday.
Sure, Pugs demonstrated that writing tests for the specifications was incredibly valuable. By no means should anyone diminish that.
Sure, Rakudo demonstrated that a serious implementation of Perl 6 on Parrot helped focus both projects.
Yet ultimately, both Parrot 1.0 and Rakudo Star were more fizzle than sizzle, and I think that's because neither one rose to the level where normal people (for however you want to characterize the kind of people you'd consider normal users) could do useful things.
I know, I know it's really difficult to start a revolution, especially when you don't know where it will end up, but very especially when you don't know what it will be. I know you want to give yourself all sorts of escape hatches and valves to help guide your evolution into a revolution....
... but at some point, I have to get work done, and if the shortest distance between here and there is using a lesser tool and if I'm not sacrificing too much future to do it, I have to hold back a tear and wish that Perl 5 had native method signatures or multiple dispatch or malleable control flow with continuations or macros.
(What about Niecza? I really shouldn't have to explain this, but IRC commentary on how I'm a bad person cannot seem to get this right. In mathematical terms, the set of things which are not promissory estoppel contains the opinions of everyone who isn't legal counsel or a director at Microsoft opinion about how it's safe for my business to use Mono. See also Microsoft Sues TomTom. If you live in a country without the threat of software patents, or if your livelihood otherwise can't be threatened by the possibility of a lawsuit against your use of a project in a way a known patent aggressor with patents on fundamental technologies you use and threatening indemnification agreements with now-defunct licensees doesn't like, good for you. We take your well-intentioned legal advice under advisement.)