Why flet wins, was Re: scheme seems neater

From: Jeff Dalton (jeff_at_todday.inf.ed.ac.uk)
Date: 04/08/04 

Date: 07 Apr 2004 23:42:07 +0100

Sunnan <sunnan@handgranat.org> writes:

> > And the disadvantage of using flet would be...?
>
> It's a disadvantage for implementors and for learners of the
> language. It's brain clutter.

But natural languages are quite cluttered. It's far from clear that
all "clutter" creates problems for learning.

Natural languages also have a lot of redundancy, which tends
to make it easier to get the intended meaning.

Common Lisp is more like a natural language than Scheme is.

They very things that seem bad about Common Lisp to someone
wanting a maximally rational design are, arguably, good.
Or at least harmless, low cost. Otherwise, they'd have
been eliminated somewhere along the way. Probably.

Languages that evolve, that are shaped by use and history,
become adapted to human needs. They can be better adapted
than the language you get from a rational design.

>From the rationalist point of view, Common Lisp's namespace
decisions may seem arbitrary. Why have those particular ones?
Why not a namespace per type? What is the argument that shows
Lisp-2 is best?

In fact, a namespace per type is not a completely mad idea.

In mathematics, a number of different alphabets and fonts
are used, so that it's usually clear what kind of thing
each symbol refers to.

Sometimes, the conventions change. For example, in model
theory, strange-looking German script letters were used
for models. But after (quite) a while, model theorists
started using ... (wait for it) ... M. And other ordinary
capital letters.

(This is, for most people, easier to read.)

So, in effect, mathematicians use lots of namespaces. That
they use A for something doesn't stop them from using
alpha, or lower-case a, or bold A, for another.

But programming languages haven't gone that way, for a
variety of reasons. Probably, that's a good decision.
That doesn't mean that anyone has an argument that shows
it is absolutely the right decision.

Note that programmers often create namespaces by convention.
In Java, class names begin with a capital, method names to
not. So you can have a class and method of the same name
(modulo case).

A naming convention, perhaps enforced by the language, is an
alternative to having separate function and value namespaces.
In Common Lisp, we have the *-name convention for specials,
which helps keep them from interfering with ordinary variables.

So there are many possibilities, and Common Lisp is at a
point in this space. I think it's likely that the combination
of design and history that led to current Common Lisp has
placed it at a not-too-bad point, regardless of how arbitrary
that position seems from maximally rational point of view.

-- jd

Relevant Pages

  • Re: CL & Practicality
    ... but Java probably has more than twenty times as ... > many as Common Lisp, depending on what you consider to be the equivalent ... You're conflating core language and core language+library issues but yes, ... the best way to discover the practicality of Common Lisp is to ...
    (comp.lang.lisp)
  • Re: How Common Lisp sucks
    ... necessities in today's world. ... getting acceptance of a considerable number of members in the Common Lisp community. ... Now you are apparently invoking a defacto standard. ... If we don't find a single example for changing the language in a fundamental way that would actually make the language easier to understand for newbies without loosing expressiveness, ...
    (comp.lang.lisp)
  • Re: pseudo code v/s algorithm
    ... insert your language here) than code. ... There is absolutely no difference between algorithm and code, ... If I have an implementation or pseudo-code it cannot be ... just have a look at the sources of some Common Lisp ...
    (comp.programming)
  • Re: Noob Wonders: Lisp-1 vs. Lisp-2
    ... “Now, the question is, why do Lisps before Common Lisp have this multi- ... language that is characterized by uncommon or pretentious ... losing the debate, and I felt it wasn't for reasons I considered "fair". ... using the term "Scheme" as the opponent position. ...
    (comp.lang.lisp)
  • Re: Lex, Yacc, and Lisp...
    ... Common Lisp specification. ... I have been involved both in implementing languages for Java and for Common Lisp. ... If you take a look around in the Java world what language extensions people are working on, and risk to take a look behind the scenes, you can tell that this is mostly the same everywhere. ...
    (comp.lang.lisp)