I've entered negotiations for a XL1200. So I was wondering about the correct market value. I did some research on Google and found that Michael Parker put his XL1200 up for sale too. That's one fine machine! The price seems about right.

Gospers homepage can be found here. Besides his extensive mathematical work, I can recommend the interview with him in the book More Mathematical People. Contemporary Conversations published by Academic Press. Gosper is a legendary Lisp hacker and mathematician. He discovered the first glider-gun in Conway's Game of Life. He is a master of continued fractions, one of the authors of HAKMEM and master puzzler.

Mario S. Mommer wrote in comp.lang.lisp:

I wrote a small framework for tracking foreign objects and using garbage collection. It is used in the lgtk lib, which you can find here: www.common-lisp.net/project/lgtk
Grep for capsules and nexus. It should be easy to reuse, since the idea was precisely to have a reusable framework.
There is no documentation on these matters yet. I'm working on it, but time is a scarce resource.

The main concern in the thread was: How to manage space allocated to data imported through foreign function calls.

Bill Clementson wrote a series of very good and instructive articles [1] [2] [3] about dynamically changing running Lisp code. In most other programming languages this would be considered high wizardry. In Lisp it just comes prepackaged like sliced bread. Ahh, the luxury!

Chad Fowler linked to an interview with Guy Steele.

Q: Tell us about your first encounter with Java technology.

Answer: Well, this part is embarrassing. When I first joined Sun Labs in 1994, I surveyed the existing projects to see what was going on. One of the projects involved a variant of C they called "Oak," and it seemed to be focused on a narrow application area, set-top cable boxes. "Interesting, I guess, but not earth-shaking," I said to myself as I tossed the overview on my pile of project documents. "Next!"

Little did I know. A year later, Bill Joy called me up and said, "Its new name is 'Java,' and we think it's going to be a big deal. Help me write the language specification!" And it did turn out to be a big deal.

This reminds me of an earlier incident when Larry Smarr, who directs the National Computational Science Alliance, first told me, over lunch, about an amazing new technology called the "World Wide Web" and interactive file browsers. I was skeptical then, too, but a year later I told him, "I was wrong, you were right!"

His paper Growing a Language was published in the Journal of Higher-Order and Symbolic Computation, vol. 12, pp. 221--236, Oct. 1999.

The server hosting lispmeister.com was unreachable for twelve hours. My security conscious provider decided to block the IP address of my server, because multicasting was enabled in the kernel. Access to lispmeister.com might be sporadic in the coming hours until this issue is resolved.
[Update]I upgraded the kernel. Everything should be fine now. The good news is: Automatic backups to a remote repository are finally working.

Bill Clementson wrote a HOWTO that explains how to profit from software development in Lisp.

I've been a VESTA fan for quite some time now. Ken Schalk presented VESTA at CodeCon 2004. VESTA is a configuration management system. Unlike CVS, which only gives you revision control, VESTA adds configuration and build management. It was used by the Digital Alpha microprocessor group to manage all design related files. VESTA also supports replication of source repositories. Here's a couple of citations from his presentation:

• Immutable, immortal, versioned storage of all sources and tools
• Precisely repeatable builds
• Incremental builds
• Parallel development
• Consistent builds
• Automatic dependency detection
• Automatic derived file management
• Site-wide caching of all build work

Subversion reached version 1.0 a couple of days ago. It certainly is an improvement over CVS, but I think Subversion is to little to late, unless your projects tend to be smaller than 10k lines. In a production environment repeatable builds are worth killing for. Shlomi Fish created a good comparison of SCM systems which inlcludes VESTA.

The cover for SL is nearing completion. After some minor changes we will be done. I've also created previews of TOC and index.

Andy Hertzfeld wrote an entertaining article about the discovery of Hungarian notation at Apple in 1982. Nowadays Charles Simonyi is busy selling Intentional Programming. He's come a long way.

I have just created a new community for Etudes at Orkut.

