Dan Sugalski wrote:
[...]
>>As soon as you get many implementations, you start to get into
>>the portability nightmare. We differ on how much of a problem
>>we think that is.
>
>Multiple implementations are good. All the languages that've had long-term
>viability have had multiple implementations. (Things like C, Fortran, and
>VOBOL spring to mind. C++ and Java look to duplicate that as well)
I would use Perl as an example of something with long-term
viability and one implementation. :-)
[...]
>>Actually the current license discourages embedding Perl. Very
>>specifically it allows embedding Perl but only if you embed the
>>whole thing. If an AL style license is kept then it needs to
>>be more flexible in this regard. (I was more flexible in this
>>regard!)
>
>I'm not sure of that. I think you could get by embedding the perl code in
>the executable if you didn't actually call it perl (saying you were
>perl-compatible or something would be OK), but I may be wrong.
Just re-read it. You can embed if it you document all of
the way. (Using 3 and 4.) You can embed the whole thing
(section 5). You can not expose any interfaces and do what
you want (section 8). Given that section 8 was added to the
license at a later date, anyone using it does stand in some
possible danger that an early copyright holder could always
come up and say, "Hey! I never saw that and don't want you
to do that either!"
Patching a license is not as simple as patching code since you
are after the fact telling people they agreed to something
that they did not agree to...
>Regardless, embedding was a serious pain. I aim to fix the technical side,
>and I'm glad you're addressing the licensing side. :)
s/addressing/trying to address/; # :-)
[...]
>>It isn't important until you try to run my script and it doesn't.
>>
>>This is the nightmare of JavaScript. This is one of the reasons
>>that I prefer Perl over Java. This is...you know my opinion.
>>But I recognize the benefit as well. I don't think it is a
>>*bad* choice, but I think it is a choice to be made with open eyes
>>and recognition of the tradeoffs.
>
>Believe me, as someone working mainly on a platform who's C compiler
>*isn't* GCC, I'm well aware of the 'fun' one can have with multiple
>implementations of the same language.
That is a 'joy' that Perl has so far largely avoided. Which is
why Perl has done such a good job of delivering portable code.
>I'm still firmly convinced that it's a profoundly good idea. Yes, having
>the source freely available takes off some of the pressures we might
>otherwise see with a closed-source language (Though for all that it's
>nasty, Visual Basic manages reasonably well that way), but we really won't
>see perl fully mature until its development is ultimately out of the hands
>of any one group.
I am not disagreeing. There are many things to be said for
having multiple implementations.
Cheers,
Ben
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Share information about yourself, create your own public profile at
http://profiles.msn.com.
