Re: How Common Lisp sucks



In article <873bg4eysu.fsf@xxxxxxx>, Bill Atkins <NOatkinwSPAM@xxxxxxx>
wrote:

Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:

In article <87lktww3hs.fsf@xxxxxxx>, Bill Atkins <NOatkinwSPAM@xxxxxxx>
wrote:

Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:

In article <873bg70w8u.fsf@xxxxxxx>, Bill Atkins <NOatkinwSPAM@xxxxxxx>
wrote:

Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:

In article <87irp30xjj.fsf@xxxxxxx>, Bill Atkins
<NOatkinwSPAM@xxxxxxx>
wrote:

I view this whole situation as somewhat analogous to the state of
Linux.

Except that Linux has a process for managing change, which IMO
contributes significantly to its success.

rg

If you are referring to the kernel proper, then yes. But if you are
referring to the operating system created by a distro, then there is
no central control except the distro's.

Correct. I would say that the kernel plays a role analogous to the
hyperspec in CL, and the fact that Linux has a process for managing
change in the kernel contributes to its success.

If Linux were like CL, the kernel design would have been frozen at some
point in its history. I think it's pretty clear that if that had
happened Linux would not be nearly as successful as it is today.

rg

As you're so fond of pointing out, the details are not important here.
But, to clarify, Linux and BSD are both implementations of POSIX as
SBCL, CLISP, Allegro, etc. are implementations of Common Lisp. This
is what's important for understanding my analogy. What you're talking
about would be analogous to SBCL, for example, freezing its features.

No. The POSIX standard is analogous to the hyperspec. Linux and BSD,
as implementations of Posix, are analogous to, say, SBCL and CLisp.

I don't get it. Isn't that exactly what I just said?

The part I took issue with was: "What you're talking about would be
analogous to SBCL, for example, freezing its features." That certainly
doesn't sound like what I'm after, which is a process for managing
change. "Freezing" anything sounds to me like the exact opposite of
what I want.

Also, because the CL community is much smaller than the posix community
there is a real danger of losing crtical mass if it fragments across
multiple implementations the way posix has.


I don't think that the lack of a standard sockets API is laughably
trivial.

Hence compatibility layers.

Developing and maintaining them can involve significant effort. That
effort might be more profitably spent elsewhere, like developing new
functionality. CL is not exactly flush with resources as far as I can
tell.


if the
productivity gains involved from using Lisp dominate the upfront
hassle of making sure a library works on your implementation or of
implementing a compatibility layer, is it not better to use Lisp and
spend some time gettings things set up?

No, because in addition to the up-front costs, I also have to accept the
risk that nasty surprises are lurking. For example, suppose I get
everything up and running and then find that under heavy load my Lisp
implementation crashes. The developers of my implementation may or may
not be able to help, and switching to another implementation may or may
not work. The only data point I have to help me assess the probability
of this scenario is that it already happened in one very prominent case
(Reddit). That makes me very leery.

And if you find out CPython can't handle your application, how are you
in a better position?

That depends on exactly *how* it can't handle the application.
Different problems have different solutions. If it's too slow, for
example, I might address that by buying more servers. But CPython is
VERY unlikely to give me the kind of nasty surprise that requires me to
give up and try over again (like random crashes). Too many people are
using it for that kind of bug to go unnoticed for long.

Here's another anecdote: while I was still at JPL I whipped up a thing
called SDS (State Database System). It was a pretty standard web app.
Exactly what it did doesn't matter. I wrote it in MCL and used the
included database (called WOOD -- William's Object Oriented Database)
for non-volatile storage. It worked like a charm -- for a while. Then
one day the database was corrupted. I don't know why, and I probably
never will, because I'm pretty sure I am the only person on the planet
who has ever used WOOD for a real application. And I will probably be
the last too (which is unfortunate, because in some ways WOOD was really
cool).

But I will never again entrust important data to anything but MySQL.

rg
.