Lemonodor is a weblog about Lisp, with posts on programming, s-expression tooling, and Lisp machine history.
HN links it for Lisp history and tooling, such as the TI Explorer Unix coprocessor post, and for the author's comments from Reddit's move to Python.
Very interesting insight into the Explorer development, thanks for posting the link!
Some (possibly) interesting comments:
- "later I think TI made (or tried to make) a plug-in card version of the TI Explorer for Macs" - this was the MicroExplorer NuBus card for Mac II-series machines, which was somewhat popular. Symbolics also built a NuBus Lisp machine board for Macs.
- "This machine had one of the largest CPUs ever made until that time, something like half a million transistors." The original version of the Explorer (Explorer I) implemented the CPU in TTL logic (plus microcode ROMs and PROMs to implement some logic functions) on two large NuBus boards, the integrated version was later used in the Explorer II and MicroExplorer.
- "the entire computer division was sold off to HP soon after I left" - one of the sad stories, HP destroyed a number of companies after they took over. In addition to TI's computer department (the TI990 16 bit machines were sold to some other company), Apollo, Tandem and DEC (via Compaq) suffered a similar fate.
- "Pretty sure the sale included a sweet little Unix box". This was the TI1500, a 680x0-based asymmetric multiprocessor machine running TI System V (SVR3) with some pretty advanced concepts for its time (such as software RAID/striping), which was also based on NuBus. You could add a TI 68020 CPU board to an Explorer and run Unix on the side. I used to service and admin TI1500 machines as a student and am possibly the last person on…
There's this recent video showing a little of what the Pharo Smalltalk environment is like:
https://www.youtube.com/watch?v=HOuZyOKa91o
The video was made by a Ruby programmer, rather than an experience Smalltalker, so it's more a newbie showing you cool things he's discovered, rather than an expert showing the power of the system.
On the other hand, there's this one:
https://www.youtube.com/watch?v=o4-YnLpLgtk
That one is an expert, Kalman Reti, showing some of what it's like to work with a Symbolics Lisp Machine. (It's not a real Lisp machine; they're all at least thirty years old now; this is an emulator running the old Symbolics OS on Linux).
Go to YouTube and search for Rainer Joswig and you'll find a few video demos of Lisp Machines and MCL and so forth.
Finally, here are a few images from about eighteen years ago, also from Rainer. They show various views of the Macintosh Common Lisp and SK8 environments. It's not an experienced user showing you around, but at least you can get some idea what the environments looked like:
http://www.lemonodor.com/archives/000028.html
A comment by Steve Huffman on my blog[1], from back when they switched away to Python:
I didn't say the are *no* shoulders to stand on. There are
just fewer.
Without a doubt, Edi Weitz single-handedly made reddit
possible. He's an army-of-one producing good Lisp
libraries. The issues that made it really hard to stick
with Lisp weren't particularily Lispy.
The biggest trouble that plagued us was that we could never
quite get Lisp reddit stable enough to sleep at night.
There were weird threading issues that would bring the site
to its knees a couple times a day and required constant
monitoring.
Another comment, from Paul Graham:
> One can argue that they betrayed the worth of a
> philosophy merely for cheap money.
Ye gods, enough with the conspiracy theories already. Y
Combinator didn't know Reddit was going to use Lisp when
we funded them. And the reason they switched (or at least,
the last straw) was all too mundane: some thread bug in
CMUCL that made the site keep crashing.
1. http://lemonodor.com/archives/001301.html
I tried to post a comment, but there seems to be a problem with their Lisp CGI's.
On Lisp vs. Python:
http://lemonodor.com/archives/001497.html
"Readable" languages are rather manager-centric. And because software managers become increasingly unimportant (or decreasingly important :), so will "readable" languages.
Of course programmers need readability too, but given a choice they'd rather stick to a concise and powerful language. Why? Probably because a powerful language, among other things, doesn't require you to get back to your code and fix it too often, and hence, you don't need that language to be too readable. It allows you to solve a problem in small, rock-solid and easily testable chunks.
I'm desperately looking for such a powerful "write-and-forget" programming language. Is it Lisp? I don't know yet.
> Jak & Daxter the whole engine was lisp based.
Only when "the whole" is defined to mean "the object scripting."
http://www.psxextreme.com/feature/45.html
"The final game engine has about nine different renderers, each is optimized for its specific task."
http://c2.com/cgi/wiki?LispInJakAndDaxter
"GOOL was used to control objects in the game"
Jak II had apparently the most of GOAL:
http://lemonodor.com/archives/000610.html
"Of the 1.2 million lines of code, roughly 900,000 lines are written in GOAL."
Still that leaves 300,000 lines which were certainly the most low-level and performance-sensitive ones.
The 900,000 lines aren't exactly "the Lisp," but that custom language, developed using the commercial Lisp, but I admit it's certainly an engineering achievement.
pg mentioned that he uses vi with a REPL ( http://news.ycombinator.com/comments?id=587 ).
I recently began using emacs + SLIME for writing Lisp and revert back to vim for everything else. I've also tried vim + VIlisp.vim, which sends Lisp code to a running Lisp interpreter. It seemed pretty decent though I don't really have enough experience writing Lisp to really compare.
Anyone else write Lisp in vi?
SLIME is great, but I really miss vim sometimes. Fortunately, Slim-Vim is in the works by the author of VIlisp.vim. Here's a couple comment pages on Lisp with vi/emacs:
http://programming.reddit.com/info/1cij7/comments
http://www.lemonodor.com/mt/mt-comments.cgi?entry_id=689