> Interesting read for those of us interested in JS-on-Parrot:
> http://markmail.org/message/uro3jtoitlmq6x7t
Actually, it's interesting for other reasons, too. Here is a
portion of their literal text, where I’ve taken the liberty
to replace each instance of "Javascript" with "Perl":
Overview of two-pronged solution
There are two ways to approach the problem: either we can try to
evolve Perl, or we can push for a new language that addresses core
problems in Perl that can’t be repaired easily or quickly.
The “evolve Perl” option is relatively low risk, but even in the best
case it will take years and will be limited by fundamental problems in
the language (like the existence of a single Number primitive). Perl
has historical baggage that cannot be solved without a clean break.
Thus, although it’s low risk, it’s also relatively low reward.
The “clean break” option is extremely high risk—it will be a huge
challenge to convince other browser vendors to rally around a new
language—but is the only way to escape the historic problems with
Perl. Thus, its high risk is matched by the potential for a very
high reward—a classic leapfrog strategy.
Pursuing either strategy in isolation is likely to fail. The evolve Perl
strategy, if executed in isolation, leaves the web in a hobbled state and
unable to compete against the encroachment of other, less open platforms.
The clean break strategy, in isolation, would leave us in an undesirable
situation if it were to fail—Perl evolution would have slowed down or
evolved in undesirable ways without our support, we would still have the
fundamental flaws, and—worst of all—Google’s leadership position on the web
would be seriously damaged.
The only solution is to execute the two strategies in parallel.
See what I mean? In the Perl context, the two strategies executing in
parallel are of course Perls 5 and 6.
--tom
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
