5 ms·

Running Open Genera 2.0 on Linux

88 points by GTP 3y ago

s1gnp0st 3y ago
We will carry this beautiful artifact forward with us until all its lessons have been learned. There was composability and fine control in these systems that is still not present in modern systems. That's not needed for everyday consumers, but boy is it lovely when you're a programmer.
- pjmlp 3y ago
  I feel that during the last two decades only Java and .NET ecosystems have come close to the experience, including Android and Powershell/Windows/.NET into the mix, naturally with caveats and plenty of "yes but" counter arguments. I consider a lost opportunity not to have turned ChromeOS into a kind of Smalltalk like experience with a mix of Flutter/Dart. Naturally one can argue Common Lisp experience with Franz and Lisp Works, Raket, or Smalltalk, are the closest to the Lisp Machine ideas, but their mainstream opportunity is now lost.
  - wk_end 3y ago
    Both the Java and .NET ecosystems are monumental (in every sense of the word) engineering accomplishments, but they don't strike me as very similar to the ultra-dynamic, introspective Lisp Machine experience. Can you elaborate on that a little bit? FWIW, the browser (though still far off) feels closer to me, with the ability to instantly pop open a DevTools console and inspect the state of everything, as does Apple's Cocoa-based stuff from my limited exposure to it, maybe not surprising given its Smalltalk heritage.
    - pjmlp 3y ago
      You have to think about the whole ecosystem and not only the VM. Dynamic nature of the runtime, being able to plug agents, changing code dynamically, the IDE experience inherited from Smalltalk vendors that jumped into Java, VisualVM and JFR, ETW, runtime APIs to the JITs, self hosted implementations, nowadays out of fashion, sending bytecodes for RPCs and network agents (RMI, .NET Remoting, Jini), are some of the reasons.
      - brabel 3y ago
        Exactly... the JVM is incredibly dynamic. It's gone totally out of fashion because of security and complexity, but I used to enjoy using OSGi to load just about any Java library into the runtime by typing its Maven coordinates, then immediately start using the library from a shell... and then just remove that lib if I didn't "like it" and it would be gone as if it never existed... I don't think a lot of people realize you can quite easily do that kind of thing on the JVM.
        pjmlp 3y ago
        Yeah, it is no accident that a JIT designed originally for Strongtalk ended up becoming the first JIT for Java. And .NET by being "Java 2.0" after the J++ lawsuit, inherited most of the same dynamism, alongside the ability to support VB capabilities, which by VB 6 were also quite nice.
        zozbot234 3y ago
        Part of the idea of WASM components is to support these same tricks with a more modern, better performing standard platform.
        pjmlp 3y ago
        That is the sales pitch, the reality is that 10 years later it is still catching up with features offered by other bytecode formats explored since UNCOL came to be in 1958.
        whartung 3y ago
        The feature and bug of the OSGI experience is its rather coarse granularity. It’s finer grained than, say, a WAR, but obviously much different than something akin to the Smalltalk or, to a lesser extent, Common Lisp. That said, make no mistake, an OSGI module can easily fall into that sweet spot of compiling and reloading fast enough to fall within the cognitive loop of effectively being “instant”. And if you organize your code well, other parts of the overall app are (mostly) unaware something has changed. Java can be quite dynamic but has not formalized things like dynamic class change lifecycle. OSGI does expose that, and lets the rest of the code tap into that so it can handle change more robustly.
