This was one of the things that convinced me to buy one (I have a MacIvory Model II). I've found it a bit difficult to get into, mainly because I don't have the time to spend immersed in it long enough to make the things I've learned stick. I also suspect that a number of the real benefits come from things that aren't immediately apparent, you really need to work with people who know the environment to show you these tricks. I know that's the way I learned Smalltalk - if I'd learned it from books on my own, I'd probably have not realized all the advantages that could be gotten from such an interactive environment.

If anyone can suggest any features like the two that Pitman describes above that I (or anyone else) could investigate, that would be great.

That said, I encourage people who want to hack/learn Lisp to stick with one of the modern setups like: Common Lisp (with Emacs or a complete free IDE setup like ClozureCL), Clojure (with Emacs or other IDE), Racket, or, ...., etc.

I would much rather see people spend time learning a Lisp language rather than fiddling with very old environments.

Both of these guys are hardcore Emacs users, running Mac OS X, and have in-depth knowledge of POSIX. It was hard for me to write them off as people who just didn't understand how modern computers work.

Fiddling with Genera has been a very worthwhile endeavor because of how much I've learned from it.

What have I learned? Well, so far I've learned that Genera is basically a case study showing that Richard Stallman's fears were actually well founded. I also learned a tremendous amount about an important but obscure part of the history of computing, a history that I think is actually a vision of what our future is.

So, yes, by all means, hack on and learn on one of the modern setups that Mark suggests above. Once you've done that, look me up and I'd be more than happy to give you a tour of Genera on my MacIvory.

Could you expand on that?

