6 ms·

Makes you wonder what pioneers back in the 60s and 70s could have accomplished with modern hardware. What does Smalltalk or Englebert's NLS end up being with gi

Makes you wonder what pioneers back in the 60s and 70s could have accomplished with modern hardware. What does Smalltalk or Englebert's NLS end up being with gigs of RAM and high speed network connections? What would the LISP machines have been like? It still kills me to think that an OS crash on one of those took you into the Lisp debugger. And it kills me to think that Smalltalk and Visual Basic had a built-in GUI editor and layout manager, unlike the web.

SllX 9y ago
> What would the LISP machines have been like? It still kills me to think that an OS crash on one of those took you into the Lisp debugger. Sometimes I think a lot of people do use LISP machines. It's just called emacs. I joked on here once that I think the end game for GNU/HURD was ultimately to become a LISP machine via emacs, and if you look at some dev setups, that's not too far from what macOS and Linux are for them today: a place to run emacs and a web browser.
- pjmlp 9y ago
  It is not the same thing. Emacs is a tiny portion of what a Lisp Machine was capable of.
  - jacobush 9y ago
    I don't doubt you, but could you be more explicit?
    - pjmlp 9y ago
      Lisp Machines REPL was graphically based, not text based. So the REPL could display any kind of data structure, and later calls could influence already displayed data. https://www.youtube.com/watch?v=o4-YnLpLgtk&t=687s https://www.youtube.com/watch?v=o4-YnLpLgtk&t=687s https://www.youtube.com/watch?v=6uPwQuxjgQo https://www.youtube.com/watch?v=6uPwQuxjgQo https://www.youtube.com/watch?v=IMN5RSIm6xw https://www.youtube.com/watch?v=IMN5RSIm6xw There was GUI based debuggers. Then there was the access of the complete OS stack and other running applications, and everything was compiled to native code, there wasn't any VM running. Try do do a (disassemble func) on Emacs for seeing actual 80x86/ARM,....
      - drb91 9y ago
        You can get some of this with McCLIM today, though not much is written for it.
      - deleted 9y ago
        [deleted]
      - jacobush 9y ago
        Oh man... impressive.
- jacobush 9y ago
  The problem for me with Emacs is that (while I use it everyday for just about all editing, and recently org-mode) it's so damn brittle and hard to configure. It's like editing autoexec.bat on DOS and reboot to try your settings. Still, it's the best I've found.
  - TeMPOraL 9y ago
    I hope you don't reboot Emacs on every config change? M-x eval-region, M-x eval-last-sexp and M-x eval-buffer are your friends. Emacs is, as suits a Lisp system, strongly runtime-modifiable. It even has its own REPL - M-x ielm.
    - jacobush 9y ago
      I have to learn these things.
