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.