PDS aftermath: .nqp programs in Parrot core

[Will Coleda]

On Mon, Jan 31, 2011 at 9:55 AM, Moritz Lenz <moritz at faui2k3.org> wrote:
> Am 31.01.2011 15:30, schrieb jerry gay:
>>
>> the concern with parrot supporting the new nqp is that any tools we
>> write using nqp can be easily ported to any other vm.
>
> The problem with Microsoft Office supporting open standards is that it
> breaks the lock-in relation to its customers.
>
> I personally hate that approach.
>
>> however
>> altruistic, portability from parrot to other backends is not currently
>> one of parrot's goals.  in fact, chromatic, myself, and others believe
>> it may be harmful to parrot's future to support portability of
>> nqp-based parrot tools to other backends. parrot is simply not in a
>> position to compete with more mature virtual machines yet, and the
>> risk that the new nqp's portability poses is significant.
>
> I also see a chance: if there's no thread of a lock-in, the potential costs
> of starting a parrot-based project are much lower, because you have the
> option to migrate away if necessary.
>
> From a philosophical point the question needs be asked (and answered) if
> parrot wants to be an open or a closed platform. So far I had the impression
> it was striving to be an open platform, but these remarks from chromatic and
> particle make me seriously doubt that. I'd like to hear the opinions from
> other parrot developers on this point.

I am not convinced that this is a problem. I certainly don't expect,
as a parrot developer, to actively work on these tools*, but find the
thought that supporting portability is harmful... strange.

The portability will flow both ways - if we have a compelling product
(either through technology or licensing, or morbid curiosity), the
portability of one of the languages targeting us (that itself is
designed to be a target for other languages) should provide another
potential path for people to come /to/ parrot.

>> none of this prevents parrot from continuing to use the existing
>> nqp-rx. it is likely that no change to parrot's nqp-based toolchain is
>> necessary, however small changes may be desired (or required) to make
>> clear the distinction between the new nqp and nqp-rx. parrot may not
>> even need to fork nqp-rx, if the nqp team agrees to give over
>> ownership of nqp-rx to parrot, or agrees to give parrot folks liberal
>> commit rights to nqp-rx.
>
> I don't know of any cases where parrot developers have asked for access to
> nqp-rx, and have been denied it. So I guess it boils down to "no problem".
>
> In fact I've pointed out that option myself:
> http://irclog.perlgeek.de/perl6/2011-01-31#i_3237158 (though I'm not
> entitled to speak for the nqp team as a whole).
>
> Cheers,
> Moritz
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>

* But as an occasional developer of other languages, it's certainly a
possibility.


-- 
Will "Coke" Coleda