Within a few years, though, desktop machines running optimized Lisp compilers were surpassing the raw performance of the Lisp Machines, though of course there was nothing like the whole system (Genera).
In the end, "worse is better", plus "AI winter" happened, which put the Symbolics/LMI/TI LispMs out of business.
But something real was lost--I don't think the world has ever seen a more powerful development environment.
One step forward, and four steps back...
The competitor LMI was also developing their next-generation Lisp machine RISC processor: https://en.wikipedia.org/wiki/Lisp_Machines#GigaMos_Systems
More about the latter: http://fare.tunes.org/tmp/emergent/kmachine.htm
LMI manufactured prototypes of their CPU, but these were older technology - not microprocessors, but VME-board sized CPUs.
Xerox mantioned that they were developing a Lisp RISC, but it never surfaced. The SPUR project designed a Lisp RISC Chip: ftp://ftp.cs.wisc.edu/markhill/Papers/jsscc89_vlsi_spur.pdf
IOW, the architectural benefit for Lisp machine weren't enough to overcome the benefit offered by Moores law. Today, things look different but it would be a much harder sell to push Lisp or any non-C launguage.
Can someone here speak to the notion of a lisp machine in the future? Is there any chance this could happen? Would it be valuable? Does anybody else here have this same dream/fantasy/whatever-you-want-to-call-it?
(edited slightly for wording and clarity)
And at that time I hardly knew Lisp! What excited me was the user experience of the Listener, the notion of programming being a way to use the computer, not just to construct software - and the way each piece of software in the system was practically an API for my own use. This was sci-fi stuff to me, extremely inspiring.
I don't know how we could move towards the creation of modern Lisp machines. Disappointingly for this old Amiga user, we don't really have regular computers that aren't ugly old x86 any more. But I think about trying to work these ideas into my software development all the time. Genera had such an impact on me I can't avoid it.
Also i feel that to a more limited sense this is what draws people to the unix CLI. And in turn what sold OSX to academia beyond media production courses. And something that both Apple and Linux userland programmers ignore at their peril.
I've never used a Lisp machine, but based on your description, it sounds like the experience of using them might have been somewhat like using the Oberon system created by Niklaus Wirth- or the other way around (based on a BYTE magazine article  about Oberon that I read, IIRC - never used Oberon either).
 I thought so because this part of your comment:
