Re: How Common Lisp sucks

In article <4aicgnFtboomU1@xxxxxxxxxxxxxx>,
Pascal Costanza <pc@xxxxxxxxx> wrote:

I'm going to point out just three problems with CL. There are more.
None of these are original observations.

1. CL lacks standardized support for many operations that are
necessities in today's world (e.g. sockets, database connectivity,
foreign functions). Moreover, it lacks any mechanism by which these
features could be standardized.

It lacks any _sanctioned_ mechanism for standardization. There is
certainly a mechanism for creating defacto standards.

That's news to me. What is it?

It is claimed that there are portable
libraries that work across implementations that provide de facto
standards, e.g. UFFI, but these claims are false.

You probably don't mean what you say here. There are definitely portable
libraries out there. Maybe not for foreign function interfaces (I can't
judge this), but certainly for other things.

Of course there are portable libraries, just not for the things that
matter in today's world.

The same holds for global dynamic variables: If you use them before you
have defined them, you are invoking undefined behavior. So there is no
difference between global dynamic and global lexical variables here.

Aw, geez, let's not descend into quibbling over these details. You know
perfectly well that every implementation handles an undeclared free
variable reference by assuming it's a dynamic reference.

If you reference
a global before defining it then you're screwed. The latter cannot be
done at all within CL unless you write a full code walker. But adding
this capability is utterly trivial within an implementation. In MCL it
takes two lines of code. And if it were done it would result in
strictly greater expressive power.

The difference between (funcall (some-expression)) and
((some-expression)) is not that of fundamentally different expressive
power.

You're right, I misspoke. It's not a matter of expressiveness, it's a
matter of verbosity. ((...) ...) is spelled (funcall (...) ...). But
my point is that if you don't like all that extra verbiage there's no
way to change it, and no good reason why you shouldn't be able to.

(Note that increased expressive power is not necessarily a good thing.
Consider the "come from" statement in Intercal as a counter example,
which also mean an increase in expressive power when added to Common Lisp.)

Yes, a good point.

Furthermore, it is not even
necessary to agree on the semantics of ((...) ...). One could simply
add a new macro defining form (or even a global variable) to set a
user-definable hook for transforming expressions whose CARs are lists
that do not begin with LAMDBA. All that would need to be agreed upon is
the name of this form. Furthermore, this would result in strictly
greater expressive power. It would be strictly backwards-compatible.
And It would serve the needs of a number of users who are not currently
being served (e.g. those who prefer to do functional-style programming
without having to type FUNCALL all the time.)

You would have to define a way to delimit the scope of the different
possible hooks, otherwise it becomes a nightmare to try to mix and match
different third-party libraries.

Fine, make it a hook function then. Now all we need to agree on is the
name of the variable.

But despite the fact that this change is easy and only good could come
of it, it does not happen because there is no process by which this
change can be effected (which is, I believe, a direct consequence of the
fact that the realities of CL politics are that CL is utterly resistant
to all change, though I would dearly love to be proven wrong on that).

The change you propose is easy to make, but the consequences of it are
not necessarily easy to deal with.

I don't have the impression that the CL community is resistant to
change.

Really? Then why has there been no change in CL in a decade?

See the various projects in various places that are quite
healthy, as far as I can tell. (If I remember corretly,
http://cl-user.net counts more than 600 entries.)

Non-sequitur. There is a big difference between writing code in the
language and making changes to the language.

(Oh, and anyone who wishes to prove me wrong, please not that there is a
big big difference between effecting change in CL and effecting change
in an implementation of CL.)

Sure. But do note that the language constructs that are part of Common
Lisp have been tried in other Lisp dialects before. I think that picking
a single Common Lisp implementation and experimenting with language
constructs there to see whether they pay off before proposing them as
official features is the healthier approach.

Indeed. I'm not saying that we should dive wholesale into a redesign.
All I'm saying is that there ought to be an end-game for the process.

3. Much of CL's core is badly designed. For example, consider NTH and
ELT. The functionality of ELT is a strict superset of NTH, so why have
NTH cluttering up the language? (To say nothing of the fact that the
order of the arguments in these two functions are gratuitously
reversed.) Why is the function that computes the difference of two sets
called SET-DIFFERENCE, but the function that computes the intersection
of two sets called simply INTERSECTION? And why do all of these
functions operate on lists, not sets? It's because there are no sets in
CL, which means that CL leads one to prematurely "optimize" sets as
lists. (I put optimize in scare quotes because in fact this is rarely
an optimization, especially when your sets get big, and most of the time
you have to go back and rip out huge chunks of code to replace your
lists with hash tables or binary trees.) I could go on and on.

These features exist all for backwards compatibility. They could at most
be deprecated, otherwise you would break a lot of existing code. I am
certain that this would do more harm than bring any benefits because the
community is, I think, not large enough to rewrite the large amount of
useful code that does exist.

IMO, just having the ability to (semi-)officially deprecate cruft, even
if it never actually goes away, I think would have enormous payoffs.
But we don't currently have that ability.

It's trivial to define your own package with the name and argument
conventions that you prefer. There is no need to force anyone else to
use the same conventions.

Yes there is: it makes life VASTLY easier for newcomers if the actual
language (as opposed to someone's private library) is not full of random
crap.

This, by the way, is the crux of SteveY's point. It often gets
overlooked so it bears repeating: it's all about how accessible the
language is to newcomers. If the language is full of random crap then
it becomes less accessible to newcomers. A library that covers up the
crap doesn't help nearly as much as actually cleaning the crap up.

Now, for those of you who wish to respond I ask you to keep in mind the
following:

1. The details of my criticisms are mostly irrelevant. What matters is
that CL is far from perfect, and that it has no mechanism for change.
So don't bother picking a nit about one of my specific criticisms unless
you wish to argue that CL is perfect and doesn't need to change.

These nits would have to be picked in case we had an official mechanism
for change. So it's a good exercise to do this already, in order to be
able to estimate whether the installation of an official mechanism would
be worthwhile.

No, because in the absence of a process the argument can be sustained
indefinitely with no resolution. Those who oppose change will falsely
claim that this is evidence that adopting a process for managing change
is hopeless (or useless, or some such thing).

I think there are better examples than the ones you propose.

Of course there are. If you think that is relevant then you have
completely missed the point.

rg
.

Relevant Pages

  • Re: Why why why? (Was: Re: Vertical alignment of text within a DIV)
    ... but a full rendering implementation for every possible display ... Remember that back when these standards were written ... there was very little in terms of cross-platform display libraries. ... It's the 'any language' bit, ...
    (comp.infosystems.www.authoring.stylesheets)
  • Re: How Common Lisp sucks
    ... There is certainly a mechanism for creating defacto standards. ... There are definitely portable libraries out there. ... What matters in today's world varies heavily across different users of Common Lisp. ... Peter Seibel has done a very good job of attracting newbies without any change to the language at all. ...
    (comp.lang.lisp)
  • Re: Python does not play well with others
    ... you have to undestand that python is not like other languages. ... what some people actively developing the language are actually doing with it ... Libraries, on the other hand, ... Something like that happened to the C++ standards committee. ...
    (comp.lang.python)
  • Re: future C standards
    ... keeping C a vital and relevant language in the ... The thing about libraries is that they don't require the ... blessing of official standards to be useful. ...
    (comp.std.c)
  • Re: R6RS Ratified
    ... 20 years of history of formally developed language ... Economically speaking, formal language standards ... sell a new commodity to corporate customers. ... Formalization ...
    (comp.lang.scheme)