Re: becoming a lisp developer

[Pascal J. Bourguignon]

ken <gebser@mousecar.com> writes:

> People familiar with C say it's a difficult language.  But I guess
> they never tried it.  You can pick up a book on it and if you give it
> a little bit of time every day, you can learn enough in a week to
> write interesting and working programs.  And it's fun.  Shell
> programming like bash and ksh are easy and fun too.  C++ too, but to a
> lesser degree. But elisp....  I tried repeatedly over more than ten
> years to learn it, bought and read a couple books on it, did some
> tutorials, of course spent a lot of time in the docs, but it wasn't
> until just a few years ago (and with a lot of help from this list)
> that I was able to write my first elisp program.  I started a second
> one last year and I'm still plodding really slow through it (but not
> often).  It takes so long to get things to work that I'm discouraged
> from spending time on it.  Half the time I'm trying to figure out the
> code and moan to myself that, if I could write this function in C, I
> would have had it written in one-tenth the time... or less.  Then,
> after I've written some working elisp code and look at, I see it's not
> that difficult.  So how is it that it took so long to figure out?

The fact is, there are big categories of languages. 

C and Pascal are the same.  C or C++ are almost the same (compare Homo
Sapiens Sapiens with Homo Neandertalis).  All the common languages fall
into the Algol category of languages; basically, when you know one, you
know all of them: the semantics are fundamentally the same, only the
unimportant syntax changes.

But beside the Algol category, there are:

- the logical programming category (Prolog, etc),

- the lisp category (eg. Common Lisp, Emacs Lisp, Scheme, and a lot of
  older lisps)

- the functional programming category (Haskell, ML, Ocaml, etc).

and a lot of others.
http://en.wikipedia.org/wiki/List_of_programming_languages_by_type


When you change of language category, the syntax may change or not, but
importantly, it's the semantics that change.  That's where you may be
misled and have to spend more learning time.


For example, syntactically, adding two numbers is written:

     {
        int a=1;
        int b=1111111112;
        int c=1111111113;
        a=b+c;
     }

in C, and:
    
    (let ((a 1)
          (b 1111111112)
          (c 1111111113))
      (setf a (+ b c)))

in lisp.  But the syntac is irrelevant.  You can easily write a
pre-processor to convert one into the other. 
(See for example: http://paste.lisp.org/display/25134)


What's more important to understand the meaning of those programs, is
their semantics.

In a 32-bit C, (ie. a C where int has a 32-bit two-complement
representation), the result would be -2072745071 with some compiler.
(In some other C compilers, it could signal a run-time error, the C
standard doesn't specify what must happen).

In a 64-bit C, (ie. a C where int has a 64-bit two-complement
representation), the result would be 2222222225.

In a 32-bit emacs, which has no bignums and where fixnums are limited to
29-bit two-complement the result would be 74738577.

In a 64-bit emacs, which has still no bignums, but where fixnums are
limited to 61-bit two-complement, the result would be 2222222225.

In a Common Lisp implementation, which therefore has bignums, whatever
the size of the fixnums, the results would be 2222222225.



So you can see that the meaning of a simple operation such as a=b+c or
(setf a (+ b c)):

1- is NOT specified entirely by most programming languages.

2- is specified entirely in some programming languages.

3- when it's specified (be it by the language or by an implementation),
   MAY or MAY NOT mean the same thing (ie. give the same results).


The semantical differences are therefore:

In Common Lisp, + for integers implements the mathematical integer
addition (up to the available memory). 

In emacs lisp, + for integers implements the addition modulo 29 or 61
depending on the machine word size.

In C, + for int may implement the addition modulo 32 or 64, or something
else (including signaling a run-time error, or a compilation-time error).


And this is only for the simpliest of the operation.  In the code sample
above, there are other semantic differences, like the fact that in lisp
there are no statement, therefore all expression returns a value.  setf
returns the last value assigned.  let returns the result of the last
expression in its body, so the let form actually returns the result of
the addition, and if you evaluate it in a REPL (read eval print loop),
then this result will be printed too.  On the other hand, {} is a
statement in C, which has no result value and nothing is ever returned
or printed by that code sample.  The let form is a valid lisp expression
as it is.  The {} however does not stand alone: you need to wrap it in a
C program to make it really meaningful.  There's the fact that in C,
types are a property of the variables, while in Lisp types are property
of the values.  The fact that setf is actually a macro, that while it's
provided by the language, could be written by the user if it was
missing, like any other macros, vs. the fact that = is a hard wired C
operator and the user can't add new operators (it's possible for some of
them in C++, but with vastly different mechanisms and semantics than
lisp macros).  Etc.


The conclusion is that to learn a programming language in a different
category of what you know already, you must forget what you know, and
just learn it from the beginning.

And the existance of those different broad categories is also the reason
why you are told to learn different programming languages.  But learning
C and C++ doesn't count.  You must pick one language in each category!


Since you already know C, you should learn at least Prolog, one lisp
(but it's also useful to learn elisp, scheme and Common Lisp),  Haskell,
APL and Smalltalk.



> Maybe, if I live to be three hundred, I'll write an elisp book myself.

Usually it comes much fater.

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.