Etudes is probably the best introduction to programming ever. Written by Charles C. Wetherell while at Livermore Labs, it attracted just the right kind of hacker personalities. People who were initiated and inspired by Etudes tend to be exceptionally good programmers.

I hope to inspire lively discussion. C. Wetherell, the author is still considering a second edition. Currently Etudes sells for above $90 for a run down copy. The last auction at Ebay toped out at $270 for a mint edition.

C. Wetherell implemented Kriegspiel in FORTRAN 66 while at Lawrence Livermore Lab. There's an interview with him and Tom Buckholtz at nersc.gov.

CW: This is probably the appropriate time to define the essential features of the game Kriegspiel.

TJB: You are right. We have discussed some aspects so far. You, Charles, did a wonderful job on this when you wrote the papers. That explanation is doubtless more concise that what I say here.

A Kriegspiel game features two people playing chess against each other. All the rules of chess (with the exception of conventions about forced draws) apply, but each player has his own board and cannot see the opponent's position on the other board.

Indeed, a player can place chessmen of the opponent's color, coins, or other objects on the board to indicate the player's guesses about the opponent's position. Such memory aids are not part of the official game.

With our Kriegspiel monitor, a player was allowed to put any number of opponent's pieces of any type on his own board, subject to two limitations. One could not put an opponent's man on a square occupied by one's own chessman. One could not put more than one opponent's piece on any one square. Also, I should note that we did not provide an analog of "coins."

As I had seen the game played, only two boards were used, with the White pieces being official on one board and the Black pieces on the other. Usually, the players sat facing each other with their boards between them and an adequately tall, wide, and opaque "divider" standing between the two boards [37]. The referee positioned himself at one end of the divider and mentally superimposed the official positions of the two players. (I recall rumors that some referees used third boards, maintaining the actual chess positions thereon as aids to themselves.)

I was proficient at refereeing two games simultaneously. This required four chess boards and one long divider. I stood at one end of the divider. The two players nearest me faced and played against each other. The other two players faced and played against each other. My main challenge was to maintain a normal degree of referee-generated "banter" and convey the required information without slowing down either the "near board" or "far board" game. Accuracy in refereeing did not prove a challenge.

Because all the rules of chess (except conventions about forced draws) apply, the two opponents know each others starting positions. Such "complete knowledge" usually dissipates starting with the first or second pair of moves.

Browsing Lambda the Ultimate I came across a reference of Henry Baker's paper The Thermodynamics of Garbage Collection which is available at his archive. Too bad his papers never got published in a Collected Works edition.

Via Emery Berger in gmane.comp.lang.lightweight comes a recommendation for this research page by Umut A. Acar. Some of tasty papers there:

• Selective Memoization
• Adaptive Memoization
• Stability, Adaptivity, and Dynamic Algorithms

Scott McKay, one of the original authors of the paper The Symbolics Virtual Lisp Machine , answered a question posed by Edi Weitz on comp.lang.lisp:

From: "Scott McKay" 
Newsgroups: comp.lang.lisp
Subject: Re: Looking for full Open Genera paper (Withington, McKay, et. al.)
Message-ID: 
NNTP-Posting-Date: Tue, 17 Feb 2004 01:08:30 GMT
Organization: Comcast Online

"Edi Weitz"  wrote in message
news:m3n07jstbv.fsf@bird.agharta.de...
> I know about the article "The Symbolics Virtual Lisp Machine" by
> P.T.Withington, Scott McKay, Gary Palter, and Paul Robertson which can
> be found at
>
>   .
>
> However, this is only an "extended abstract" which at various points
> makes references to "the full paper." It is noted that the paper was
> submitted to PLDI '94 but it doesn't seem to be part of the PLDI '94
> proceedings.
>
> Can anyone help me in locating the full paper?
>
> Thanks,
> Edi.

