Re: How Common Lisp sucks

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.

There are two significant differences between the Posix community and
the CL community.

First, the Posix community has processes for developing and evolving
standards beyond Posix (e.g. the standard C library, the C++ template
library, etc.). The CL community has no analogous process.

Second, the size of each branch of the POSIX community is vastly larger
than the entire CL community all put together. So the posix community
is better able to withstand the negative consequences of Balkanization
than the CL community can.

But really, the details don't matter. The gist of my argument is that
once fragmentation occurs, it's not always possible to unify the
differing implementations.

You don't have to unify the implementations, just (certain parts of)
their APIs.


How do you suggest we build "a process for change" in light of these
facts?

It seems pointless to answer that question in the absence of agreement
that there is a problem that is worth addressing.

You claimed in a recent post that you had made suggestions on
how to fix things; I don't remember reading anything even remotely
like that. Do you disagree that de facto standards are not a
reasonable bridge to get Lisp from near-oblivion to some shadow of its
former glory?

I think it's important that the standards be codified and that there be
some mechanism for "officially" marking the transition between "under
consideration" (or under development) and "adopted." Right now the
transition is too fuzzy. It makes it too hard to tell whether one can
rely on a particular feature.

Also, why have you failed to produce any more than two or three
laughably trivial examples to explain why Common Lisp "sucks"?

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

I chose a few trivial examples because it's easier to argue the merits
of trivial examples than complicated ones, and I didn't want to get too
bogged down in arguing the benefits because that's not the point.

If you want non-trivial examples, there are lots of those too. The MOP
for example. Or anything listed here:

http://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Issues/Issues-Ca
tegorized.html

Imagine how out of control the discussion could get if we started
drilling down into those details here.

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.

If there were e.g. standardized library APIs that would help by making
it easier to assess how many implementations out there conformed to the
particular APIs that I was relying on. Looking at the specs to see if
an implementation conforms (or at least purports to conform) to
specification X, Y and Z is a lot easier and cheaper than actually
trying it (especially if in addition to trying it you actually have to
generate specifications X, Y and Z).

If you truly do care about
installing libraries, why not sit down and write some code to fix it,
instead of clogging up comp.lang.lisp with this rubbish?

Because the problem I am talking about cannot be effectively addressed
merely by writing code. If you think it can then you have not
understood the problem.

rg
.

Relevant Pages

  • Re: How Common Lisp sucks
    ... vs that of producing a minimal CL based on the CL standard). ... Fortunately there is a much closer analogy which is that in both areas ... multiple implementations (Linux, Solaris etc and LispWorks, CMUCL etc). ...
    (comp.lang.lisp)
  • Re: struct mapping problem (gcc on Linux)
    ... standard in preference to reality. ... The OP had an issue with gcc on Linux not doing what he expected. ... Whether he knew it or not, the C language standard can't help him ... knowlege of actual implementations is at least as ...
    (comp.lang.c)
  • Re: Requesting advice how to clean up C code for validating string represents integer
    ... Linkname: c standard - clc-wiki ... with a signed zero (including all IEC 60559 implementations) ... that follow the specification of annex G, the sign of zero ... between brake pedal and brake pads being through a complicated ...
    (comp.lang.c)
  • Re: Storgae durations
    ... standard you referred to is no longer current. ... advocating C99 and saying that C90 is obsolete, ... Then you are in no position to make an argument about C99's portability ... there are implementations for C99 that target those platforms. ...
    (comp.lang.c)
  • Re: idea: on the issue of C and language extensions
    ... features; this route would be based mostly on something like a mailing ... implementations, yet far lighter weight and informal than forcing ... extensions they have done already... ... When parts of the Standard released by such a major organisation like ...
    (comp.std.c)