- jecel 9y ago
  How is that a joke? The third paragraph of the 1983 GNU project announcement (https://www.gnu.org/gnu/initial-announcement.en.html https://www.gnu.org/gnu/initial-announcement.en.html) said: "GNU will be able to run Unix programs, but will not be identical to Unix. We will make all improvements that are convenient, based on our experience with other operating systems. In particular, we plan to have longer filenames, file version numbers, a crashproof file system, filename completion perhaps, terminal-independent display support, and eventually a Lisp-based window system through which several Lisp programs and ordinary Unix programs can share a screen. Both C and Lisp will be available as system programming languages. We will have network software based on MIT's chaosnet protocol, far superior to UUCP. We may also have something compatible with UUCP."
  - SllX 9y ago
    Not many people today would think of their "GNU/Linux" system as a Lisp machine anymore than anybody thinks of their Chromebook as a JavaScript machine, nor is it really comparable to the Lisp Machines of the past.
    - jecel 9y ago
      I fully agree that GNU/Linux is nothing like a Lisp Machine, but that is because things didn't go according to the original plan (otherwise we would be talking about GNU/Trix).
  - lispm 9y ago
    But not 'via Emacs'. A Lisp Machine is not an Emacs OS.
    - jecel 9y ago
      A bit picky, but fair enough. One interesting thing about the original plan is that Unix was essentially text only back then. Part of the idea of making it more Lisp Machine-like was to have a GUI, so when Unix got that (with X11 eventually winning) this part of the plan became less urgent. I suppose an Emacs OS would be sort of a GUI but not quite?
pjmlp 9y ago
> Makes you wonder what pioneers back in the 60s and 70s could have accomplished with modern hardware. One of the best Bret Victor talks is about that. "The Future of Programming" https://www.youtube.com/watch?v=8pTEmbeENF4 https://www.youtube.com/watch?v=8pTEmbeENF4 > And it kills me to think that Smalltalk and Visual Basic had a built-in GUI editor and layout manager, unlike the web. Anyone of us doing desktop/mobile development on .NET, Java, Android, iOS, Qt development can still enjoy such goodies. With web, one day it might catch 90's RAD tooling.
- codingdave 9y ago
  One of the reasons it has never taken off is that GUI editors and layout managers that have come out for the web (and there have been a few), have never quite gotten the code right. They would produce a page that looked like the designer... but with terribly written HTML/CSS. So web designers and developers prefer to make their own markup.
  - pjmlp 9y ago
    I seldom recognize pieces of HTML/CSS literature when looking at the developer tools panel, or source code from well known frameworks.
  - lkrubner 9y ago
    The deeper problem is that the tech industry is slow to get rid of HTML, even though HTML was created to exchange documents, and nowadays we mostly use it as a GUI for network software. See "The Problem With HTML": http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html
    - ahartmetz 9y ago
      It used to be conventional wisdom that using HTML as a layout system is wrong, you know. Because it wasn't meant to be one, and text content was supposed to be independent of the medium on which it is viewed. Well, at the time I had my doubts that it was going to work, but it was (and still is) a nice idea.
TeMPOraL 9y ago
They'd accomplish a lot, but I fear most of it wouldn't take anyway. The problem is the Internet. Or, more precisely, other people. Those systems of old didn't separate between "an user" and "a developer" because they assumed all users are trusted (and responsible people). With the Internet, this assumption immediately becomes false - between people attacking the network and social engineering, it's dangerous to let people have that much control over their environment. Which is something that pisses me off, because I'd love to work on a modern-day version of a Lisp machine, but I understand this can't ever become mainstream (and myself I'd be worried using it to do my banking). Or, as I sometimes phrase it, Star Trek-level tech requires Star Trek-level society.
- TheOtherHobbes 9y ago
  I suspect there are Laws of Social Computing which guarantee that public networked systems inevitably converge on certain kinds of uses and applications, with certain consistently reinvented “abuses” and failure modes. Networked computing is just a mirror. We seem surprised when some of the things we see it aren’t very nice, but perhaps we shouldn’t be.
- drb91 9y ago
  > Those systems of old didn't separate between "an user" and "a developer" because they assumed all users are trusted (and responsible people). With the Internet, this assumption immediately becomes false - between people attacking the network and social engineering, it's dangerous to let people have that much control over their environment. More than that: ads. They really did destroy the internet.
- walterbell 9y ago
  We now have the HW/SW technology to authenticate and isolate code and individual humans, including the creation of parallel universes (copy-on-write disk and memory for transient VMs that are forked from running code) with optionally persistent side effects. Some of these ideas are present in https://cappsule.github.io/faq/ https://cappsule.github.io/faq/

SllX 9y ago

> What would the LISP machines have been like? It still kills me to think that an OS crash on one of those took you into the Lisp debugger. Sometimes I think a lot of people do use LISP machines. It's just called emacs. I joked on here once that I think the end game for GNU/HURD was ultimately to become a LISP machine via emacs, and if you look at some dev setups, that's not too far from what macOS and Linux are for them today: a place to run emacs and a web browser.

pjmlp 9y ago
It is not the same thing. Emacs is a tiny portion of what a Lisp Machine was capable of.
- jacobush 9y ago
  I don't doubt you, but could you be more explicit?
  - pjmlp 9y ago
    Lisp Machines REPL was graphically based, not text based. So the REPL could display any kind of data structure, and later calls could influence already displayed data. https://www.youtube.com/watch?v=o4-YnLpLgtk&t=687s https://www.youtube.com/watch?v=o4-YnLpLgtk&t=687s https://www.youtube.com/watch?v=6uPwQuxjgQo https://www.youtube.com/watch?v=6uPwQuxjgQo https://www.youtube.com/watch?v=IMN5RSIm6xw https://www.youtube.com/watch?v=IMN5RSIm6xw There was GUI based debuggers. Then there was the access of the complete OS stack and other running applications, and everything was compiled to native code, there wasn't any VM running. Try do do a (disassemble func) on Emacs for seeing actual 80x86/ARM,....
    - drb91 9y ago
      You can get some of this with McCLIM today, though not much is written for it.
    - deleted 9y ago
      [deleted]
    - jacobush 9y ago
      Oh man... impressive.
jacobush 9y ago
The problem for me with Emacs is that (while I use it everyday for just about all editing, and recently org-mode) it's so damn brittle and hard to configure. It's like editing autoexec.bat on DOS and reboot to try your settings. Still, it's the best I've found.
- TeMPOraL 9y ago
  I hope you don't reboot Emacs on every config change? M-x eval-region, M-x eval-last-sexp and M-x eval-buffer are your friends. Emacs is, as suits a Lisp system, strongly runtime-modifiable. It even has its own REPL - M-x ielm.
  - jacobush 9y ago
    I have to learn these things.
jecel 9y ago
How is that a joke? The third paragraph of the 1983 GNU project announcement (https://www.gnu.org/gnu/initial-announcement.en.html https://www.gnu.org/gnu/initial-announcement.en.html) said: "GNU will be able to run Unix programs, but will not be identical to Unix. We will make all improvements that are convenient, based on our experience with other operating systems. In particular, we plan to have longer filenames, file version numbers, a crashproof file system, filename completion perhaps, terminal-independent display support, and eventually a Lisp-based window system through which several Lisp programs and ordinary Unix programs can share a screen. Both C and Lisp will be available as system programming languages. We will have network software based on MIT's chaosnet protocol, far superior to UUCP. We may also have something compatible with UUCP."
- SllX 9y ago
  Not many people today would think of their "GNU/Linux" system as a Lisp machine anymore than anybody thinks of their Chromebook as a JavaScript machine, nor is it really comparable to the Lisp Machines of the past.
  - jecel 9y ago
    I fully agree that GNU/Linux is nothing like a Lisp Machine, but that is because things didn't go according to the original plan (otherwise we would be talking about GNU/Trix).
- lispm 9y ago
  But not 'via Emacs'. A Lisp Machine is not an Emacs OS.
  - jecel 9y ago
    A bit picky, but fair enough. One interesting thing about the original plan is that Unix was essentially text only back then. Part of the idea of making it more Lisp Machine-like was to have a GUI, so when Unix got that (with X11 eventually winning) this part of the plan became less urgent. I suppose an Emacs OS would be sort of a GUI but not quite?

pjmlp 9y ago

> Makes you wonder what pioneers back in the 60s and 70s could have accomplished with modern hardware. One of the best Bret Victor talks is about that. "The Future of Programming" https://www.youtube.com/watch?v=8pTEmbeENF4 https://www.youtube.com/watch?v=8pTEmbeENF4 > And it kills me to think that Smalltalk and Visual Basic had a built-in GUI editor and layout manager, unlike the web. Anyone of us doing desktop/mobile development on .NET, Java, Android, iOS, Qt development can still enjoy such goodies. With web, one day it might catch 90's RAD tooling.

codingdave 9y ago
One of the reasons it has never taken off is that GUI editors and layout managers that have come out for the web (and there have been a few), have never quite gotten the code right. They would produce a page that looked like the designer... but with terribly written HTML/CSS. So web designers and developers prefer to make their own markup.
- pjmlp 9y ago
  I seldom recognize pieces of HTML/CSS literature when looking at the developer tools panel, or source code from well known frameworks.
- lkrubner 9y ago
  The deeper problem is that the tech industry is slow to get rid of HTML, even though HTML was created to exchange documents, and nowadays we mostly use it as a GUI for network software. See "The Problem With HTML": http://www.smashcompany.com/technology/the-problem-with-html http://www.smashcompany.com/technology/the-problem-with-html
  - ahartmetz 9y ago
    It used to be conventional wisdom that using HTML as a layout system is wrong, you know. Because it wasn't meant to be one, and text content was supposed to be independent of the medium on which it is viewed. Well, at the time I had my doubts that it was going to work, but it was (and still is) a nice idea.

TeMPOraL 9y ago

They'd accomplish a lot, but I fear most of it wouldn't take anyway. The problem is the Internet. Or, more precisely, other people. Those systems of old didn't separate between "an user" and "a developer" because they assumed all users are trusted (and responsible people). With the Internet, this assumption immediately becomes false - between people attacking the network and social engineering, it's dangerous to let people have that much control over their environment. Which is something that pisses me off, because I'd love to work on a modern-day version of a Lisp machine, but I understand this can't ever become mainstream (and myself I'd be worried using it to do my banking). Or, as I sometimes phrase it, Star Trek-level tech requires Star Trek-level society.

TheOtherHobbes 9y ago
I suspect there are Laws of Social Computing which guarantee that public networked systems inevitably converge on certain kinds of uses and applications, with certain consistently reinvented “abuses” and failure modes. Networked computing is just a mirror. We seem surprised when some of the things we see it aren’t very nice, but perhaps we shouldn’t be.
drb91 9y ago
> Those systems of old didn't separate between "an user" and "a developer" because they assumed all users are trusted (and responsible people). With the Internet, this assumption immediately becomes false - between people attacking the network and social engineering, it's dangerous to let people have that much control over their environment. More than that: ads. They really did destroy the internet.
walterbell 9y ago
We now have the HW/SW technology to authenticate and isolate code and individual humans, including the creation of parallel universes (copy-on-write disk and memory for transient VMs that are forked from running code) with optionally persistent side effects. Some of these ideas are present in https://cappsule.github.io/faq/ https://cappsule.github.io/faq/