On Mon, Jan 31, 2011 at 9:55 AM, Moritz Lenz <[email protected]> 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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