Tucker reminded me that we never actually completed the
paper because the conference committee didn't accept the
abstract.  This is really too bad because, with all due humility,
the VLM was actually wickedly cool, had some really neat
implementation tricks, and just worked way better than it
had any right to.  Despite the fact that it was too little, too
late for Symbolics, it was actually one of the most-fun things
I had the good fortune to work on.

I certainly agree that the mismatch between memory and
CPU performance supports the conclusion of the paper --
tagged memory and micro-programming would probably
be beneficial in a big way.  (Of course, given how many
stupid buffer overrun viruses there are these days, it's
hard to believe that anybody can still think that not having
manifestly-typed data is defensible.)

Leo Pos pointed out an article by ESR where he analyzes the management of closed source vs. open source projects and (not surprisingly) concludes:

Our reply, then, to the traditional software development manager, is simple -- if the open-source community has really underestimated the value of conventional management, why do so many of you display contempt for your own process?

Once again the example of the open-source community sharpens this question considerably -- because we have fun doing what we do. Our creative play has been racking up technical, market-share, and mind-share successes at an astounding rate. We're proving not only that we can do better software, but that joy is an asset.

Two and a half years after the first version of this essay, the most radical thought I can offer to close with is no longer a vision of an open-source-dominated software world; that, after all, looks plausible to a lot of sober people in suits these days.

Rather, I want to suggest what may be a wider lesson about software, (and probably about every kind of creative or professional work). Human beings generally take pleasure in a task when it falls in a sort of optimal-challenge zone; not so easy as to be boring, not too hard to achieve. A happy programmer is one who is neither underutilized nor weighed down with ill-formulated goals and stressful process friction. Enjoyment predicts efficiency.

Relating to your own work process with fear and loathing (even in the displaced, ironic way suggested by hanging up Dilbert cartoons) should therefore be regarded in itself as a sign that the process has failed. Joy, humor, and playfulness are indeed assets; it was not mainly for the alliteration that I wrote of "happy hordes" above, and it is no mere joke that the Linux mascot is a cuddly, neotenous penguin.

It may well turn out that one of the most important effects of open source's success will be to teach us that play is the most economically efficient mode of creative work.

There's some essential truth in his last sentence. Don't get me wrong. I've been there and failed (web archive link). IPmeter was Open-Source, dual licensed and came ready-to-run in a 1U box. We burned some 10m Euro until we realized, that bandwith was "to cheap to meter". Bummer.

How can we have fun coding and pay our bills at the same time? I'm still trying to find the answer.

Via boingboing comes this exciting news about fighting robots:

While in Japan, I saw the coolest thing ever! Fighting robots. But not in the traditional Battlebots sense. Imagine rock-em sock-em robots, only fully articulated and computer controlled. It's called Robo-One and it's amazing. 15" tall androids belt each other boxing style until one falls down. These mini androids are as articulate as the Sony Curio, Honda ASIMO, or Fujitsu HOAP - only guys are making them in their apartments for about $3000, rather than 10 Million. I've uploaded a bunch of videos to give you an idea. Robolympics is sponsoring a Robo-One match in San Francisco in March - along with Battlebots, sumo bots, and others. Watch these videos!
--David Calkins

My wife threw a Cuban themed birthday party. I tended the bar together with my best friend Peter and we served Mojitos, Caiprinhas and Screwdrivers. Cuban Jazz and bar music filled the air, we drank, danced and schmoozed. Then my special friend Elmar suggested it was time for the Big cigar.

There's a little story about the Big cigar: When the two of us where deep into a venture capital funded high risk startup some five years ago, we had to deal with a six foot six tall, cigar chain smoking VC. Meetings tended to be long and low on content as well as oxygen. Elmar wanted to make sure we would get some payback for suffering throug this and had some gigantic cigars handmade. We envisioned a final meeting where we would light them up and enjoy the surprise. Alas, the project tanked, the meeting never happened.

But when it's time, it's time. So we went down into the humidor in the cellar, retrieved the two remaining Big cigars and where surprised to find them fresh and in good shape after almost five years. I must say this was one fine cigar!

