Mitchell N Charity wrote:
My thanks for the thoughtful reply.
Doubly so since complete silence would have been quite a bummer.
You're welcome, and I've been surprised at the silence. If nothing else,
I though I included enough questionable statements in my last posting to
spur some discussion. :-)
Well we are in the midst of that national productivity drain otherwise
known as tax season.
Something from your prior post I forgot to address:
Elf development continued to slow, down to a small fraction of an FTE.
Still only one developer. There's been almost no community interest.
I'm confused. Have you mentioned Elf on the list before? Given a talk on
it to Boston.pm?
I hadn't heard of it before. What steps have you take to publicize it?
Pugs managed to attract, at its peak a few years ago, tens of active
developers.
So what might make Perl 6 development more like...Pugs?
Or put another way, what attracted developers to Pugs?
And Moose has an active community now.
Is Moose really an apt comparison? It provides a set of libraries for
implementing an alternative object model, no? That sounds more to me
like a language feature project, rather than a language project.
It bypasses the language bootstrap problem by offering an incremental
enhancement for incremental effort.
Perl...is singular among the top 10+ most used languages in still
having only a single implementation.
Interesting point.
It is unusual in not having both JVM and CLR backends, usually with
at least one being production hardened.
This reminds me of some of Dan Sugalski's (last seen on the list here in
2005) Parrot talks from around 2001. The pitch was that Parrot would be
superior to CLR and JVM - enough so to attract other languages to the
platform.
That sounded great then, but 7 or 8 years later without Parrot, it
might be time to rethink that strategy.
If you've been following P6 development, what seems to be the
community's thoughts on putting aside Parrot for now, and going for a
CLR implementation, so that the problem is smaller in scope. (This is
such an obvious approach, that I'm sure it has been discussed countless
times.)
CLR could be a good playground for P6 to mature in. Put to use on small
desktop widgets and apps. under Mono until it is ready for real work.
(About a month ago I surveyed the available languages for Mono for a
small desktop application, and was disappointed to see that Perl had
virtually no presence in this area. I assume this be because it'd be a
bear to port P5 to run under CLR, if even possible. But P6 offers new
opportunities.)
Targeting CLR might mean limiting what P6 can do, or making the
compiler's job harder, but chances are it'll still lead to useful code
faster than tackling a compiler and a VM simultaneously.
And almost everything I do hear of, seems to occur in the context of
Perl 6.
Probably because P5 is considered near impossible to port to another run
time.
I was struck by "A language intended to supplant an already highly
useful language". Supplant? Some form of p6 currently seems the only
likely path by which perl5 will end up on other vm's, no?
I agree about P6, but I'm not sure P5 ever will.
Not for any inherent reason.
See above.
The p5 opcodes are in better shape now than they've ever been. One
could certainly imagine doing a javascript implementation of the p5
vm for instance.
Really? That's a practical possibility now?
It's other languages which are supplanting p5, not p6. P6 seems p5's
last chance at non-death.
True.
But that doesn't change the point that for the core community who have
stuck with Perl, P5 is a successful and highly useful tool, and sets a
high bar for a replacement. All the crufty bits that have driven other
developers to other languages are not viewed as a substantial negative
by this mostly satisfied group.
Perl seems to be living off its installed base for
now, which will get burned through in just a few years.
Likely, though it is a "long tail" situation, so "a few years" only
works for some definition of market share or some such. Like the dead
languages you cite, there will be P5 holdouts for decades. There's just
too much code for that not to be the case.
So a first strawman opportunity might be to address the impression
that "p6 is a completely different language than p5 - p5 code won't
run on anything p6".
What's the relevance?
Replacing it with "p6 is the mechanism by which the perl community is
attempting to do what every other major language has already managed
- to grow beyond its original C implementation."
A lofty goal, and not something a typical project contributor can have
much of an impact on.
Elf has two backends, a perl5 and a common lisp one. ... Fib in naive
CL is 10x faster than p5. With p6 boxing, multimethod arithmetic,
etc, elfcl runs fib several times slower than p5. But note that
creates a story for eventually running faster than p5.
Yeah, but it sounds like the optimizations need to happen down in the CL
code, which seems to defeat your object of attracting Perl developers by
developing a P6 compiler in P6.
So yes, slow is an issue. Perl 6 in general will tend to have a longer
compile time, but potentially much faster runtimes.
Is compile time still considered much of an issue? It seems that when
compile time matters, it either happens beforehand (p-code) or a
persistent service is used (mod_perl).
So another strawman opportunity is applications that require some
subset of perl running faster than p5.
Faster is only one possible dimension of better.
For example, regexps on CL. And maybe on recent javascript (webkit).
So you're saying appeal to CL or JS developers by providing a
mini-language layer that provides a new language feature? (And do it in
a way that isn't far more painful and disruptive than just using a
native library.)
I think you need to look at a more specific niche where an application
built from a subset of P6 can offer the complete solution, and do it in
some fashion that's superior to existing tools.
The gotcha is many such needs are addressed in a p5 context by using
a wrapped C library.
That provides speed, but not flexibility.
Concern for throwaway-ness seems to decompose into two issues: "code
churn will make my code's existence transient"; and "the big picture
will evolve in a way such that no one ever cares that my code was
written". With perception being more important than reality.
Current Moose and past pugs suggest churn doesn't discourage people
from contributing.
That would fit with my expectations.
Any large project written in p6 now is almost by definition throw
away code. ... "I'd have architected this differently if I had full
p6"...
Right. I think the more important aspect is whether the project as a
whole is viewed as a temporary, throw-away solution. If you can connect
the dots (and your proposal should) showing a lineage from Elf to a
production solution, then that should help address that concern.
For example, spell out a roadmap showing how a P6 compiler in P6 can be
morphed into one that spits out CLR bytecodes. You could build this on
P5 (with STD?), and it could eventually be bootstrapped away, replacing
P5 with a CLR executable.
Then make a case for how such a compiler could be developed faster than
Rakudo. (If it can't, then the better solution would be retargeting
Rakudo to CLR.)
The concern that 'no one will ever care' is more problematic. The
belief that rakudo/parrot will become a/the production p6 has
motivated its developers, discouraged others from working on other
things. And the belief that it won't, has discouraged others from
working on it. For p6 in general, there being neither a project
manager, nor broad community involvement, there is no "sanctioned"
implementation effort. So all efforts have the 'this may dead end and
no one will ever care' burden.
Right, but developers will make a judgment on the probability of that
happening, and back the project they think has the best chance of surviving.
The Perl 6 language itself has it.
More so every day as we approach the decade anniversary of its inception
without a practical implementation.
Other ways to address it, include incremental improvements on top of
p5. One can view them as backports...
But of course P6 backports to P5, while they can add language features,
they'll never facilitate P5 breaking free of its current implementation,
which you pointed out is potentially holding back the language.
For agile, there are also several components. There's "it works, and
it's easy to make progress". That's true for elf, and may even be
true for rakudo now, as one can now extend it with p6. But there's
also "and I can use the improvements in production". That's Moose,
but nothing p6.
The "it works" part helps, but without the "and I can use it" for
something useful part, you're just performing an academic exercise, and
that limits the audience of developers.
A p6ish standard library of classes might be done in the context of
the existing Moose community.
Without a plan for how you get from there to a full compiler, I think
such a project has the effect of slowing the temperature rise on the
inevitably boiled frog that is Perl. :-)
-Tom
--
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/
_______________________________________________
Boston-pm mailing list
[email protected]
http://mail.pm.org/mailman/listinfo/boston-pm