- GTP 3y ago
  I'm too young to have ever touched a lisp machine, but I heard many opinions about them. If you used one, could you please briefly share your experience?
  - EdwardCoffin 3y ago
    I think the best description of the kind of thing the lisp machines (the Symbolics ones, at least) supported is described in this thread mostly carried by Kent Pitman [1]. I'd at least read all of the comments he wrote as well as whatever else you need for the context he is posting in. Edit: this thread too [2] [1] https://groups.google.com/g/comp.lang.lisp/c/QzKZCbf-S6g/m/KnsOdcyWzc8J https://groups.google.com/g/comp.lang.lisp/c/QzKZCbf-S6g/m/K... [2] https://groups.google.com/g/comp.lang.lisp/c/XpvUwF2xKbk/m/Xz4Mww0ZwLIJ https://groups.google.com/g/comp.lang.lisp/c/XpvUwF2xKbk/m/X...
  - deleted 3y ago
    [deleted]
  - nickpsecurity 3y ago
    Well, it's a combination of the hardware, OS, IDE, and language. Modern languages and VM's have caught up to many features of the Lisp machine. I've read lots of people's comments about them along with its documentation. Let me highlight a few things you might still like. The language is highly dynamic, supports types for better speed, macros let it rewire itself to better express concepts, it is interpreted for instant development, still compiled with good performance, safer by default than many compiled languages, and you can edit the code and save state of running programs. I've just named off advantages of all kinds of programming languages all mixed into one. The flexibility was so strong that, as new paradigms were added (eg OOP, aspects), they could just bring in a library to make the language itself do that. Aside from live debugging, my favorite feature when trying Lisp was per-function, incremental compilation.: make a change within a function, press a button, that individual function was compiled (sub-1-second), and that got loaded into the system for live interactions. I could iterate about as fast as I could think or type with the code still being fairly quick. It was mind blowing. Today's machines have OS's in one language, supporting libraries might be in another, there's often a runtime with its own style, the app language itself for the logic, and usually one for the web browser. The mismatches between these languages can cause all kinds of headaches. Debugging them takes different tools. In a Lisp Machine, everything from the OS to the IDE to your apps were written in Lisp. IIRC they came with source. Any failure in any layer loads up in the same IDE with code in same language. The IDE was also fully-featured for its time. Today, we have a lot of good IDE's. I don't think most of them share a language, source, and libraries with your apps, though. I'd like to see a comparison between top IDE's today and the Lisp Machine to see where today's tooling is stronger or weaker. Those are a few things that come to mind. I assure you that my experience trying to code in native languages was way different in both development speed and debugging. Learning Python now, it's good for rapid development but not as flexible or compiled. Lisp would give me all that. Many more ecosystems are using Python, though. By using Python, I get to use every library they build, guide they write, and maybe get paid for my code. Odds of all of that go down when using Lisp. Such social factors, along with high cost of Lisp Machines, are a huge part of why they disappeared. Less-powerful languages are going strong. If using a Lisp (eg Clojure), it's often tied to platforms written in non-Lisp languages.
LispSporks22 3y ago
I love building software from within the system that runs it. I really hate the edit compile run/ maybe debug cycles of popular, “modern” software development.
- coliveira 3y ago
  Nowadays the closest you can get to this is either Smalltalk (using squeak for example) or, going to the other side of the spectrum, Forth (using gforth for example).
  - chx 3y ago
    There are other people still alive who know Forth? :) I thought we died out.
b112 3y ago
[flagged]
- deleted 3y ago
  [deleted]
Zambyte 3y ago
Obviously this is more true to actual Lisp machines than Emacs, but in practice how different of a UX would this be? Ignoring the huge ecosystem around Emacs, it seems like the main difference is being able to save the application state and restore it at a later time. Are there any other major differences?
- pjmlp 3y ago
  Think about the bootloader landing on Emacs, being graphical based not text, compiling elisp to native code, the image based, systems programming forms for elisp, the whole OS infrastructure and graphical applications, that is how much it is missing from Emacs.
- lispm 3y ago
  see for example two Symbolics applications demoed: https://www.youtube.com/watch?v=RQKlgza_HgE https://www.youtube.com/watch?v=RQKlgza_HgE first demo is about Paintamation, a 2,5d paint and animation application the second demo is demoing the 3d modeler and the 3d animation application running on the Symbolics with a b&w console, a color screen & framebuffer, a Lisp keyboard and a pen tablet All the code was written in object-oriented Lisp.
  - malkia 3y ago
    Completely unrelated, but I think "symbolics.com" was the absolutely first domain registered. Also thanks for the video :) :) :)
    - lispm 3y ago
      > but I think "symbolics.com" was the absolutely first domain registered no quite, there were a few earlier domains registered. But it's the first .com domain registered.
      - chx 3y ago
        More like created, registration process was not open. Was there anything but the darpa domains and nordu.net before symbolics?
zeroclicks 3y ago
This sounds like a terrible way to run a lisp emulator. One shell command after another which assume one has the apt(1) package manager available on their system. Maybe the title of the article is poorly done. The easiest way to run a lisp machine is just to start emacs (there are ports for various operating systems) or try something like racket where you have a REPL with graphics and other goodies installed. I know HN loves lisp, but putting this article on the front page is a good way to deter lisp adoption.
- wk_end 3y ago
  You can argue that Emacs is a "Lisp machine", in that it's an environment you could conceivably think of as a kind of virtual "machine" in which you can run a particular Lisp (although arguably Elisp isn't what most people mean by Lisp), but this is about Lisp Machines[0], which are very specific historical computers. I hope it would go without saying to anyone looking to adopt Lisp that this is for historical interest* only and you should instead install a modern Lisp like SBCL or what have you. [0] https://en.wikipedia.org/wiki/Lisp_Machines https://en.wikipedia.org/wiki/Lisp_Machines * (nd IMO its the sort of historical interest that indeed belongs on the front page of HN)
  - zeroclicks 3y ago
    You're right that "Lisp Machines" refer to a very peculiar point in time, available to only a very small number of people. The article even mentions: > This was all accurate as of around 2018, but please be aware that things may have changed since then! There's no reason this should appear on the frontpage of a "news" site.
    - wk_end 3y ago
      Based on the age of your account, you're new here, so...for better or worse, things that aren't "News" regularly are popular on Hacker News. Even if it's not new, it's can still be new to one of the lucky 10,000.