Via slashdot comes this interview with Sun's Victoria Livschitz:

The correlation of the size of the software with its quality is overwhelming and very suggestive. I think his observations raise numerous questions: Why are big programs so buggy? And not just buggy, but buggy to a point beyond salvation. Is there an inherent complexity factor that makes bugs grow exponentially, in number, severity, and in how difficult they are to diagnose? If so, how do we define complexity and deal with it?

The preventive measures attempt to ensure that bugs are not possible in the first place. A lot of progress has been made in the last twenty years along these lines. Such programming practices as strong typing that allows compile-time assignment safety checking, garbage collectors that automatically manage memory, and exception mechanisms that trap and propagate errors in traceable and recoverable matter do make programming safer. The Java language, of course, personifies the modern general-purpose programming language with first-class systemic safety qualities. It's a huge improvement over its predecessor, C++. Much can also be said about the visual development tools that simplify and automate more mundane and error-prone aspects of programming.

I feel like jumping up and down and shout: "Lisp, just use Lisp!". Of course she would't know better. She probably never saw a Lisp Machine, let alone experienced one. It makes me sad/mad just reading it. It's almost as bad as this terrible book by Marilyn vos Savant (the woman with the worlds highest MENSA certified IQ) about Andrew Wile's proof of Fermat's Last Theorem.

Daniel Barlow mentioned a funny article about J2EE on #lisp.

Also from RubyConf, one more answer to where we went wrong with J2EE, and Java in general. Matz -- the inventor of Ruby -- titled his keynote address How Ruby Sucks. Java folk have always taken the language too seriously. It's too late now -- it would incite an irrational panic among Java developers -- but we might be in a much better place today if, about five or six years ago, James Gosling had been able to deliver a talk about Java in that same spirit.

J2EE applications tend to grow like cancer until all ressources of the host have been consumed. At my day job we've written over one million lines of Java implementing a simple internet marketplace. We do use a code generator to do most of the grunt work, but only because we cannot create the necessary abstractions within J2EE. Using a code generator is like enumerating all the parts and assembly instructions for a house instead of just writing "home". Java has no meta.

---

Dan Weinreb (who wrote the original Lisp Machine Manual, co-designed Common Lisp and co-founded Object Design Inc.) asked me via email to clarify my J2EE rant and "what it would mean for a language to have meta. I will write about this in more detail soon, but here's the gist:

