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
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
Yet I'm not here to bury Perl 6.
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
... 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.)