From: Rainer Joswig
Subject: Re: Learning curve for common lisp
Date: 
Message-ID: <joswig-0401992049410001@pbg3.lavielle.com>
In article <···············@varese.cs.uchicago.edu>, Soren Dayton <···············@cs.uchicago.edu> wrote:

> Some friends and I are thinking about a project, and we were wondering
> about using CL (including CLOS).  Given backgrounds with C++,
> etc. (fairly substantial) and Scheme and ML (less substantial) what sort 
> of learning experience should we be expecting?  

With substantial programming experience and a fair bit of reading
existing CL code, one should be able to write *good* code
after a year. "Good" depends for example on the scale
of your project. If you want to implement a really complicated
program in CL, then you might have to deal with, say, 100k lines
of dense code. Don't forget that you also might have
to learn how to use some new libraries, which might
be very different from what you are used to (say, a
logic formalism or CLIM).

The most important thing is to have a model for the Lisp
computation in your mind (lambda calculus, objects, ...).

> Given the size of CL, we are a little worried that we'd begin by writing
> pretty lousy code, and have to go back at some point and rewrite some
> stuff.  Is this a serious problem?

Depends. Your initial design of your application is the critical
part. If you have a good conventional design you should
be able to move your code around - better than in
a static language. Either code changes have small effects
(changing a class often can be done in a running program)
or you may be able to write tools to introduce large
changes.

You will make really fast progress once you learn not to implement
your application in Common Lisp, but in a language suited to
solve your problem. This language should be implemented in
Common Lisp (Common Lisp is a programmable programming language).
Let macros generate your code.

Write tools to manage and to visualize your application.

Learn to work with CL environments - not against them.
Everything is dynamic - there is a reason for that.

>  What sort of time scale should we be
> aware of? When will we hit that point?

For a more specific answer we would need to know something about
your project.

-- 
http://www.lavielle.com/~joswig