"Erann Gat" <gNOSPA...
@flownet.com> wrote in message
So, you think that the necessity for someone to port the implementation
> In article <2fvjemF2uf0...
> "Will Hartung" <wi...
> > Lack of standards is not "holding" CL back. It's lack of developers with
> > will to solve their problems using the language. Or, for those with the
> > will, they're simply not "sharing", for whatever reason.
> And that "whatever reason" could very well be standards. I, for
> example, wrote some lightweight database code (motivated by the fact
> that none of the shared code out there worked when I tried it), but I
> haven't bothered to share it because it's MCL-specific, and so I have
> judged the potential audience too small to be worth the bother of making
> the code suitable for distribution.
specific bits of your code to their platform will outweigh any benefit your
portable code will offer them? That porting will be harder for them than
writing what they need from scratch?
The strange thing I see here is that you're willing to throw the baby out
> > At this point, we'll cue the "don't want to pay for CL" threads. Of
> > this has nothing to do with standards either.
> Of course it does. The Lisp code I run on my Mac won't work on any Lisp
> I can get for my Linux machine -- whether or not I pay for it. The
> reason I don't buy a Lisp for Linux is not because I'm unwilling to pay
> for Lisp (I pay for the Lisp I run on my Mac) but because paying for it
> won't do me any good. And the reason it won't do me any good is
> directly related to the lack of standardization for functionality that
> is basic for modern computing.
with the bathwater. Perhaps the GUI is the One Thing keeping you on MCL.
GUIs are a mess in any cross platform project, in any language. Java's been
struggling with this since the get go, and they're working on their 3rd
version now. (AWT, Swing, SWT). So, I'm going to punt on that point, just
toss it aside. It's a deep, dark, black hole, and we all know that.
Also, I'm ignorant of how MCL deals with networking. Maybe they do some
wacky stuff above socket, listen, accept, connect, read/write and select.
But it's hard to fathom what. Most of the Lisp socket implementations seem
to expose that high level aspect of the API. Most don't go down into the
deep nuances of TCP and IP that the raw, low level APIs of the Berkley
Sockets, but most applications don't need that level of detail. Maybe your's
Most of the "threading" implementations seem very similar to the CLIM model
as well, but again, I don't know anything about MCL. Of course some of those
implementations differ as to whether they use native threads or not. I think
even Franz's implementations vary across platforms, tho the API is the same.
But, basically, you're saying that the level of platform dependence of your
Lisp code is so ingrained, that it's not even worth pursuing to port it to
your Linux machine. Best throw it all out and start new on the Linux box.
That it is not worth implementing the MCL specific calls on your Linux Lisp
to port your code. It is simply too difficult, and the code isn't worth it.
Does it affect casual porting of the code? Sure it does. But even conforming
implementations have issues porting code, even if they implement the same
APIs. Look at the difficulty of porting Unix apps to Mac OS X. Porting those
apps to Mac OS 9-- were Just Too Hard. But now that there is "more unix",
applications and code can more easily be bent to work on OS X, so porting is
worthwhile vs tossing it all away and starting anew.
But if you were willing to post your code, perhaps someone else would find
the value of the code worth the effort to actually port it, then again,
maybe it simply relies too much on the MCL implementation.
We we're mostly talking sockets and threads here I thought.