Subject: Re: O'reilly subjugated to the Lisp juggenaut (well, almost ;-)
From: Erik Naggum <>
Date: 14 Jan 2004 07:33:27 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Damien Kick
| I would also love to see the Lisp equivalent of something like
| _Large-Scale C++ Software Design_; i.e. a book that treats the
| subject of developing large-scale applications with Common Lisp,
| though I would imagine that it is the many idiosyncracies of C++ and
| the relative comprehensiveness of CL that have produced the need for
| the former the lack of the later.

  The most important difference would be that a large-scale Common
  Lisp project would increasingly be written in an application-domain
  language, while a large-scale C++ project would continue to be
  written in C++.

| [...] is there a unique CL angle to this subject or is it really the
| more general design principle of less coupling leads to better
| testability?

  There is a unique Common Lisp angle which I believe only Scheme will
  share with it: Instead of working in the language delivered to you
  by some vendor, you will generally build your own development system
  in possibly multiple stages and then compile the application at some
  point in this multi-stage build process, and it might not even be
  the last step that produces the application as users will see it.

  If you want to do anything remotely similar to this in any other
  environment, regardless of how tightly coupled it is with the core
  language, you will have to resort to a multitude of tools that are
  loosely coupled instead of closely integrated.  Brilliant inventions
  like the m4 macro processor under Unix (enter Gary Larson-mode and
  visualize the /rejected/ m1, m2, and m3) demonstrate what happens to
  large-scale projects like sendmail.  Common Lisp itself grew out of
  several large projects (even by today's standards), and the various
  Lisp machines demonstrated what happened in the Lisp world when they
  needed to grow their own tools.

  Many people complain about the difficulty of integrating Common Lisp
  with other programming languages, but in a large-scale project, you
  will have different people working in different languages to talk to
  the different parts of the real world that it would be even more
  work to include in the Common Lisp world, and they are free to build
  the interface any way they like.  Small-scale projects face tougher
  restrictions in this regard because the same programmers will work
  in the different languages and the kind of scaffolding that you set
  up when building something that cannot support itself until it nears
  completion will appear to consume a lot of resources that some naïve
  people think ought not to be consumed, and so they use Perl or some
  other horrible crock, instead.

  In many important ways, Common Lisp becomes a different language
  when the project becomes large enough, but those who have found
  Common Lisp to be to their liking in small projects will need a bit
  of attitude readjustment to cope with the products of other people's
  small projects in their large project.  Common Lisp works so well on
  a small scale that many people strongly resist the differences in a
  large-scale project, and much of Common Lisp's perception problem is
  that it works too well on a small scale.  It is self-evident to any
  working brain that C++ does not work well on a small scale, so it is
  easy to dupe oneself into believing that it is because it works so
  well on a large scale, but there is no credible evidence that it in
  fact does work on a large scale.  That people /make/ something work
  can never be evidence of anything.  The Lisp world has an incredibly
  strong proof-of-concept advantage in the Lisp machines, which died
  for a lot of reasons unrelated to the scalability of the languages;
  a careful reading of the history will reveal that they died because
  they were /too successful/.  (I have found that the worst possible
  thing you could do wrong in this world is to give people something
  that is more powerful than they are prepared to understand.  Back
  when I believed that SGML was a brilliant idea, I did not understand
  that the people who were the intended users were completely unable
  to understand it, and that only those who were stupid enough not to
  realize it in time, would continue to work with it, and so they sat
  there with their excellent document production system with a clever
  markup system and thought it had to be useful for something grander,
  and now we have XML, a non-solution to a non-problem so brilliant
  that m4 no longer seems like a prank.  We really need Gary Larson-
  style cartoons on the history of computer science.)

  The only other large-scale projects that one should look at when
  trying to see the Common Lisp way, is entire programming systems,
  like the complete Debian GNU/Linux development system.  It is not
  the individual languages or tools or programs that make it up, but
  a general sense of the entire system.  Common Lisp is how such a
  system would be if it were done right.  (Those who think Windows is
  a usable system may of course feel free to believe that it is also
  an instance of a large-scale project, but the distance to how it
  would be if done right may just be too large to visualize.)

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.