Subject: Re: "Well, I want to switch over to replace EMACS LISP with Guile."
From: Erik Naggum <>
Date: 29 Sep 2002 17:04:58 +0000
Newsgroups: comp.lang.lisp
Message-ID: <>

* Tim Bradshaw
| A related point, it seems to me, is that reinvention is more-or-less
| inevitable if the existing art is so bad that coping with it is too hard.

  This can be a good reason for re-invention, but then the smart re-inventor
  knows the past and what he needs to be better than.  If re-invention only
  means that one treads the same old path all over again, it is very bad.  And
  of course knowing the past is going to be hard.  That is why psychologists
  have to study so many completely bogus psychological theories -- left to
  their own devices, past psychologists have invented all these wacky ideas,
  and future psychological inventors please take note: they were discarded.

| So one escape from the wheel of reinvention is to try and come up with
| systems that are well designed in the first place.

  The force of genious lies behind a significant shift in perspective more
  than in new ways to perform old tasks.  We humans are pretty annoyingly
  limited when it comes to getting stuck in a well-known pattern and those who
  are not, tend to be more wacky than genius.

| 1. Anyone who's read my previous article(s?) in this thread knows I
|    think redoing emacs in scheme *or CL*[1] is insane.

  I once started down that path, but having spent a couple hundred hours on a
  Common Lisp-based Emacs, decided that it was going to take a couple thousand
  hours before I had a system I would use myself and would be able to attract
  others to join in building.  I still wonder what would have happened had I
  not gotten fed up, but the better system would also be harder to maintain
  than to build.  Emacs moves on, and if I were to build another Emacs, would
  have to duplicate a /lot/ of effort.  It would, in brief, be what I would do
  for the next few years.

| 2. Anyone who has read the drivel I write for a bit longer knows my feelings
|    about XML.  Every time I have to do something for which XML might seem
|    suitable, I just invent something else, largely so that I don't have to
|    cope with the ideas behind XML - other people's ideas.

  What can I say?  I wasted 6 years of my life on SGML and related technologies
  only to find that when I wanted to translate my experience and knowledge and
  significant grasp of this technology into a book that would teach what I had
  found to others, I had to look real hard at all the braindamaged things that
  I had been willing to sweep under the carpet and found, to my horror, that
  SGML, once understood, could not possibly be worse implemented than SGML
  itself -- if you get the very valuable core ideas behind SGML, SGML was self-
  defeating because it had to cater to a huge number of idiotic requests and
  requirements that took away from its ability to express what it wanted to
  express, and it became such a horribly application-dependent language that
  you would have to retarded to write anything worse.  I could not publish this
  in a book that would be a conceptual introduction to SGML and abandoned the
  whole language and my investment in time.  Once every two weeks or so, I get
  mail from somebody else who have discovered the same thing after actually
  having tried to use SGML for something other than a stupid markup language.

|   XML and its encrustations seem to me to be classic examples of the existing
|   art being just too bad to deal with.

  I takes considerable time to understand this, however.  If you do /not/ grasp
  the core ideas behind SGML and XML, you will probabl invent something worse,
  such as an ad-hoc binary format, and since most people would rather die than
  think (in fact they do), XML is better than what a braindead ignorant fool
  would invent from scratch.

| So I think that in order to avoid endless reinvention it's *critical* to use
| systems which are good enough[2] in the first place.  There are rather few of
| those around in IT, because they are *very* hard to produce.  The C/Unix pair
| is possibly one (but I think probably not), Emacs/elisp is, I think, one.
| Common Lisp is the only system that I am pretty sure is one.

  I think Common Lisp is the only fundamental IT system that is better than
  just Good Enough.  I am, however, dismayed at what every single vendor does
  with the language when it comes to presenting Common Lisp to "modern" stock
  computers.  For instance, the lack of the full range of hardware integers
  really, really bugs me.  I got a suggestion in the mail to look at the 8 new
  xmm<n> (128-bit) and mm<n> (64-bit) registers in the IA32 platform, and found
  that after spending a lot of time on programming specifically for these,
  there is absolutely no reason to stick to 32-bit integers on IA32.  The too
  few legacy registers should be used for interaction with memory, and the mmx
  registers should be used for integer arithmetic.  Not doing this is not using
  the Intel platform for what it's worth.  However, this is not done in any of
  the Common Lisps available for the Intel platform, although it would give the
  compiler writer 8 64-bit integer registers and 8 128-bit numeric registers
  that could both be split into smaller registers if need be, and this would
  solve so many of the register starvation issues on that platform.  This is
  the kind of thing that bugs the hell out of me.  Then there is the Unix
  integration, which is abysmal and forces people to use other languages to do
  anything resembling systems programming.  Dsspite all I know about Unix and
  Common Lisp, I do not feel that I write Common Lisp programs /under/ Unix.
  It is as if the Common Lisp programs run on a separate machine somewhere.
  And given that "feel", why not exploit the work in virtual machines and JIT
  compilers and related efforts in the Java and even the .NET community and let
  Common Lisp code become interchangeable and portable between all the
  implementations so that there could be a component market and you could
  actually develop on one platform and deploy on any number of others.  These
  are the developments in a significant part of the software market these days,
  and it bugs the hell out of me that I have to choose whether to continue to
  use Common Lisp if I want to be a part of this.  The effort to make a JVM run
  inside Common Lisp, for instance, is a really good idea.  Now we need a CLVM
  that actually supports CLOS.  Notice that these are not "user land" things,
  they require vendor support and just as much "develop a new system to use the
  new ideas" as any other revolution, but at least the programming language
  does not need to change, and we should be able to leverage off of all the
  existing Common Lisp skills, the standard behind it, textbooks, courses, and
  the long experience with the language to get things right.  However, it takes
  people who actually /like/ Common Lisp to do this and who are professional
  enough to set aside their personal issues when implementing the standard
  faithfully so others can trust that the specification will be sufficient and
  they can concentrate on their application and not have to waste time on
  subtle incompatibilities.  This would be slightly more interesting than a
  Common Lisp Emacs, but I actually think a Common Lisp Emacs would be so much
  easier to build once such a system was in place.

Erik Naggum, Oslo, Norway                 Today, the sum total of the money I
                                          would retain from the offers in the
more than 7500 Nigerian 419 scam letters received in the past 33 months would
have exceeded USD 100,000,000,000.  You can stop sending me more offers, now.