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 spent some time writing JavaScript, and I can't understand why people say there's a nice language in there despite its flaws. (In my mind, it's mostly decent, despite its flaws.) I suppose that's like saying "Wow, Python supports functional programming!" if you learned Java because Scheme was too scary or "Ruby is basically Smalltalk!" if everything you know about object systems comes from realizing that PHP continues to get it wrong.
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.)
I've long thought that near compatibility with a subset of perl 5 was the key to perl 6. If you can make adoption gradual - for real projects they you could get perl 5 users to start switching. Or perhaps more ambitious, can perl 5.20 be rakudo perl 6 with a perl 5 grammer ?
Those are two good thoughts, and they've come up at various times. If you remember back far enough, Ponie (Perl 5 on Parrot) was to be either or both a compatibility layer for running existing CPAN modules in process with Perl 6 programs or a target for an additional or replacement VM for Perl 5.12.
Being able to run Perl 5 code in the same process as Perl 6 code would still be a huge deal. Getting rid of XS is only part of it though, and that gets to the point of why reimplementing Perl 5 is so tricky.
Gradually moving Perl 5 the language to Perl 6 the language is possible, but the amount of time it will take is substantial. Consider changing simple things, such as the concatenation operator or the type hierarchy. Certainly adding features such as grammars or an object system is much easier, but there's no simple or clean way to change the notion of Perl 5 context into the notion of Perl 6 context.
I think it's still probably a shorter path to implement Perl 6 on its own than to try to make it a 20 year vision for Perl 5, but 11 years of Perl 6 leave me unwilling (even unable) to speculate on calendar dates.
Wow, you really let the floodgates go. I guess one of the interesting things that I've seen happen in the last few years is this idea of splitting the language that gets written from the language that gets compiled. For example Coffee Script is just a nice translation layer for devs that sits on any javascript compiler. Moose (to some extent) is just an extension of the syntax for perl. Though I think that this is one place where p5 really shines. Sure you can write a bunch of methods on a unique object in PHP or javascript, but there's not a clean nor easy way to built out what appear to be new keywords.
Where does this leave p6, who knows. I really like what I've seen, but I've yet to see a super compelling feature from p6, that has not already been re-done in p5. I don't know if this is vindication of your idea, but ya I keep grabbing perl because it's what things like me, and together we get stuff done.
Niecza could be easily ported to the JVM if the threat of Microsoft patents becomes a serious issue. (I wrote a begining of a Common Lisp backend).
If?
(I suppose the other question is "Do you trust Oracle more than Microsoft?")