Subject: Re: free lisp compilers?
From: Erik Naggum <>
Date: 1999/09/09
Newsgroups: comp.lang.lisp
Message-ID: <>

* Friedrich Dominicus
| If the problems exist very much, why isn't than antther solution choosen?
| As explained above, I do not know about C++  to tell something against or
| pro.  Just one point seems to be clear.  Large projects are done in C++
| and there are a million tools out there and even with tools like the GNU
| Tools developer have written e.g KDE and it worked quite fine.  But there
| isn't any GUI-Toolkit I know of which was written in Common Lisp and is
| in widespread news for open software projects.  And even worse many of
| the GUI-Toolkits for Common Lisp are not supported any longer and look
| quite a bit old.  So why should people which do programming for the fun
| of it choose Common Lisp?  The advantages do not seem so large that they
| would switch from C++, and in fact they prefer to write software with C++.

  using Franz Inc's cbind utility, a fairly new Lisp user (he just got the
  Allegro CL Trial edition for Linux) compiled up gtk bindings and wrote
  some Lisp source that basically did gtk calls from Lisp in a few hours.
  it seems fairly verbose to me, but that was his first approximation.
  fairly impressive, still, and if it doesn't take more than this to get
  access to such toolkits, what's holding us back is probably only that we
  think it's a lot of work.  beginners don't know that, so they just do it.

  why should people who do programming for fun choose Common Lisp?  because
  it's a lot _more_ fun programming in Common Lisp!  I chose to rebuild my
  carreer and switch away from C/C++ when I had to use C++ in a project
  (and like so many other programmers, I had heard mostly good things about
  it at the time (August 1993)), but the language is really, truly
  braindamaged.  I was complemented on my design and coding from the few
  people I got to know who were seasoned C++ programmers at the time, but
  it still took forever to write, there were always unwanted side effects
  of the most seamingly innocuous code and no way to have the compiler or
  system tell you about them, and the redesigns that had to be made as we
  discovered more details of the problem space were so costly the project
  didn't reach its goals even with two more programmers on it and almost
  twice the time, but we did publish a small useful core and a lot of
  useful design papers.  this experience had "there has to be a better way"
  virtually flashing over us all the time, and I decided to take a good
  serious look at Common Lisp, which I had been using for fun off and on
  for longer than I har programmed in C.  it took me three years of other
  useful work (I wrote articles for various newspapers and journals, and
  covered various IT-related news events, and also began writing a book
  about SGML, which led me to conclude that that language was braindamaged,
  too, so I stopped working on SGML) before I could go out there and say
  "I'm a Lisp programmer" and expect to be paid for it.  since it was clear
  to me that I could sustain myself as a writer, and I had no plans to
  return to hell and write C++ code ever again, the risks were pretty low
  and I could invest my time in Common Lisp, which I really _like_.  this
  would not have been possible in a _less_ fun language.  (now, three years
  may seem like a long time, but I want to be really good at whatever I do,
  and good articles and columns don't exactly come for free, either.)

| I just can say, it seems not to matter.  And I can say the same for
| Eiffel.  But relatively few are using Common Lisp and Eiffel instead of
| C++.  So the problem seems not to big for them.

  they don't know how easy it could be.  they expect changes to be so and
  so expensive.  the result is that fewer changes are made than necessary
  for correct operation, broken designs survive into products, and new
  versions are harder to get out the door without massive rewrites.  this
  is how the C++ world works.  since C++ people tend to know C++ only,
  which is actually good for them when you think about it, they don't see
  it as a problem.  many other disciplines talk about "baselines" and the
  work required to establish them, and it is fair to say that the baseline
  for correcting errors in C++ is much, much higher than that for Common
  Lisp, but those who have internalized the C++ baseline won't believe the
  Common Lisp figures.  I think we have some evidence of that right here.

| I found no comparable book to ANSI C from K&R with solution books.  And
| another book I asked for, was out of print for MIT-Press.  So it's not
| damn easy to find stuff for Common Lisp.  BTW the handbooks whic come
| with Allegro CL und LispWorks are quite good and useful.  And the
| Hyperspec is really a good organized reference.  But this are IMO quite
| advanced docs.  And not very suitable for a beginner or even worse a
| complete beginner to programming.

  a complete beginner to programming would probably have a hard time
  getting a job if all he knew was Common Lisp.  those who employ Common
  Lisp people tend to expect good knowledge of several languages.  it may
  therefore be a disservice to a future programmer to teach him the best
  language first...  several of the good Common Lisp programmers I know who
  have been taught Scheme and Common Lisp have asked me time and again to
  show them more low-level stuff.  new Common Lisp users seem to find the
  low-level access "panels" intriguing and opening them to see what's
  inside is entertaining and adds a feeling of being in control.  then we
  put the panels back on and we don't have to _work_ at that level.

  it's election time in Norway.  explains everything, doesn't it?