

Parrot as a Mature Platform - stefano
http://wknight8111.blogspot.com/2010/09/parrot-as-mature-platform.html

======
jsn
10 years in development, and it's not a mature platform. I wonder how people
working on perl6 / parrot bear with that. I mean, if it's on your CV, it
basically reads like "I worked on something for 10 years, and nothing was
delivered (nothing usable in real life, at least)". What does the potential
employer say -- "Welcome aboard, we hate delivering products anyway"?

Also, how do those projects acquire new developers? Say, you're an open source
enthusiast with a set of relevant skills / preferences (VM skills, programming
languages, technical writing, FOSS project management, whatever), looking for
a project to join. Why would you choose a project with a history of staying in
"experimental, unstable and incomplete" state for 10 years, no deadlines
mentioned and unusable for anything serious in production? At this rate, it
will probably still be in the same state in 3 years; what will you have
achieved by then? "I wrote a lot of highly complex code / documentation, but
almost nobody really uses it"?

~~~
chromatic
What does "mature" mean in this context? (The same goes for "unstable" and
"incomplete". Is Python 3 immature and unstable and incomplete because it has
the GIL and no official JIT?)

I have no problem explaining the presence of Parrot and Perl 6 on my CV to
employers willing to ask honest questions about my participation in both
projects. All of our successes and failures are visible to anyone willing to
understand them. We deliver working software every month, with continual
improvements. We review the way we schedule, develop, and deliver that
software regularly. We have a good testing infrastructure. The software gets
more and more usable and more and more useful and we manage to attract more
and more users and more and more contributors. Parrot has to walk the fine
line between making architectural changes Rakudo Perl 6 needs and maintaining
a stable base for Rakudo -- two desires which often conflict.

Yet somehow, month after month for almost three years now, both projects
release usable, useful, well-tested software. You can see the monthly
improvements.

Does the fact that Parrot suffered a critical project personnel failure four
or five years ago forever taint everything good it's done in the intervening
years? Does the fact that Perl 6 had to invent new parsing techniques ruin its
suitability now? In five years? In twenty? (Just how long should it take to
invent something new anyway?)

I believe that an honest assessment of both projects as they stand right now
will demonstrate that we can make and meet commitments. What more can you ask
of developers and project managers?

~~~
jsn
I don't know; I suppose "mature" wrt software is not unlike "mature" wrt human
beings -- it means "when you stop growing fast and changing unpredictably",
and maybe "when other people rely on you". Or something like that. I don't
think GIL-lessness [or any other feature] is related to "mature" (that would
rather go into "incomplete" folder).

You point out that you perl6 folks make a steady progress, and that the work
you're doing is fairly hard. All valid points, but... I don't want to sound
cruel, but a steady progress solving hard problems is not very valuable per se
to the [potential] users of the software or employers of the participants.
They usually care much more about results. If you deliver the results without
much progress and avoiding hard problems, you're fine; if you do a lot of
progress working through hard problems without practically useful results,
you're screwed.

You say your software works; fine, but for what definition of "work"? "Passes
tests" is one thing, but "usable for production heavy lifting" is something in
a completely different league. I see people migrating from ruby-1.8 to
ruby-1.9 now and then; a move from python2 to python3 is a fairly rare beast;
but did anyone move from perl5 to perl6? or started a non-toy / non-research
project using perl6 / parrot?

You mention the research value (new parsing techniques et ol). I have my share
of doubts wrt this part (so does the author of the article, IIRC), but let's
skip it. My bigger point is, is it what users and employers want? I honestly
don't see it. Please don't misunderstand me here; I'm not saying you must do
what some other people want. You, of course, are free to do whatever, I (or
anybody else) is not in position to tell you what to do. But then again, when
other people (production perl users, potential investors, employers and
contributors -- in short, industry people, not research people) judge your
projects, their judgments will probably be aligned with their very specific
industrial needs, not with potential research value and/or some decades-long
perspective.

------
wazoox
Right on! Parrot needs to think big now that it's stable.

