Re: How Common Lisp sucks
- From: Ron Garret <rNOSPAMon@xxxxxxxxxxx>
- Date: Sun, 23 Apr 2006 14:34:19 -0700
In article <87lktww3hs.fsf@xxxxxxx>, Bill Atkins <NOatkinwSPAM@xxxxxxx>
Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:
In article <873bg70w8u.fsf@xxxxxxx>, Bill Atkins <NOatkinwSPAM@xxxxxxx>
Ron Garret <rNOSPAMon@xxxxxxxxxxx> writes:
In article <87irp30xjj.fsf@xxxxxxx>, Bill Atkins <NOatkinwSPAM@xxxxxxx>
I view this whole situation as somewhat analogous to the state of
Except that Linux has a process for managing change, which IMO
contributes significantly to its success.
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.
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
You don't have to unify the implementations, just (certain parts of)
How do you suggest we build "a process for change" in light of these
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
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
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:
Imagine how out of control the discussion could get if we started
drilling down into those details here.
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.
- Prev by Date: Re: How Common Lisp sucks
- Next by Date: Re: How Common Lisp sucks
- Previous by thread: Re: How Common Lisp sucks
- Next by thread: Re: How Common Lisp sucks