No macros. The reason we use code generators is, that we do data modeling
using UML. We also model business workflows in UML including constraints
on vertices that realize state changes. Ideally we would like to do that
at runtime including the necessary migration of changed data structures
and business objects. Java provides only very limited facilities for
reasoning about itself. To do on the fly code migration/ data migration,
even with an externalized model is very hard. So we settled for a
process that does the following:
1. Collect user stories.
2. Change data structures and workflows according to customer requirements.
3. Export model
4. Import model into code generator
5. Generate code (that's about 80% of the application) including
   migration code for instances that use the old data model
6. Compile.
7. Run and migrate all data to new model.
8. Test.
9. Generate code again loosing migration code.
10. Run, test
11. Deploy.

Dan suggested I should consider building an interpreter and that I should really talk about schema evolution instead of code migration/data migration. He also pointed me to David Bau's blog for further reading on "XML Beans", because I mentioned that we do our own data serialization.

Via Hrvoje Blazevic in comp.lang.lisp comes the news that Richard P. Gabriel made a PDF version of his book available online. He writes:

This is my first book, published in 1985. It's on what determines the performance of a Lisp implementation and how to measure it. It is the source of the so-called "Gabriel Benchmarks," which are still in use to benchmark Unix systems.

Because it's out of print, I've made the pdf of it available under this Creative Commons License.

Years ago it took me two months to locate and purchase a used copy and I'm very happy RPG now made this fine book available online.

Kocsis Krisztian has some nice pictures of his disassembled Symbolics XL1200 on his page.

Via saladwithsteve comes this memorable quote:

Carl Sagan: "There is a myth about such highs. The user has an illusion of great insight, but it does not survive scrutiny in the morning. I am convinced that this is an error, and that the devastating insights achieved while high are real insights; the main problem is putting these insights in a form acceptable to the quite different self we are when we're down the next day...If I find in the morning a message from myself the night before informing me that there is a world around us which we barely sense, or that we can become one with the universe, or even that certain politicians are desperately frightened men, I may tend to disbelieve; but when I'm high I know about this disbelief. And so I have a tape in which I exhort myself to take such remarks seriously. I say 'Listen closely, you son-of-a-bitch of the morning! This stuff is real!'"

-from the footnotes of "Botany of Desire", originally quoted anonymously in "Marihuana Reconsidered"

This is exactly how I feel about my night phase code after changing phase. Night phase code tends to be terse, sometimes obscure. To quote Hagbard Celine a.k.a R.A.Wilson:

Coding distorts perception.

While working on the print edition of Successful Lisp I found the following ressources helpful:

• Tutorial on Good Lisp Programming Style by Peter Norvig
• Lisp: Style and Design by Molly M. Miller and Eric Benson
• BUGS in Writing: A Guide to Debugging Your Prose (2nd Edition) by Lyn Dupre

Our text block width is only four inches, which sometimes resulted in peculiar formatting compromises for longer code examples.

Because I'm very lazy guy, automation always appeals to me. Many times it's the little tools that make all the difference. Chew Wei Yih created websec to automate checking web pages for changes in content. It scans an URI list, downloads the pages, diffs the changes and sends you email, if the page changed since the last run of websec. I run it from crontab once a day to check for changes on my watch list of web sites.

I couldn't find version 1.4 online, when I recommended it recently, so I put it up for download here.

Christophe Rhodes announced the availability of his paper about maintenance of Common Lisp programs available. (via #lisp)

Via abusabletech.org comes this NY-Times article telling the story of the CIA trojan horse software that created a 3 kilotonn explosion. If this turns out to be true, I wonder what they are up to nowadays?

Via lemonodor comes an article by Brian Marick about the Master of Fine Arts in Software trial. Fascinating stuff.

In many ways Software resembles literature. Considering this, Stephen King's book On Writing might as well be about software development. King describes how the charactes in his books seem to have their own agenda, their own mind. To programmers who've been maintaining big software systems this sounds quite familiar.

In a comp.lang.lisp posting Tayssir John Gabbour pointed to an interesting article by Jonathan Rees about object oriented languages in general and Lisp. Here's a quote:

This is related to Lisp being oriented to the solitary hacker and discipline-imposing languages being oriented to social packs, another point you mention. In a pack you want to restrict everyone else's freedom as much as possible to reduce their ability to interfere with and take advantage of you, and the only way to do that is by either becoming chief (dangerous and unlikely) or by submitting to the same rules that they do. If you submit to rules, you then want the rules to be liberal so that you have a chance of doing most of what you want to do, but not so liberal that others nail you.

Joe Marshall points to a good paper on Mathematical Limits to Software Estimation in the current abysmal (or should I write entertaining?) thread "Lisp's future" in comp.lang.lisp. He also recommends the book The Limits of Software by Robert N. Britcher. He tells the inside story about the development of the FAA's Advanced Automation System (AAS). How IBM made use of all "industry best practices", was on schedule throughout the whole eleven year project, and failed spectacularly one month before completion. Britcher was also part of the team that developed the original (and still running) air traffic control system that was supposed to be replaced by AAS. Highly recommended!

Teemu Kalvas announced his Lisp500 a Lisp in 500 lines of C on the #lisp IRC channel today.

Xah Lee announced an interesting article on algorithmic mathematical art on comp.lang.lisp.

Many thanks to Howard Lovy for pointing me to his interesting article about the kabbalistic concept of "Tikkun Olam" and nanotech.