6 ms·

Can we have a simulation of that? Ideally from the hardware level of chips and mechanical design of keyboard?

by avmich 5y ago

jonathanstrange 5y ago
I think that the best way to get a similar experience would be to grab SBCL and write a high-level virtual machine on top of it that serves as a common GUI, application framework, editor, database, and provides other OS-related functions to make the developer experience 100% within Lisp. No Emacs or anything else from the outside, everything from audio over the graphics and the monitor sizes to networking needs to be abstracted away from the real machine. For example, every GUI and graphics feature needs to be freely scalable and resolution-invariant, based on virtual screens with their own coordinate systems. Aspect ratio is a problem, though, it probably needs to be taken from the real machine. 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.
- lispm 5y ago
  https://common-lisp.net/project/mcclim/ https://common-lisp.net/project/mcclim/ Alternatively a complete OS (not based on SBCL): https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano
  - jonathanstrange 5y ago
    Yes, I know these but my suggestion was pretty much the opposite, to use Linux as a basis and abstract away from it entirely. The result is better and much more usable. That's just my opinion, of course, and ymmv.
    - lispm 5y ago
      McCLIM runs on Linux, but it has tools like debugger, editor, listener and others written on top of it. Applications are possible. The UI is similar to that what a Symbolics had. It can serve as the UI part of a larger solution like you mentioned, where some services are provided by Linux, or tools on top of Unix (database, etc).
    - rjsw 5y ago
      An alternative could be to build SBCL into a unikernel.
Animats 5y ago
Well, if you made one, it would be much better than the original. We had one refrigerator-sized Symbolics machine at the aerospace company, during the false AI boom of the 1980s. I used it a few times, but it had one LISP fan who used it a lot for a specific project. It broke down a lot, and Symbolics service was very poor. The early versions had a really slow garbage collector. Minutes. With everything in one address space, you had to wait out the GC; you couldn't kill your program and start over. Many of those special-purpose buttons on the Space Cadet-derived keyboard didn't actually do anything. Unless, of course, someone rebound them in EMACS. 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.
- chris_st 5y ago
  I worked for about four years on Symbolics machines in the AI summer of the mid 80's. We were, perhaps, lucky in that I don't remember them breaking down at all, and our service guy was competent and entertaining. 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.
  - p_l 5y ago
    Refrigerator size suggests to me one of the very early models, which in fact could have been much more problematic than any of the latter. I seem to recall being warned in case of "free to good home" 3600 about how delicate it was.
jdboyd 5y ago
From a historical interest perspective, I would love to see some Symbolics simulators. 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.
- bitwize 5y ago
  > 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. 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#.
  - diskzero 5y ago
    Are you saying a modern developer running Lisp has most of the same features of a Lisp Machine? If not, what language(s) are you referring to?
throwaway81523 5y ago
The Symbolics software is still proprietary, I think. The MIT CADR software is available and can run under emulation, but last I heard it was not all the way there. I'm sure some people here know more about it than I do.
- imglorp 5y ago
  Yes, see http://symbolics-dks.com http://symbolics-dks.com 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.
- rjsw 5y ago
  The MIT CADR software can also run on an FPGA. The main problem with it is that we only have a saved image from a pre-Common Lisp version, there are sources and compiled files for a later version that does implement Common Lisp as well but so far we have not worked out a way to get an updated image. There is an emulator for the LMI Lambda hardware that can run an improved version of the final LMI software.

Can we have a simulation of that? Ideally from the hardware level of chips and mechanical design of keyboard?

by avmich 5y ago

Can we have a simulation of that? Ideally from the hardware level of chips and mechanical design of keyboard?

I think that the best way to get a similar experience would be to grab SBCL and write a high-level virtual machine on top of it that serves as a common GUI, application framework, editor, database, and provides other OS-related functions to make the developer experience 100% within Lisp. No Emacs or anything else from the outside, everything from audio over the graphics and the monitor sizes to networking needs to be abstracted away from the real machine. For example, every GUI and graphics feature needs to be freely scalable and resolution-invariant, based on virtual screens with their own coordinate systems. Aspect ratio is a problem, though, it probably needs to be taken from the real machine. 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.

lispm 5y ago
https://common-lisp.net/project/mcclim/ https://common-lisp.net/project/mcclim/ Alternatively a complete OS (not based on SBCL): https://github.com/froggey/Mezzano https://github.com/froggey/Mezzano
- jonathanstrange 5y ago
  Yes, I know these but my suggestion was pretty much the opposite, to use Linux as a basis and abstract away from it entirely. The result is better and much more usable. That's just my opinion, of course, and ymmv.
  - lispm 5y ago
    McCLIM runs on Linux, but it has tools like debugger, editor, listener and others written on top of it. Applications are possible. The UI is similar to that what a Symbolics had. It can serve as the UI part of a larger solution like you mentioned, where some services are provided by Linux, or tools on top of Unix (database, etc).
  - rjsw 5y ago
    An alternative could be to build SBCL into a unikernel.

Animats 5y ago

Well, if you made one, it would be much better than the original. We had one refrigerator-sized Symbolics machine at the aerospace company, during the false AI boom of the 1980s. I used it a few times, but it had one LISP fan who used it a lot for a specific project. It broke down a lot, and Symbolics service was very poor. The early versions had a really slow garbage collector. Minutes. With everything in one address space, you had to wait out the GC; you couldn't kill your program and start over. Many of those special-purpose buttons on the Space Cadet-derived keyboard didn't actually do anything. Unless, of course, someone rebound them in EMACS. 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.

chris_st 5y ago
I worked for about four years on Symbolics machines in the AI summer of the mid 80's. We were, perhaps, lucky in that I don't remember them breaking down at all, and our service guy was competent and entertaining. 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.
- p_l 5y ago
  Refrigerator size suggests to me one of the very early models, which in fact could have been much more problematic than any of the latter. I seem to recall being warned in case of "free to good home" 3600 about how delicate it was.

jdboyd 5y ago

From a historical interest perspective, I would love to see some Symbolics simulators. 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.

bitwize 5y ago
> 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. 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#.
- diskzero 5y ago
  Are you saying a modern developer running Lisp has most of the same features of a Lisp Machine? If not, what language(s) are you referring to?

throwaway81523 5y ago

The Symbolics software is still proprietary, I think. The MIT CADR software is available and can run under emulation, but last I heard it was not all the way there. I'm sure some people here know more about it than I do.

imglorp 5y ago
Yes, see http://symbolics-dks.com http://symbolics-dks.com 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.
rjsw 5y ago
The MIT CADR software can also run on an FPGA. The main problem with it is that we only have a saved image from a pre-Common Lisp version, there are sources and compiled files for a later version that does implement Common Lisp as well but so far we have not worked out a way to get an updated image. There is an emulator for the LMI Lambda hardware that can run an improved version of the final LMI software.