- lispm 3y ago
jjwiseman 3y ago
When a site is defined, Genera calls (si:enable-who-calls :new) automatically for you.. But we want to enable who-calls on all functions, not just new functions, so we must manually set that up (si:enable-who-calls :all) This takes a few minutes to run. My god, it takes minutes to run now? How long did that take to run on the original hardware?
- lispm 3y ago
  On my Apple M2 Pro it runs in 15 seconds on a large world. A real Ivory machine would be roughly 70 times slower.
  - tallbikeguy 3y ago
    I'm struggling to configure/build the VLM on my M2 Mac running Ubuntu in a VM - any chance you could share your configure.ac or build process?
gumby 3y ago
I have never been as productive as I was when I had (the terminals for) two of these babies on the desks in my office. I can't imagine how much they must have cost in 1985, much less in today's dollars. I do remember each had 8 MW of memory (40 bits IIRC, 36 bit word + 4 bits of ECC) and one of them had a color display (!!!) in addition to the regular monitor. And apart from the hardware cost, the machines themselves were in a machine room with coax and data run to my office.
- mcculley 3y ago
  What were you developing or working on with them? My only exposure to Symbolics was as part of a simulation system.
  - gumby 3y ago
    Cyc https://en.wikipedia.org/wiki/Cyc https://en.wikipedia.org/wiki/Cyc
    - mcculley 3y ago
      Very cool!
floren 3y ago
So has anyone tried this lately? I'm on an up-to-date Debian Stable running X and FVWM, and when I try to run it I see https://pastebin.com/7bJk7Mr4 https://pastebin.com/7bJk7Mr4 (acts like it can't find the x server)

88 points by GTP 3y ago

We will carry this beautiful artifact forward with us until all its lessons have been learned. There was composability and fine control in these systems that is still not present in modern systems. That's not needed for everyday consumers, but boy is it lovely when you're a programmer.

pjmlp 3y ago
I feel that during the last two decades only Java and .NET ecosystems have come close to the experience, including Android and Powershell/Windows/.NET into the mix, naturally with caveats and plenty of "yes but" counter arguments. I consider a lost opportunity not to have turned ChromeOS into a kind of Smalltalk like experience with a mix of Flutter/Dart. Naturally one can argue Common Lisp experience with Franz and Lisp Works, Raket, or Smalltalk, are the closest to the Lisp Machine ideas, but their mainstream opportunity is now lost.
- wk_end 3y ago
  Both the Java and .NET ecosystems are monumental (in every sense of the word) engineering accomplishments, but they don't strike me as very similar to the ultra-dynamic, introspective Lisp Machine experience. Can you elaborate on that a little bit? FWIW, the browser (though still far off) feels closer to me, with the ability to instantly pop open a DevTools console and inspect the state of everything, as does Apple's Cocoa-based stuff from my limited exposure to it, maybe not surprising given its Smalltalk heritage.
  - pjmlp 3y ago
    You have to think about the whole ecosystem and not only the VM. Dynamic nature of the runtime, being able to plug agents, changing code dynamically, the IDE experience inherited from Smalltalk vendors that jumped into Java, VisualVM and JFR, ETW, runtime APIs to the JITs, self hosted implementations, nowadays out of fashion, sending bytecodes for RPCs and network agents (RMI, .NET Remoting, Jini), are some of the reasons.
    - brabel 3y ago
      Exactly... the JVM is incredibly dynamic. It's gone totally out of fashion because of security and complexity, but I used to enjoy using OSGi to load just about any Java library into the runtime by typing its Maven coordinates, then immediately start using the library from a shell... and then just remove that lib if I didn't "like it" and it would be gone as if it never existed... I don't think a lot of people realize you can quite easily do that kind of thing on the JVM.
      - pjmlp 3y ago
        Yeah, it is no accident that a JIT designed originally for Strongtalk ended up becoming the first JIT for Java. And .NET by being "Java 2.0" after the J++ lawsuit, inherited most of the same dynamism, alongside the ability to support VB capabilities, which by VB 6 were also quite nice.
      - zozbot234 3y ago
        Part of the idea of WASM components is to support these same tricks with a more modern, better performing standard platform.
        pjmlp 3y ago
        That is the sales pitch, the reality is that 10 years later it is still catching up with features offered by other bytecode formats explored since UNCOL came to be in 1958.
      - whartung 3y ago
        The feature and bug of the OSGI experience is its rather coarse granularity. It’s finer grained than, say, a WAR, but obviously much different than something akin to the Smalltalk or, to a lesser extent, Common Lisp. That said, make no mistake, an OSGI module can easily fall into that sweet spot of compiling and reloading fast enough to fall within the cognitive loop of effectively being “instant”. And if you organize your code well, other parts of the overall app are (mostly) unaware something has changed. Java can be quite dynamic but has not formalized things like dynamic class change lifecycle. OSGI does expose that, and lets the rest of the code tap into that so it can handle change more robustly.
