Subject: Re: Learning curve for common lisp
From: Erik Naggum <>
Date: 1999/01/04
Newsgroups: comp.lang.lisp
Message-ID: <>

* Soren Dayton <>
| 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?

  there'll be an effort to unlearn the expectation to let the compiler tell
  you what you have missed.  this can be a source of very annoying errors
  for quite a while.  you'll (eventually) notice that the kinds of errors
  you don't make more than make up for the annoying errors, but it doesn't
  feel like it very early on.  C++ compilers make it easy to get simple
  things right, but extraordinarily hard to get complex things right.  I
  don't think people would fail to get simple things right unless they had
  a tool that effectively invited them not to care about them, and too much
  static type checking and the like does just that.

| 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?

  well, you'll find that you write verbose code, but not lousy code.  if
  you're used to Scheme, you might write Schemish code, which I think is
  lousy in Common Lisp mainly because run-time type dispatch is so strongly
  discouraged by the language specification and by the excessive focus on
  separately-named operators on only one type at a time.  with ML under
  your belt, you might be more inclined to get CLOS right in that you can
  think of the various methods as invoked for statically selected objects,
  although they are not actually statically selected.

| What sort of time scale should we be aware of?

  it appears to take longer to really grasp a new language the more code
  people write per unit of time.  that is, if your primary focus is to get
  something done, you'll bring all your experience to the task and press
  onward, and you won't notice the subtle warning and stop signs.  the more
  you are free to observe and reflect, the shorter time it takes to learn
  most anything.  in the end, you get more done if you don't go too fast,
  which is like outrunning your mental abilities on the keyboard.  of
  course, you want to go as fast as you can, but that's usually a lot
  slower in the beginning than you feel comfortable with if you have a lot
  of experience getting things done in another language.

  I think the best solution is to have somebody who knows Common Lisp way
  better than you look at your code and ask you what you _really_ want to
  accomplish with it, as that can be fairly well covered in syntax and the
  kinds of obscure machinery that C++ is virtually made of.

| When will we hit that point?

  it depends on how much you value introspection, and how much "there MUST
  be a better way than this"-signals from your aestheticles¹ will interfere
  with your coding.  since you have "fairly substantial" exposure to C++,
  they can't be all that well developed (sorry), but I have seen people go
  from dabblers in Common Lisp to _enjoying_ the HyperSpec in three months.

¹ the little-known source of aesthetic reactions.  if your whole body feels
  like going into a fetal position or otherwise double over from the pain
  of experiencing something exceptionally ugly and inelegant, such as C++,
  it's because your aestheticles got creamed.