Can we have a simulation of that? Ideally from the hardware level of chips and mechanical design of keyboard?
I did LISP work then, but mostly using Franz LISP on VAXen and Sun Workstations. I was never really into the LISP cult, though I wrote a lot of LISP. Franz LISP could compile to .o files, but you couldn't just link them and make an executable. You had to load them back into the LISP environment. I asked the Franz people why they didn't package up the run time so that you could just link the thing and make an executable without debug break and interpreter capability. They were puzzled at the question. Delivering a finished product was totally alien to them.
Eventually, hard-compiled LISP on microprocessors became faster than custom LISP hardware, and LISP machines went away. And, eventually, other languages got enough dynamism that LISP was no longer needed.
It's one of those things which was better in retrospect.
I remember when the generational GC was released. Before that, we just used to reboot at the end of the day... but the generational GC just worked, and we didn't have to worry about memory (so much). Our rep installed the GC thermometer (that showed in the overscan area so you didn't lose any screen real estate), and that really showed the difference.
And, by the way, it was Zmacs, not Emacs on the Symbolics.
I was advised that if possible, grab the boards necessary to upgrade 3600 to 3670 to have much easier life ;)
Lisp isn’t dead. It’s not taking over the world, but it looks like Clojure is a top 25 and Common Lisp might be a top 40 language: https://redmonk.com/sogrady/files/2021/08/lang.rank_.0621.pn...
I ran it on an AtariST.
From a productivity and ergonomics perspective, I don't think chip level simulation would be the way two go. First, Genera has been ported forward to new system. First OpenGenera was released for Tru/64 on the DEC Alpha platform as an official product. The fastest Symbolics hardware was about 6 times faster than the original Symbolics hardware. OpenGenera on a 533mhz Alpha was about 3 times faster still. There is a project called VLM to let you run OpenGenera on x86 or ARM and I would imagine it is many times faster still. Also, to my understanding, OpenGenera can still be purchased from symbolics-dks.com for a heft fee.
Second, I think that productivity will be limited by how much it is stuck in the past. If nothing else, crypto being behind the times seems likely to be an issue with networking with the rest of the world.
I would love to see a more modern system like OpenGenera. I also would love to see Symbolics style keyboards be made and possibly upgraded with things like better keyswitches and USB. That should be doable for someone who wants to make a custom layout, circuit board for that layout, and keycaps but based on QMK compatible hardware.
[1] https://interlisp.org/ &
[2] https://github.com/interlisp
Thereby uplifting this environment to current systems without layers upon layers of emulation, fully and legally open-sourced.
Open Genera and Portable Genera use an emulator written in assembler (running on DEC Alpha, X86-64 and ARM64 - for the CPU emulation) and output goes to X11.
edit: OFC i know Interlisp-D/Medley is also an emulation. But directly retargeted, and legally open source. And not 'production ready', for now. But seems to be only a matter of time.
People I know used it on original DEC Alphas and on Alpha emulators running under Windows.
The new version, called Portable Genera, has three assembler Ivory emulator versions: DEC Alpha, Intel x86-64 and ARM64.
> And does it matter if it's practically unavailable?
There are a few users.
Without having to break the bank, or being otherwise artificially constrained.
Yes? ;-)
1.) (potential) portability, speed
2.) amount of delivered/contained applications
3.) look&feel/usability
4.) access to full source
5.) price (ignoring time)
edit: or use %, 1 to 10, whatever you like
The MIT Lispm software is BSD. http://www.heeltoe.com/retro/mit/mit_cadr_lmss.html It's very old (>40 years) , had never more than a low hundred users. Dead for decades. No Common Lisp. No TCP/IP.
LMI Lispm Software: old, license unclear. TI Lispm software: leaked, uncomplete, no license.
Symbolics Lispm software: partly leaked, no license, owner exists, commercially available. Has a Common Lisp implementation. Best Lispm software. Most development stopped mid 90s. Some updates in the last years, due to a new emulator. Emulator was a commercial product.
Interlisp/Medley: open sourced after a long time being not available. A Common Lisp version which very few people ever used. Emulator was a commercial product. The software is largely written in Interlisp, a Lisp dialect which has been mostly dead for 35 years with almost no users, no libraries, ...
All of these have some very cool technology, but much of it is between 50 and 30 years old.
It's not the Lisp for the 'rest of us', it's for hobby software archeologists, for the few people who have capabilities to update them and for the <100 actual users/developers using them for work.
And I pointed out that maybe the next best thing would be https://news.ycombinator.com/item?id=29245984
With the intent to not having to start from scratch, not necessarily using it as is, but to take inspiration from. Or not, and really pushing it forward instead, but that depends on so many factors. However, it is possible.
Besides that, did you really have the impression 'innocent people' had to be warned of the consequences, wasted time, whatever? ;-)
Furthermore, either Common Lisp is Common Lisp, or not. So what does it matter, if only few people ever used that?
As soon as it's getting graphical there is nothing besides the two commercial vendors(so proprietary), and old McCLIM.
So who really cares? There is Movitz and Mezzano, why should there be no effort to make Medley modern?
Would McCLIM on steroids be better for SBCL and Clozure? Who knows?
I for my part like to look deep into such things, to see how I can adapt the concepts(not necessarily code) into my dabblings on FPGAs.
Sometimes I had my mind blown, by things I haven't seen before, didn't even know the possibility thereof. Learning new concepts, applying them.
Like this https://www.youtube.com/watch?v=4bM3Gut1hIk (not related to topic)
Anyway, I like to go back into the roads not taken, to at least partially re-branch from there. There is much to learn from. From that what we have now, not so much.
Not really. Currently the most Common Lisp is SBCL. There is software out there and the probability of being able to run it on a Lisp implementation depends on its compatibility (and the effort that has been taken to make it compatible). Medley is very different from most other Lisps, even from other Lisp Machines, so it would be interesting how get software in and out of it, make it compatible, etc. Actual software depends on more than just 'Common Lisp' (which itself has a lot of differences between implementations): file system, I/O system, characters, networking, threading, FFI, TCO, ... Lisp Machines have a very different operating system and very different development environments. Lots of basic assumptions don't apply there.
> why should there be no effort to make Medley modern
There is already some. We'll see what it brings.
> Anyway, I like to go back into the roads not taken, to at least partially re-branch from there. There is much to learn from. From that what we have now, not so much.
Even though the past stuff interest me (and I remember a time, when there were active Lisp Machine users around), I learn a lot from stuff we have now, too.
Open Genera was soft emulation of the Symbolics Ivory hardware on Alpha. I believe they didn't even do anything fancy like dynarec; which is why it was such a doddle to port it (from binaries?!) to amd64.
> Second, I think that productivity will be limited by how much it is stuck in the past. If nothing else, crypto being behind the times seems likely to be an issue with networking with the rest of the world.
A modern developer running Visual Studio Code has most of the features the Lisp Machines had, and then some. Edit and continue can even be had under Java and C#.
There is an emulator for the LMI Lambda hardware that can run an improved version of the final LMI software.
I once spoke to David once asking if they would open source the UI for posterity and he politely replied in the negative. There are a few MacIvory installations left floating around so they might have a support contract stream (I'm guessing) although I'm not sure what other possible income they hope will be coming.
The preservation part is becoming most acute as there will soon be zero hardware and zero people who can get this into digital museum status.
Anyone who wants to develop such a thing would have to take care to also abstract away from common mechanisms that are not very useful. For example, there seems to be absolutely no need to speak about files in such a system except for legacy support with the outside world. Likewise, standard network access should be on a self-configuring virtual p2p network whereas normal networking is a legacy system to the outside world.
Well, that's just my idea of a good Lisp machine. I don't mind if it runs on Linux as long as it doesn't feel like it. On the contrary, having such a large ecosystem underneath would allow the VM developers to integrate existing technologies freely into the VM. All it takes is to write a Lisp abstraction layer that deliberately prohibits any direct access to the underlying non-Lispy implementation. (If you grant too much access to the outside from the VM, then you destroy the VM's purpose - guaranteed interoperability, full reflection, and interactivity.)
However, I don't see such a truly interactive environment to happen because it's a lot of work.
Alternatively a complete OS (not based on SBCL):