GTP 3y ago
I'm too young to have ever touched a lisp machine, but I heard many opinions about them. If you used one, could you please briefly share your experience?
- EdwardCoffin 3y ago
  I think the best description of the kind of thing the lisp machines (the Symbolics ones, at least) supported is described in this thread mostly carried by Kent Pitman [1]. I'd at least read all of the comments he wrote as well as whatever else you need for the context he is posting in. Edit: this thread too [2] [1] https://groups.google.com/g/comp.lang.lisp/c/QzKZCbf-S6g/m/KnsOdcyWzc8J https://groups.google.com/g/comp.lang.lisp/c/QzKZCbf-S6g/m/K... [2] https://groups.google.com/g/comp.lang.lisp/c/XpvUwF2xKbk/m/Xz4Mww0ZwLIJ https://groups.google.com/g/comp.lang.lisp/c/XpvUwF2xKbk/m/X...
- deleted 3y ago
  [deleted]
- nickpsecurity 3y ago
  Well, it's a combination of the hardware, OS, IDE, and language. Modern languages and VM's have caught up to many features of the Lisp machine. I've read lots of people's comments about them along with its documentation. Let me highlight a few things you might still like. The language is highly dynamic, supports types for better speed, macros let it rewire itself to better express concepts, it is interpreted for instant development, still compiled with good performance, safer by default than many compiled languages, and you can edit the code and save state of running programs. I've just named off advantages of all kinds of programming languages all mixed into one. The flexibility was so strong that, as new paradigms were added (eg OOP, aspects), they could just bring in a library to make the language itself do that. Aside from live debugging, my favorite feature when trying Lisp was per-function, incremental compilation.: make a change within a function, press a button, that individual function was compiled (sub-1-second), and that got loaded into the system for live interactions. I could iterate about as fast as I could think or type with the code still being fairly quick. It was mind blowing. Today's machines have OS's in one language, supporting libraries might be in another, there's often a runtime with its own style, the app language itself for the logic, and usually one for the web browser. The mismatches between these languages can cause all kinds of headaches. Debugging them takes different tools. In a Lisp Machine, everything from the OS to the IDE to your apps were written in Lisp. IIRC they came with source. Any failure in any layer loads up in the same IDE with code in same language. The IDE was also fully-featured for its time. Today, we have a lot of good IDE's. I don't think most of them share a language, source, and libraries with your apps, though. I'd like to see a comparison between top IDE's today and the Lisp Machine to see where today's tooling is stronger or weaker. Those are a few things that come to mind. I assure you that my experience trying to code in native languages was way different in both development speed and debugging. Learning Python now, it's good for rapid development but not as flexible or compiled. Lisp would give me all that. Many more ecosystems are using Python, though. By using Python, I get to use every library they build, guide they write, and maybe get paid for my code. Odds of all of that go down when using Lisp. Such social factors, along with high cost of Lisp Machines, are a huge part of why they disappeared. Less-powerful languages are going strong. If using a Lisp (eg Clojure), it's often tied to platforms written in non-Lisp languages.

LispSporks22 3y ago

I love building software from within the system that runs it. I really hate the edit compile run/ maybe debug cycles of popular, “modern” software development.

coliveira 3y ago
Nowadays the closest you can get to this is either Smalltalk (using squeak for example) or, going to the other side of the spectrum, Forth (using gforth for example).
- chx 3y ago
  There are other people still alive who know Forth? :) I thought we died out.

b112 3y ago

[flagged]