>the way each piece of software in the system was practically an API for my own use
matched somewhat with something I read in that BYTE article, which was something to the effect that once you had written a subroutine in Oberon, it could be called from anywhere in the OS. IOW, in a sense, the whole OS was like a single program, that you could program. Cool concept.
Though the Oberon system might have been much less evolved, or whatever - as I said, used neither, just interested in the thing.
P.S. From the Wikipedia article about Wirth:
[ Wirth has reportedly told the joke that, because Europeans pronounce his name properly, while Americans pronounce it as "nickel's worth", he is called by name in Europe and called by value in America. ]
Oberon was inspired by Mesa/Cedar, there are quite a few Xerox papers about how Mesa/Cedar used to work. This is probably the most relevant one.
Think about a Lisp/Smalltalk environment, but based on a strong typed language instead.
Regarding Oberon, it had similar ideas.
Basically there were no programs, only modules (strong typed dynamic libraries).
Any procedure/function that had a special type signature could be called from the CLI environment, UI action, or after selecting an UI element, depending on the way the mouse buttons were used.
Also the environment was focused on graphics not plain text.
The last version before Active Oberon was introduced, System 3 with Gadgets, had quite nice Amiga style GUI.
You can find tons of screenshots on my site.
Pretty cool. Thanks for mentioning it.
>You can find tons of screenshots on my site.
I googled for your HN username + " site"; is it this one:
Earlier Wirth designed a personal workstation called Lilith with a stack-architecture CPU and Modula-2 as its system programming language. This was in many ways similar to Smalltalk or Lisp Machines, but with reduced complexity.
Edit: Looked it up - the JVM does seem to:
A Raspberry Pi is "regular computer" enough for me, at least as a hack platform. Ditto all the other ARM SBCs which are largely similar. (Odroid is fairly nice, too.)
The special microcoded systems are dead, but ARM is a nice enough design and it's available from a ton of different sources.
With the GNU Hurd important parts of the OS could be written in Scheme as well.
The problems start with the desktop, where we don't really have anything that's well-integrated and lispy. Sure, there's StumpWM (Common Lisp), and there's Emacs, but they are separate programmes and there's no link between them.
There is McCLIM, a GUI toolkit which looks like a continuation of lisp machine ideas, but as far as I know it does not have an active community (unlike Guix and Guile, whose communities actively work on a Scheme-powered operating system).
But at that point, why bother? Build a games console or a cable TV box with a web browser and call it a day...
An emacs written in Common Lisp, running in StumpWM, running atop a CL Guix, Shepherd & GuixSD would be a thing of beauty.
I agree, however my reasons for going towards Common Lisp vs Scheme wouldn't really be those, but basically that important stuff is already standardized, proven and documented (i.e. conditions&restarts, object oriented system), while on the Scheme world they are left to "roll your own" status.
I'd say Scheme is a great language for learning and exploring, while CL is a better choice for creating production software.
Heh, I find none of these things desirable :) I guess some people are just wired differently. I prefer a single namespace for all values, #F as the only false value, and (optionally) hygienic macros with syntax-case (which does not prevent traditional macros of the defmacro kind).
Maybe I just irrationally don't trust bytecode vm's.
For me, at least, elisp just feels like a primitive Common Lisp while Scheme feels like a completely different language with a similar surface syntax.
But if you see what was missing in elisp: object system, closures, keyword arguments, ... That stuff was also in LML.
I'm reminded of this article (https://fare.livejournal.com/189741.html), where this Common Lisp macro:
(defmacro nest (&rest r) (reduce (lambda (o i) `(,@o ,i)) r :from-end t))
(define-syntax (nest stx)
(syntax-case stx ()
((nest outer ... inner)
(foldr (lambda (o i)
(with-syntax (((outer ...) o)
#'(outer ... inner)))
#'inner (syntax->list #'(outer ...))))))
I'm not going to sit here re-evaluating Scheme, year by year, to see whether it's up to snuff yet.
Someone drop me an e-mail when Scheme gets a well-defined, left-to-right evaluation order, and when its imperative forms all return a stable value like #f or whatever.
((nest x) x)
((nest x ... (y ...) z) (nest x ... (y ... z)))))
Edit: Decided to stress test the chez scheme macro expader. for 30000 expansions, it was under 1s using the syntax-case version. I'd say that is very much good enough.
The smaller standard does not specify a low level macro facility. That doesn't mean that an implementation won't have one. No scheme has syntax-rules only.
I agree that the defmacro is simpler, but nobody said otherwise. The nest macro is more or less perfect for defmacro since it doesn't need hygiene.
If defmacro is so Important, there are several schemes with it out there, and if you really need it it is trivially implemented using low level hygienic macro facilities.
A few years back, I managed to get a Lisp interpreter written in x86 assembly language reading from a floppy and running on the bare metal on an old 32-bit laptop.
I think the leading edge has moved on from Lisp Machines, but as the mainstream took a wrong turning a long time ago, that still has a long way to catch up. For me, the hot topics in system design are capability-based security, dependent types, and live programming.
My "dream" is to have a statically typed Lisp (with type inference) running on commodity hardware (x64), and either compiling to the bare metal (faster) or to byte code (smaller, less work, and portable). This would be image-based, so no file system would be necessary, and have a single-address space, so you could treat the entire internet as if it were part of your machine's memory. It would have a structure editor instead of an Emacs variant.
This is probably more than I'll ever have time to do. I have implemented my own Lisp dialect (which could form the basis of the system proposed above), and am using it to develop a visual dataflow programming language (http://web.onetel.com/~hibou/fmj/FMJ.html). Many here and elsewhere are skeptical of the value of this, but I'm convinced it's the right thing. My short-term goal is to add dependent types to the new language.
So I've dismissed the idea of a custom processor. It just doesn't seem to have much value vs using ARM or RISC-V or x64.
I've thought about the kernel aspect, but this mainly seems like drudge work. reimplementing stuff that's been a solved problem for a long time with linux. Not to mention drivers, which would be a massive massive effort.
So I sort of settled on the idea of a lisp based userland. That seems at least feasible.
I don't really understand containers well enough to understand what exactly is exposed to a program you are writing. I've heard you can run statically compiled programs without installing a base distribution. So maybe that would be where to start.
> These names are hold-overs from the original implementation of LISP on the IBM 704. That machine had partial-word instructions to reference the address and decrement parts of a machine location. The a of CAR comes from "address", the d of CDR comes from "decrement". the c and r come from "contents of" and "register". Thus CAR could be read "contents of address part of register".
Guy Steele and Gerry Sussman also made a working processor from this design, but only fabricated a few prototypes (apparently it was absurdly slow, even by their standards). If you come by Gerry's office he'll gladly show one off to you.
"Why Lisp Machines? The standard platform for Lisp before Lisp machines was a timeshared PDP-10, but it was well known that one Lisp program could turn a timeshared KL-10 into unusable sludge for everyone else. It became technically feasible to build cheaper hardware that would run lisp better than on timeshared computers. The technological push was definitely from the top down; to run big, resource hungry lisp programs more cheaply. Lisp machines were not "personal" out of some desire make life pleasant for programmers, but simply because lisp would use 100% of whatever resources it had available. All code on these systems was written in Lisp simply because that was the easiest and most cost effective way to provide an operating system on this new hardware."
Yes, of course it would be highly valuable.
The reason of the superiority of a Lisp machine is the following:
On a Lisp machine, what you manipulate is not files (text files or binary files), but meaningful information stored as s-expressions that can be directly shared by many applications, instead of being sent (copied) through pipes between processes in separate address spaces. This is where the power of a Lisp machine lies.
This, and much more, is masterfully explained in this paper by Robert Strandh:
Not so much anymore though. I feel like static type systems have progressed enough that dynamic typing really has little appeal to me at this point, especially the idea of dynamic stuff "all the way down."
Nowadays my fantasy is more along the lines of:
* a machine with a simple instruction set for CPU and GPU and without slow transfers between the two
* a modern statically typed language that can be used to program both CPU and GPU, that's basically "Rust, but better, and with simpler syntax without braces and semicolons and commas and with easier macros and..."
* some simple garbage collected extension language for runtime/dynamic stuff. Still statically typed though.
Makes me wonder: could there be a fully statically typed variant of Lisp? Did anyone try that?
FYI: Lisp already allows you to specify data types if you want, as if it were a statically typed language. If you do this, a good Lisp implementation, like SBCL, will then do static type checks and will also improve execution speed significantly -- with this plus other tricks, Lisp can approach Fortran and C speed.
Discussed here, for example: https://news.ycombinator.com/item?id=9297665
At least that's what I heard; I was working on the C++ based Newton OS, and sat next to the Dylan guys for a while, until they were told to stop work on their stuff. So I could have the level of "metalness" wrong.
Not really. Dylan was a stripped-down version of Common Lisp (which has an object system built in) with some of the fringier bits (like :before, :after, and :around methods) and the parentheses stripped off.
It didn't have special variables, but it did have module variables, which were lexically accessible from anywhere inside the module where they were defined, or in any module that imported them. THey were more like entries in Smalltalk dictionaries than special variables (a possibly-overlooked point is that the initial design discussions at Apple included several Smalltalk enthusiasts from ATG).
The object system would definitely have looked like Common Lisp. It was CLOS minus some of the bells and whistles, as you observed.
Also, like Scheme and unlike Common Lisp, Dylan was a Lisp-1, not a Lisp-2.
For those unfamiliar with that jargon, it refers to how namespaces are organized in Lisps. In Dylan, as in Scheme, there was a single namespace for variables, functions, types, and so on. For example, <collection> was the abstract superclass of all collections, but the name "<collection>" was just a read-only module variable that happened to refer to the (anonymous) class.
By contrast, in Common Lisp there are separate namespaces for variables, functions, classes, and some other things. Thus, in Common Lisp (but not in a Lisp-1), you can have a function named "address", a class named "address", and a lexical variable named "address", and they don't collide or shadow one another.
The original MessagePad might not have had enough memory to run a serious Dylan environment. But unshipped versions of the tablet newt ("Senior") did have enough, and my understanding is that they did, at least for a while.
I'm not sure whether it would fit on Junior; it might not. It was about half a megabyte. I don't remember how much room Junior had. I ran it daily, though, on a Senior prototype.
It wasn't a Lisp machine in the usual sense, though, and not just because it didn't have hardware tags bits and so forth. The development environment didn't run on Newton hardware; it was a heavily-customized version of Macintosh Common Lisp called Leibniz which ran on Mac hadware. Our Newton hardware was ribbon-cabled to the Macs' Nubus slots. Leibniz had both Common Lisp and Dylan development environments in the same runtime image, complete with text editors and listener windows for Lisp and for Dylan. We used Common Lisp code to manage and customize the development environment, and we used Dylan code to implement bauhaus OS features.
So I guess, in a sense, the combination of Mac hardware plus Newton hardware plus Leibniz acted sort of like a Lisp machine, but less featureful.
This isn't my itch, but some possible answers could include having hardware enforced type safety and architectural support for efficient execution. To give a rather extreme example of what is possible with a dedicated architecture, study the Reduceron [1,2]. IMO, doing something similar for Lisp would be much much easier.
Could it be done? Yes, absolutely and it would be great fun.
You'd have to work with an FPGA though unless you have a
sizable fortune to fab a chip (though 28nm is almost
PS: Reduceron has a hardware garbage collector
Was gonna try this but haven't yet.
After it's up, then what?
The CONS protoype (AI Memo 444):
The CADR (AI Memo 528):
The Symbolics lisp machine museum:
After-the-demise symbolics info:
P. Tucker Withington's contemporary thoughts:
Lisp family tree:
I wonder what type of legal challenges are inherent in making Genera open source? My limited understanding of the situation is that the IP of Symbolics is held up in an odd manner due to the dissolution of the company, but I don't know all of the details. It would be nice if Genera were open source and ported to the x86-64. Barring that, a free software clone of Genera would be nice, but it may be a substantial implementation effort.
It would have been easier to create a port of the LMI or TI systems to a workstation or 386 PC, they only ever used a 32 bit word. TI would have been the obvious candidate as they were building 68020 systems that used the same case as the Explorer. Add a simple external MMU to the 68020 and a native compiler and it would be reasonably fast.
I guess that LMI didn't have enough staff to look at something like this back then. There is a new Lambda emulator if anyone wants to play with it .
Xerox did port their software to workstations and I believe it is still sold by Venue.
I learned OO programming on a Symbolics 3600 using ZetaLisp+Flavors around 1987. It was a cool system (when it did not have hardware issues). I used a Symbolics to implement perhaps the first simulation of kinematic self-replicating robots (and accidentally invented robot cannibals -- another story as a cautionary tale...)
Genera may be interesting to play with for fun and learning -- but Smalltalk is much more of a living thing with ongoing communities around Squeak, Pharo, Amber, and more.
I liked Genera but I loved Smalltalk (first with ObjectWorks/VisualWorks and then other variants). After using those two environments, pretty much everything since has been disappointing and felt like big steps backward.
(Well, the Newton OS was cool too including with "Soups"... Sad Apple killed the Newton OS just as the MP2100 with the StrongARM was good enough hardware to run it well... I also liked HyperCard which Apple also killed... And I also learned Forth before any of those and it was cool within its niche...)
I tried that before with Python and also Jython about a decade ago, but did not quite get it to be as interactive: http://patapata.sourceforge.net/critique.html
Sadly though the philosophy that everything should be programmable has mostly been lost, though partially revived in the browser. But only partially.
I'm not sure what you are thinking of, but there's no such thing in RISC-V. Possibly you are referring the the goals of lowRISC, which will be RISC-V based but have various extensions.
I did ask the fellow from genera about disaster recovery (failed or borked hdd) and he said as I am a license holder he can send me cds or send the hdd and have him image it. The full source for genera is part of the image so tons of interactive docs and source to explore!
Pictures of my previous efforts:
http://www.smalltalk.org.br/fotos/ (with 68000 and ARM processor)
http://merlintec.com/swiki/hardware/28.html (with my own processor starting in 1999)
Currently I am replacing the ALU Matrix coprocessor described there with an alternative that is more generally useful. I will move the text somewhere public (github, for example) so people can always access the lasted version.
Back to the original topic, it is interesting to discuss what good would a Lisp Machine (or Smalltalk computer) be in 2017? Would it run the language faster than a x86 processor? Lisp Machines tried to be the best possible interpreter, but we now have advanced adaptive compilation technology. A very parallel Lisp could be really fast in a dedicated architecture (see GPUs and similar) but most people are interested in normal, sequential Lisp. In that case it might still have a niche if it could perform as well (or nearly as well) but with far fewer transistors (lower power and lower cost).
In short: a 2017 Lisp Machine should either go beyond the current Von Neumann model or it should do what you can do with Lisp on normal machines but cheaper and with less energy.