Subject: Re: How to get a wider audience for CL
From: Erik Naggum <>
Date: 29 Aug 2002 13:39:08 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Pascal Costanza
| Now here are some of my thoughts about what could help or, in my opinion,
| what is in fact needed to have CL reach a wider audience again.

  More important than just a wider audience is where you will go to find the
  wider audience.  In other words, who to attract and whence.

| However, there are some drawbacks.

  I think people who cannot read specifications need to learn to read
  specifications -- and not just language specifications.  Some think this an
  arrogant and elitist position, but Common Lisp /has/ a specification and you
  are expected to write to the specification, not only to the implementation.
  So you do not try something you dream up and see if it works, you employ
  yourself to understand what the language allows and then let your creativity
  roam free when it has a sound foundation.  Really nasty things happen to
  people who randomly try something they envisioned in a pipe dream and wonder
  what it means without any ability to predict the machine's response.  Trial-
  and-error mode is actually unsuitable for all languages, but some languages
  have no specification and you /have to/ test things you dream up from
  insufficient understanding and see if it "works" and even what it does.  I
  think it behooves a novice to Common Lisp to shed such notions of the only
  proper approach to learn a programming language.  Trial and error is based
  on intuition, but you need to build that intuition first.  Using intuition
  from one language to be creative in another does not work very well.
  Perhaps, however, the reason you still appear to be look at Common Lisp from
  the outside.

| The ANSI specs doesn't provide rationales so you can't understand the
| specifications if you haven't got an idea about the topics upfront.

  I spent a fair amount of time with Ada 83 and the development towards Ada
  95.  The annotated standard has an excellent rationale liberally sprinkled
  throughout the entire document, and it is indeed very valuable.  Back when C
  was ANSI X3.159, it came with the rationale as a sort of add-on document.
  However. the committee decisions for Common Lisp actually form a rationale
  relative to the base document, which is CLtL1, the Silver Book.

| Furthermore, the deprecated sections are highly confusing: first of
| all, a newbie (me, at least) doesn't care at all wheter someone from a XJYIZ
| committee voted for this and that (I am intentionally exaggerating here);
| this is (probably still) interesting for historical reasons but not when you
| actually want to learn the language.

  I think you should read more of these decisions before you dis them all.

| (We could use "CLtL3" as a working title for such a refactoring?)

  But who would ensure that this new document agrees with the standard?

| This already would mean a lot of work but would pay off in the long run for
| the CL community.

  I actually doubt that.  So do all the others who have not started writing it.

| What do you think?

  I think the HyperSpec is an amazingly high-quality document that it pays off
  handsomely to learn to read and navigate and that it would /not/ pay off to
  write another complete document.  However, it would pay off to link from the
  HyperSpec pages to "commentary" pages.  This could be a useful thing to do
  with cliki.

| P.S.: Perhaps you need this background information: usually, I don't read
| tutorials or introductions to languages on a tutorial level. I highly prefer
| to learn languages from their specifications.

  Could it be that you lack the background to be able to read this particular
  specification and that you would benefit from getting the conceptual models
  right rather than read a tutorial?  From reading your article, I trust that
  you are quite capable of internalizing the fundamental concepts, but you
  should consider the possibility that you started writing your article too
  soon and that the thinking that would normally pulsate with the energy of
  change have coagulated during the writing process that exposed them to your
  conscious verbalization of these ideas.  (I frequently find myself writing
  both code and prose mainly to clarify my thinking on a subject, but there is
  a level of commitment to that which has been expressed involved in publishing
  or sharing that makes it surprisingly hard to revise in fundamental ways.
  Annoyingly common psychology that is hard to beat.)

  I do not think we gain anything if we attract people who do not know how to
  program or how to read a specification -- the cost of entertaining them
  could well be very more on the community than any benefits.  Those who
  desire to write tutorials should get paid for this by people who want to buy
  the books or take the courses.  Something on the level of How to Design
  Programs for Common Lisp would be great (ignoring cost/benefit analyses),
  but this has to be done in an existing educational setting.  This quality
  level is immensely expensive to attain.

  I have written scattered sections of what could become a book under favorable
  conditions.  I have aimed to lead people from the Unix and C environment into
  the Unix and Common Lisp environment, using Emacs.  I am a firm non-believer
  in the Windows experience for a large number of reasons, many political, but
  Unix and Linux have some problems when it comes to Unicode support and the
  entertainment industry.  I believe people are more productive using Common
  Lisp than C++ with the visually oriented programming environments for the
  simple reason that you live within the evolving Common Lisp world, but more
  work needs to be done on collaborative efforts, versioning not just of source
  code but of loaded executable code, and some sort of Common Lisp server that
  works like a database engine where an individual programmer has his own work
  space that he commits to the system, much like CVS does today, but within
  the Emacs/Common Lisp server world.  I have also been dabbling in a Common
  Lisp Emacs (clemacs) that would integrate all of these facets, but there are
  features in Common Lisp that need to evolve and features in implementations
  that are required to support this mode of work.

  Many of the ideas that form the foundation for Common Lisp and Unix are
  actually very similar and should have been able to work tightly and well
  together.  That they do not is perhaps one of the major failures of the
  Common Lisp community.

Erik Naggum, Oslo, Norway

Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.