Lisp Machines started at MIT, some of that code is actually available online now (http://www.heeltoe.com/retro/mit/mit_cadr_lmss.html). That software became the basis of two companies: Symbolics and then later, Lisp Machines Inc (LMI). This Wikipedia entry does a good job at explaining the impact this part of history had on RMS: http://en.wikipedia.org/wiki/Lisp_Machines#Folklore_about_LM...

So, here is where the history of Genera is non-existent or murky. Yes, you can download a torrent of Genera. But how do you obtain a legal license Genera? Who actually owns the IP to Genera?

In learning the answers to those questions, I was left with even more respect for RMS and an amusing, if not ironic, anecdote showing how his vision for the future turned out to be correct.

> How do you obtain a legal license Genera?

You purchase a copy of Open Genera for the DEC Alpha for $5000 from David Schmidt.

> Who actually owns the IP to Genera?

John Mallery (http://www.csail.mit.edu/user/926). He's the most recent owner. Before he got the IP, it was owned by a series of law firms and ex-Symbolics employees.

Why do I find this this amusing? Well, the software that RMS worked so hard to protect and that ultimately helped "inspire" him to start GNU has been relegated to the footnotes of history. Meanwhile, GNU software is used on millions of machines.

LOL. Great, anyone got a spare Alpha lying around?

> This Wikipedia entry does a good job at explaining the impact this part of history had on RMS

I'm looking at this line: "Unfortunately this openness would later lead to accusations of intellectual property theft."

That doesn't really capture the acrimony iirc. I was just a youngin' at the time, but I remember overhearing rms get a phone call; I believe it was from someone at the Symbolics legal team. They were trying to explain to him how he had violated something-or-another because he built some LISP feature from scratch.

They went round in circles for a while, finally rms tired of the conversation and ended it. It was a very bizarre conversation for an academic environment like the AI Lab.

IIRC, there's a Linux version that owners of Open Genera for the DEC Alpha are allowed to download.

When the research created the first usable prototypes of hardware (the Lisp Machines and other stuff) and software (expert systems, ...) DARPA wanted to commercialize it to create a market which then could serve their needs. So licenses of the Lisp Machine design were sold to LMI, Symbolics and later TI. DARPA financed also the users. Many machines were funded to be bought by university projects. Much of the early Lisp Machines were sold to the SDI project (strategic defense initiative, a pet child of Ronald Reagan in the cold war, the space deployed missile defense system).

Stallman's role in that scenario is relatively tiny. He worked on software and when some of the stuff he was using was about to be commercialized (in the above context), he protested against it. DARPA's mission was not to develop free Lisp software, but to develop battle management systems, logistics software, diagnosis software for complex military equipment, assistents/trainers for fighter pilots, missile guidance software, ...

Stallman fought for free software, but he was working in a government funded lab, where the funders (DARPA) had a very different mission. The 'hacker spirit' at the lab was more of an accident, attracting creative people to develop the next generation of software and hardware. For the military and other government agencies, with commercial spin offs.

As mentioned the SDI initiative was using this technology. But there were several others. One of the biggest wins was DART, http://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replanning...

Stallman developed a lot of GNU software, but the goal of a new Lisp environment was given up early. For the initial goals see the GNU manifesto: http://www.gnu.org/gnu/manifesto.html

Funny side note: In the AI Lab, the names of the Symbolics machines started as dead rock stars. (Sinatra too, I think.) After they ran out of those, dead movie stars were used for names. RR was not too popular in those parts (he was president at the time), so he was one of the machine names too.

It was all fun and games until some D/ARPA reviewers walked through the machine room and put it together.

I've thought of just calling him. But I'm intimidated of him to be honest. He wrote the webserver that ran whitehouse.gov during the Clinton administration, I can barely program in Lisp.

I've used this trick quite successfully ($20-50 items from appropriate gift vendors -- Cabelas for outdoor type people, gourmet food vendors for other people).

It's like the next-level of conference schwag.

It seems very plausible though, given John's background.

I would love to read it. Please post it to HN if you ever get to it, I think a lot of people (including me) are interested in the concepts and ideas behind Genera and other Lisp machines.

Could you expand on that as well?

How is it that we lost the ability to fix the code to a program that crashed, then continue running the program from where it left off? Why aren't all of our tools self-documenting? Etc, etc.

I've spent quite a bit of time wondering why we've "lost" so much. I think that part of the problem is that technology was developed a rate faster than what most people could keep up with. I remember that early Macs had a game to teach people how to use the mouse! Also, before the internet, it was hard for to transmit software and information about it.

So, the way I view the world of technology now is that we haven't "lost" anything, we're just catching up with the past. And doing a better job of it too!

In many ways, I think that the capabilities of "HTML5" (HTML/CSS/JavaScript) are converging on the capabilities of the X Window system. The main difference that I can see is that "HTML5" requires about 2-4 inches of book to understand while the X Windows System required a couple of feet of book to understand.

I'm not sure if my view of us just needing to catch up with the past is correct, but it's been pretty useful to me. Now, instead of bemoaning things that are lost, I look forward to seeing those things again, in a form that is easier to understand. More "pure" if you will.

I'm looking forward to the day when I can edit any part of my OS or applications, live, while they are running. I'm looking forward to being able to fix a program that has crashed and then have it continue running. I enjoy using interactive debuggers and I'm looking forward to seeing them in more languages. I love using REPLs to learn new languages and for doing quick prototyping.

That's why I'm watching JavaScript with interest. Many people are doing things with JavaScript that we were doing with Lisp Machines before. Some people are able to edit their server-side JavaScript live. Many of us know that our web browser has a built-in JavaScript REPL, some of us use that to fix webpages that other people wrote.

In short. After spending a lot of time reading, talking about, and using Lisp Machines, I feel like I have a deeper understanding of what William Gibson meant when he said "The future is already here — it's just not very evenly distributed."

Footnote: 1: http://www.cs.washington.edu/homes/weise/preface.html

    NeWS was architecturally similar to what is now called AJAX, except that NeWS:
    - used PostScript code instead of JavaScript for programming.
    - used PostScript graphics instead of DHTML/CSS for rendering.
    - used PostScript data instead of XML/JSON for data representation.

* a self-documenting editor

* a doc browser, which integrates with said editor

* a high performance compiler, which integrates with the above two

* a debugger that can step through OS code as easily as program code

* the ability to stop a program midexecution, change it, and continue from where you stopped.

Python is a script interpreter running on UNIX. Nothing more, nothing less. It's terribly misguided to compare it to a LispM. You don't even know what you're missing.

I'm glad you didn't fall for that trap. Software engineers constantly make excuses for doing things in idiotic ways. Almost nothing I use really works anymore. It just "kind of" works most of the time. Look at your average web applicaton and the ridiculous resources it takes to get the thing up on the screen and interacting with the user. We've become addicted to high powered machines and finding more complex and inefficient ways of doing the same things.

We need to take it back to the old skool.

Well, maybe I'm not in that trap now, but I was for a long time.

> Almost nothing I use really works anymore.

I'm hoping that I can hide from that inside the Emacs monastery. That didn't seem to work for jwz though, so I'm not sure if there's a way to avoid having to update my silly software several times a decade.

As a general rule learning is better than repeating, however there is value in those old environments. Primarily for a long time software was getting more complex than hardware could support and so there are a lot of adaptations that were made in 'old environments' to support better performance on under-performant hardware.

As we enter the 'post PC' era and get a wider spread of machine capabilities in the market place, it is always useful to have a few 'tricks' in your pocket for getting better performance out of your system.

Knowing that you got those tricks from systems that are now > 20 years old provides a pretty good patent defense if you get trolled. Especially if you can show that you, being reasonably skilled in the art, learned to do what you did using exemplars that are greater than 20 yrs old. That is a strong case for prior art.

I worked on Symbolics machines (rms, please forgive me). I even fixed a bunch of the wire-wrapped original LMs from before Symbolics.

I remember it being earth-shattering at the time (self-documenting? whoa) but I confess I'm curious how much was just the transition from TOPS-20 etc to a completely new single-user environment. All stuff from the dark ages really.

I'd probably fire it up out of nostalgia if nothing else.

BTW: Dan Weinreb's post ("Why did symbolics fail?" linked in the OP) has migrated to here: http://danweinreb.org/blog/why-did-symbolics-fail

The "Help" button the Symbolics machines blew me away. I've used software with great built-in help. It's impressive to see it system-wide.

Another thing that I still find really impressive is how (aside from the bootloader) all of Genera is written in Lisp and can be edited, live, while the system is running.

A lot of the things that I see people doing with JavaScript feel very familiar. It's exciting to see how the things that people are doing with JavaScript are approaching the capabilities of Genera, but in a way that will be much more accessible to the "kids these days".

Yes, we don't have a Lisp or Smalltalk like environment for JavaScript. Not yet. Given how widely supported JavaScript is though, I could see us getting there organically? Not sure.

http://lively-kernel.org/

I like Embscripten and so forth for hack value, but this is a terrible way to build systems. I mean, people want sandboxed code in the browser, so why not make the whole browser sandboxed? Because nobody cares enough to put the effort in, I guess. Chrome is the only browser going along these lines and Mozilla is doing its best to hose down that effort because it just might allow people to program for a simple portable VM instead of all this application-parading-as-a-platform web standards stuff.

http://www.2ality.com/2012/02/servo.html is worth a read.

> Chrome is the only browser going along these lines

Chrome is using a C++ core with no plans to stop doing that that I know of....

I also think JavaScript is a bad basis for a platform in any case, since it requires loads of complexity to be fast. Why not just a simple typed language or VM? I have read some JS JIT papers and they have found plenty of code generation bugs (more security holes).

For the rest, one of the main points of Rust and servo is to have better security-by-design. Whether the DOM ends up implemented in JS or in Rust is still up in the air at this point, but either one would be much better than C++ from a security perspective.

As for JavaScript, it's what we have due to happenstance, but displacing it involves either a huge amount more complexity in web browsers (to support JavaScript _and_ another language both touching the same objects and whatnot without memory leaks) or just dropping JS entirely and implementing some other language (not exactly likely to succeed). Maybe someone will create a VM that can run both JS and something else well. Maybe. It's not all that simple to do.

We don't need a VM to run JS "well". Nothing going on in the browser is even CPU intensive if not for the huge gobs of complexity going on. People are making simple things harder and harder to do, and complex things easier and easier. If you just write everything for a simple typed VM you don't have to bend over backward to make things run fast. There's nothing going on in the client side of say, GMail, that I couldn't do (faster!) on the computer I was using in 1997.

     > Nothing going on in the browser is even CPU
     > intensive if not for the huge gobs of complexity going on.

Note that GMail is not an example of an application that really does intensive JS. A photo editing app would be a better example.

It's CPU intensive because of the way it's done, not because it intrinsically requires much CPU. That was my point. And it's not just algorithms; everything goes through a million layers of abstraction.

>Note that GMail is not an example of an application that really does intensive JS. A photo editing app would be a better example.

Again, I was doing photo-editing years ago with no troubles. You wouldn't even be able to start your JS photo editing app on a 1996 computer. And by focusing on "CPU-intensive" tasks you're missing an essential point, which is that stuff that shouldn't require any CPU does. My system shouldn't pause - ever. We have optimised everything for high throughput on powerful machines. The JVM suffers from exactly this problem. Java is plenty "fast" if you ignore latency.

There's just nothing demanding enough to require that going on. And yet the UI locks up for 1-2 seconds pretty frequently on my $1000 desktop machine with loads of RAM and CPU. It's even worse on my $400 laptop. There's nothing intrinsic in the hardware or the tasks that should cause this to happen - it's the design of the software. It's because the system is too complex and preemptable that this happens.

I wrote about my experiences learning to use Genera here: http://genera.posterous.com/ - which reminds me, I need to spend more time with Genera.

I've also been told that a lot of things didn't work or were missing in the version of Genera that people can find online. I can't speak to the validity of that statement though.

Take, for example, read and write barriers for GC. On a modern system with virtual memory, each memory access is run through a TLB which has among other things protection and page out bits. That could easily be supplemented with a couple of extra bits to implement GC barriers. While we were getting greedy, we could even add a lightweight trap mechanism of handling the associated faults in user space, at the user's privilege level, to avoid the expense of transitioning into kernel privilege level (indeed Intel and AMD implement all the necessary functionality in their virtualization extensions).

One anecdote that he likes to use is to compare the speed of Smalltalk running on the Xerox Alto computer with Smalltalk running on a current CPU that is 50,000x faster than the Alto. He notes that benchmarks run in both systems are only 50x faster, claiming that this means we've lost a factor of 1000x in efficiency just on the basis of using inferior architectures (at least inferior if your target language isn't C).

Part of me is thankful for the relentless push of x86 and the speed gains realized, but another part of me really regrets that all of the crazy architectures from the 70's and 80's have been lost.

The Alto's main memory had a cycle time of about 850 nsec, and could transfer 2 16-bit words per cycle: http://www.computer-refuge.org/bitsavers/pdf/xerox/parc/tech....

This gives a main memory bandwidth of roughly 5 MB/sec. A top-end single CPU system today has probably 25 GB/sec available to it, a factor of 5,000 more. Moreover, much of that is achieved through optimizing burst reads--actual sustained random access throughput is going to be much lower and the delta much less.

Given modern implementation techniques, the actual efficiency loss is probably on the order of 10x rather than 1000x. And much of it is the result of the memory wall, which has been driven by DRAM physics rather than micro-architecture. Doing a couple of memory lookups to support dynamic dispatch is a hell of a lot more expensive, relative to an ALU operation, these days than it was 30 years ago.

Dan Ingalls gave a talk in 2005 about the history of Smalltalk implementations in which he mentioned the Xerox NoteTaker. The NoteTaker was a PC powered by the 8086, and according to Ingalls executed Smalltalk VM bytecode at twice the speed of the Alto. Here is the link to the talk: http://www.youtube.com/watch?v=pACoq7r6KVI#t=42m50s and here is my analysis with more details on the specs and economics of the NoteTaker: http://carcaddar.blogspot.com/2012/01/personal-computer-youv...

Same thing with stack machines vs registers (why would you ever want a stack machine for CPS-compiled code?), tagged arithmetic (SPARC has tagged arithmetic instructions, but it turns out pipelining makes "manual" tag-checking just as fast), etc.

If anything, a pipelined, superscalar RISC CPU benefits Lisp more than it does C.

The strict conceptual partitioning of software problems and hardware problems is quite passé these days. In the last 10 years, Intel and AMD have added a tremendous amount of very CISC-y functionality into x86 (e.g. string search instructions), in recognition of the fact that exploding transistor budgets make hardware the right place to implement certain things.

> but there was no reason why the GC couldn't have been moved into kernel space before virtualization extensions came along.

GC couldn't have been moved into kernel space because of the second part of my argument: UNIX hides hardware features not necessary to run C programs. The MMU can do quite a lot that is obscured behind the very limited mmap() abstraction.

"Also, note that the Sunstone project did address many of the competitive concerns, especially the continual mention of Sun in this analysis. The Sunstone project included a chip design for a platform meant to run Unix and C, as well as Lisp. It was a safe C exploiting the tagged architecture, for example, to allow checking of array bounds. And the Sunstone project was being produced on-time. But to back up the analysis of Symbolics’ priorities, it was cancelled as we were getting the first chips back from LSI Logic."

I'm assuming that it should be getting the date and time from the network but that doesn't seem to be working either, although I'm not using a dedicated host like in the article. I'll do further exploration on a dedicated machine at a later date.

(It's been a couple of years since I booted my LispM, but I used to know how to do this :-)

  Error: Unable to set calendar clock
  
  TIME:SET-CALENDAR-CLOCK
    Arg 0 (TIME:NEW-TIME): 354054620

Edit: the emulator is outputting:

  arithmeticexception; file stub/output10 line 215