RE: RFC idea

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.