deleted 3y ago
[deleted]

Zambyte 3y ago

Obviously this is more true to actual Lisp machines than Emacs, but in practice how different of a UX would this be? Ignoring the huge ecosystem around Emacs, it seems like the main difference is being able to save the application state and restore it at a later time. Are there any other major differences?

pjmlp 3y ago
Think about the bootloader landing on Emacs, being graphical based not text, compiling elisp to native code, the image based, systems programming forms for elisp, the whole OS infrastructure and graphical applications, that is how much it is missing from Emacs.
lispm 3y ago
see for example two Symbolics applications demoed: https://www.youtube.com/watch?v=RQKlgza_HgE https://www.youtube.com/watch?v=RQKlgza_HgE first demo is about Paintamation, a 2,5d paint and animation application the second demo is demoing the 3d modeler and the 3d animation application running on the Symbolics with a b&w console, a color screen & framebuffer, a Lisp keyboard and a pen tablet All the code was written in object-oriented Lisp.
- malkia 3y ago
  Completely unrelated, but I think "symbolics.com" was the absolutely first domain registered. Also thanks for the video :) :) :)
  - lispm 3y ago
    > but I think "symbolics.com" was the absolutely first domain registered no quite, there were a few earlier domains registered. But it's the first .com domain registered.
    - chx 3y ago
      More like created, registration process was not open. Was there anything but the darpa domains and nordu.net before symbolics?

zeroclicks 3y ago

This sounds like a terrible way to run a lisp emulator. One shell command after another which assume one has the apt(1) package manager available on their system. Maybe the title of the article is poorly done. The easiest way to run a lisp machine is just to start emacs (there are ports for various operating systems) or try something like racket where you have a REPL with graphics and other goodies installed. I know HN loves lisp, but putting this article on the front page is a good way to deter lisp adoption.

wk_end 3y ago
You can argue that Emacs is a "Lisp machine", in that it's an environment you could conceivably think of as a kind of virtual "machine" in which you can run a particular Lisp (although arguably Elisp isn't what most people mean by Lisp), but this is about Lisp Machines[0], which are very specific historical computers. I hope it would go without saying to anyone looking to adopt Lisp that this is for historical interest* only and you should instead install a modern Lisp like SBCL or what have you. [0] https://en.wikipedia.org/wiki/Lisp_Machines https://en.wikipedia.org/wiki/Lisp_Machines * (nd IMO its the sort of historical interest that indeed belongs on the front page of HN)
- zeroclicks 3y ago
  You're right that "Lisp Machines" refer to a very peculiar point in time, available to only a very small number of people. The article even mentions: > This was all accurate as of around 2018, but please be aware that things may have changed since then! There's no reason this should appear on the frontpage of a "news" site.
  - wk_end 3y ago
    Based on the age of your account, you're new here, so...for better or worse, things that aren't "News" regularly are popular on Hacker News. Even if it's not new, it's can still be new to one of the lucky 10,000.
lispm 3y ago

jjwiseman 3y ago

When a site is defined, Genera calls (si:enable-who-calls :new) automatically for you.. But we want to enable who-calls on all functions, not just new functions, so we must manually set that up (si:enable-who-calls :all) This takes a few minutes to run. My god, it takes minutes to run now? How long did that take to run on the original hardware?

lispm 3y ago
On my Apple M2 Pro it runs in 15 seconds on a large world. A real Ivory machine would be roughly 70 times slower.
- tallbikeguy 3y ago
  I'm struggling to configure/build the VLM on my M2 Mac running Ubuntu in a VM - any chance you could share your configure.ac or build process?

gumby 3y ago

I have never been as productive as I was when I had (the terminals for) two of these babies on the desks in my office. I can't imagine how much they must have cost in 1985, much less in today's dollars. I do remember each had 8 MW of memory (40 bits IIRC, 36 bit word + 4 bits of ECC) and one of them had a color display (!!!) in addition to the regular monitor. And apart from the hardware cost, the machines themselves were in a machine room with coax and data run to my office.

mcculley 3y ago
What were you developing or working on with them? My only exposure to Symbolics was as part of a simulation system.
- gumby 3y ago
  Cyc https://en.wikipedia.org/wiki/Cyc https://en.wikipedia.org/wiki/Cyc
  - mcculley 3y ago
    Very cool!

floren 3y ago

So has anyone tried this lately? I'm on an up-to-date Debian Stable running X and FVWM, and when I try to run it I see https://pastebin.com/7bJk7Mr4 https://pastebin.com/7bJk7Mr4 (acts like it can't find the x server)