Why don't people like lisp?

[Kaz Kylheku]

Alex Martelli <aleax at aleax.it> wrote in message news:<rDYkb.320434$R32.10609926 at news2.tin.it>...
> Pascal Costanza wrote:
> > Exactly. Lisp-style Macros make these things a breeze. The other
> > alternatives you suggest are considerably more complicated. As I have
> 
> What's "considerably more complicated" in, say,
>     my_frobazzer = frobaz_compiler('''
> oh my pretty, my beauteous,
> my own all my own special unique frambunctious *LANGUAGE*!!!
> ''')
> and later on call my_frobazzed(bim. bum, bam) at need? 

The problem is that

    program = compiler(character-string)

is too much of a closed design. A more flexible design resembles:

    abstract-syntax-tree = reader(character-string)

    target-syntax-tree = translator(abstract-syntax-tree)

    program = compiler(target-syntax-tree)

The input to a compiler should not be a character string, but
structured data.

> The complexity
> of the frobaz_compiler factory callable depends exclusively on the
> complexity of the language you want it to parse and compile, and you

In Lisp, the complexity of the compiler is constant; it's a language
builtin. The complexity of the reader depends on the complexity of the
lexical properties of the language, and the complexity of the
translator depends on the semantic complexity of the language.

> The vast majority of applications has absolutely no need to tinker
> with the language's syntax and fundamental semantics.

This is a common fallacy: namely that the difficulty of doing
something, and the consequent infrequency of doing it, constitute
evidence for a lack of need of doing it. In fact this is nothing more
than rationalization: ``I know I have inadequate tools, but I really
don't need them''. It's not unlike ``I can't reach those grapes, but I
know they are sour anyway''.

In Lisp, tinkering with the syntax and semantics is done even in
trivial programs.

By the way, your use of ``fundamental'' suggests a misunderstanding:
namely that some kind of destructive manipulation of the language is
going on to change the foundations, so that existing programs are no
longer understood or change in meaning. This is not so: rather, users
extend the language to understand new constructs. The fundamental
syntax and semantics stay what they are; they are the stable target
language for the new constructs.

> When you need
> a language with different syntax, this is best treated as a serious
> task and devoted all the respect it deserves, NOT treated as "a
> breeze".

This is a common viewpoint in computer science. Let me state it like
this: ``language design is a Hard Problem that requires you to whip
out lexical analyzers, parser constructors, complex data structures
for symbol table management, intermediate code generation, target code
generation, instruction selection, optimization, etc.'' But when you
have this:

    abstract-syntax-tree = reader(character-string)

    target-syntax-tree = translator(abstract-syntax-tree)

    program = compiler(target-syntax-tree)

you can do most of the language design work in the second step:
translation of syntax trees into other trees. This is where macro
programming is done, and there is a large amount of clever
infrastructure in Lisp which makes it easy to work at this level. Lisp
contains a domain language for language construction.

> PARTICULARLY for domain-specific languages, the language's
> designers NEED access to domain-specific competence, which typically
> they won't have enough of for any domain that doesn't happen to be 
> what they've spent many years of their life actually DOING (just

Bingo! This is where Lisp comes in; it gives the domain experts the
power to express what they want, without requiring them to become
compiler construction experts. This is why Lisp is used by some
artificial intelligence researchers, biologists, linguists, musicians,
etc.