At 03:57 PM 9/25/00 -0400, Ben Tilly wrote:
>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. :-)
Viabiliy in the short term, yes. Long term? We'll see how the perl 6 task
goes. Perl's life as a 'real' programming language really began with perl
4, and is on the decline. It's certainly not gone anywhere near it's full
potential. (Speaking purely from an internals standpoint) Having only one,
volunteer-supported, implementation is a big reason for this. (And for
those of you playing along at home, I am *not* advocating perl going
corporate--I rather like the current state of affairs. Regardless, if the
VMS/Solaris/AIX/HPUX/Apple engineering departments dedicated a half-dozen
full-time engineers to perl we'd see a significantly faster and cleaner
system...)
>>>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!"
That's actually not that bad--it means you can't make your embedded app be
perl. You can still embed the core interpreter into, for example, a CAD app
and use it as your scripting language. I think.
>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...
Yeah, you've got to get them right enough the first time, and then live
with the consequences. I'm seriously thinking of instituting an "All code
submitted to the repository belongs to Larry" rule until we have this
hashed out, so there's only one copyright holder to deal with.
>[...]
>>>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.
Portable? Think not. Mostly portable, sure. (My main platform's VMS,
followed by (ick) Windows, and then Linux, with some smattering of Mac
stuff) Perl still has portability issues if you stray outside the language
into OS territory. It's no different than
C/C++/APL/PostScript/Forth/whatever in this regard.
It's also given us a relatively sluggish language. (Snappy interpreter,
yes, but we have the potential to do significantly better)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
