Mitchell N Charity wrote:
...Perl 6 implementation has been characterized by a dearth of
developers. There are several reasons for it, but the lack of
implementation development resources has been the defining factor of
the Perl 6 endeavor for several years now.
Building a large project with long term objectives and almost no
short-term payoff is probably the most difficult undertaking for an open
source volunteer model.
A language intended to supplant an already highly useful language has
such a high threshold for achieving usefulness, that it doesn't lend
itself to an agile approach, and open source developers are agile by
nature - they're motivated by the idea that for a moderate investment of
effort, they'll get back some new bit of utility. Working on the
foundation for a house that's not going to be built for several years
just doesn't offer the kind of reward most developers are motivated by.
The perl community has just not meshed in the way that, for instance,
the ruby and python communities have.
I'm not involved in either of those communities, but I'm not sure the
comparison is apt. I bet when it comes to core development, both Python
and Ruby emerged from obscurity in a relatively fleshed out and useful
form. (Having spent time in obscurity getting fleshed out.) Being new
languages they could get by with offering modest core functionality, and
still be perceived as useful. Their attraction was their (perceived)
novel approach that pulled in unsatisfied developers from other communities.
I think Perl 6 suffers from its affiliation with Perl 5. For Perl
developers, Perl already provides high productivity, and there isn't a
pressing need to replace it with Perl 6. Sure, Perl 6 sounds terrific,
and most will migrate to it, but that's not the same as being motivated
to implement the language. Backporting features from Perl 6 to Perl 5,
while useful for the language designers and to ease the transition, only
reduces the motivation.
For non-Perl developers, Perl 6 is too easily dismissed as being related
to this thing they either left behind years ago, they think is old hat
compared to what the IT press is talking about, or something they've
heard made fun of. Why would they want to contribute to that?
It makes me wonder whether Perl 6 would gain from a rebranding campaign.
When attempting to create a Perl6-class language, the obvious thing to do
is to build on an existing strong language. But pugs failed to attract
enough Haskell-writing developers, and Common Lisp, OCaml, etc, seem
unlikely to fare better.
For someone looking for a practical tool, and not just a playground for
language experimentation, these Perl 6 prototypes are unappealing. They
come with the built-in assumption that they'll perform poorly (unless
proven otherwise), and they feel like they're disposable. Why spend time
contributing to something that is pretty much guaranteed to be thrown out?
Elf's purpose is to permit Perl 6 implementation development _in Perl 6_.
Elf is based on the hypothesis that developers could be found if the
implementation language was itself Perl 6.
I like the theory and agree with it, but I think you still need to make
a compelling case to address the two prior mentioned problems with a
high-level implementation.
One thing I'd want to see is how contributions to Elf is going to
benefit whatever is seen as the final production-ready implementation of
Perl 6.
So, the idea was, create the first usable partial implementation of
Perl 6, write it in Perl 6, and people will flesh it out and/or
bootstrap off it.
One approach to consider is finding a problem space where a Perl 6
subset can be a compelling solution. Reduce the size of the work that
needs to be done to achieve something with practical usefulness and
you'll increase your chances of getting developers on board.
() Rakudo/Parrot. ...there are several known limitations, including
performance.
That's not what you'd expect from that architecture, but I presume
that's just a growing pain that'll get worked out with time. The
assumption being that a low-level implementation starts slow and gets
faster, while a high-level implementation starts slow and pretty much
stays there.
But it has developers.
Likely because they feel Rakudo/Parrot are on a direct line to becoming
the production-ready solution.
Build out STD/viv into a perl5 and Moose based implementation of
Perl 6.
Is there much hope that that won't perform badly?
The test suite needs, in my estimation, to grow by >10x.
And needs a generative testing system. Perl 5 suffers from it's lack of
sufficient testing. And Perl 6 is a much more complex language.
A note of expectation management. Perl 6 implementation is crawling along
on a shoestring. A handful of developers digging through the maze of an
understaffed, big and complex bootstrap problem. Contributing tends to not
be a smooth process. Which can be quite confusing, and frustrating. But
even lending an oar, an hour or two a week, can be of value.
It's certainly possible that Perl 6 turns out to be a case of biting off
too much. Of choosing the wrong problem to work on.
I'd do the following to get Perl 6 past the bootstrap tipping point (I
only follow second-hand information on Perl 6 so my apologies for
mentioning things that are already being done or have been already
proposed and rejected):
1. Raise enough funds for TPF to hire a full time, dedicated project
manager (someone from the Perl community willing to work on minimal income).
2. Find a few problems areas where it is believed a Perl 6 subset could
offer a compelling solution.
3. Outline the subset of features needed to achieve #2, and get
volunteers to write test suites for them.
4. Break down the features into self-contained projects, and put them
out to bid. Something a contract programmer could work on for a month or
two between projects.
5. Go back into TPF fund raising mode to cover the costs of #4.
The theory being that once you get past the initial tipping point,
you'll have a useful tool that will attract developers, and encourage
incremental development from that point forward.
I have no idea what, if any, budget TPF currently has. I do know they
offer grants from time to time, and I wonder if there has been any
effort to parcel out Perl 6 pieces to grant recipients. I don't mean
paying for developer proposed Perl 6 projects (I'm pretty sure pieces of
Parrot where funded by TPF), but instead specing out (or providing a
test suite for) needed bits of functionality to get from point A to B in
an orderly fashion.
-Tom
--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
_______________________________________________
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
