5 ms·

As someone who used Franz LISP on Sun workstations while someone else nearby used a Symbolics 3600 refrigerator-sized machine, I was never all that impressed wi

As someone who used Franz LISP on Sun workstations while someone else nearby used a Symbolics 3600 refrigerator-sized machine, I was never all that impressed with the LISP machine. The performance wasn't all that great. Initially garbage collection took 45 minutes, as it tried to garbage-collect paged-out code. Eventually that was fixed. The hardware was not very good. Too much wire wrap and slow, arrogant maintenance. I once had a discussion with the developers of Franz LISP. The way it worked was that it compiled LISP source files and produced .obj files. But instead of linking them into an executable, you had to load them into a run-time environment. So I asked, "could you put the run time environment in another .obj file, so you just link the entire program and get a standalone executable"? "Why would you want to do that?" "So we could ship a product." This was an alien concept to them. So was managing LISP files with source control, like everything else. LISP gurus were supposed to hack. And, in the end, 1980s "AI" technology didn't do enough to justify that hardware.

varjag 1y ago
Lisp Machines had versioning file systems IIRC. Kinda like on VMS. Was SCCS really that far ahead?
- johnisgood 1y ago
  You are correct, see: https://en.wikipedia.org/wiki/Versioning_file_system#LMFS https://en.wikipedia.org/wiki/Versioning_file_system#LMFS. Also: https://hanshuebner.github.io/lmman/pathnm.xml https://hanshuebner.github.io/lmman/pathnm.xml It is worth mentioning that while it is not versioning per se, APFS and ZFS support instantaneous snapshots and clones as well. Btrfs supports snapshots, too. HAMMER2 in DragonFlyBSD has the ability to store revisions in the filesystem.
- rst 1y ago
  Ummmm... yes. The problem with versioning file systems is that they only kept the last few versions; for files under active development, it was usually difficult to recover state older than a week or two. (SCCS handled collaborative development and merges a lot worse than anything current, but... versioning file systems were worse there, too; one war story I heard involved an overenthusiastic developer "revising" someone else's file with enough new versions that by the time the original author came back to it, their last version of the code was unrecoverable.)
- kragen 1y ago
  Yes, because on VMS (and presumably Genera) 20 versions of a file took 20× as much disk space as one version, so you wouldn't keep unlimited versions. In SCCS the lines that didn't change are only stored once, so 20 versions might be 2× or 1.1× or 1.01× the original file size.
raverbashing 1y ago
> "So we could ship a product." This was an alien concept to them. This mentality seems to have carried over to (most) modern FP stacks
- whstl 1y ago
  Nah, it carried over to scripting languages. Most of them still require a very specific, very special, very fragile environment to run, and require multiple tools and carefully ran steps just so it does same you can do with a compiled executable linked to the OS. They weren't made for having libraries, or being packaged to run in multiple machines, or being distributed to customers to run in their own computers. Perhaps JS was the exception but only to the last part. Sure it mostly works today, but a lot of people put a lot of the effort so we can keep shoving square pegs into round roles.
  - raverbashing 1y ago
    You are correct unfortunately
  - jacquesm 1y ago
    Don't get me started. I tried to use a very simply python program the other day, to talk to a bluetooth module in a device I'm building. In the end I gave up and wrote the whole thing in another language, but that wasn't before fighting the python package system for a couple of hours thinking the solution is right around the corner, if only I can get rid of one more little conflict. Python is funny that way, it infantilized programming but then required you to become an expert at resolving package manager conflicts. For a while Conda seemed to have cracked this, but there too I now get unresolvable conflicts. It is really boggling the mind how you could get this so incredibly wrong and still have the kind of adoption that python has.
    - ErroneousBosh 1y ago
      [flagged]
rjsw 1y ago
Franz Lisp could create standalone executables from very early in the project, the compiler is one.
- e40 1y ago
  Correct. To continue the puns, it was called Liszt.
MangoToupe 1y ago
> The hardware was not very good. The hardware was never very interesting to me. It was the "lisp all the way down" that I found interesting, and the tight integration with editing-as-you-use. There's nothing preventing that from working on modern risc hardware (or intel, though please shoot me if I'm ever forced back onto it).
e40 1y ago
I worked on Franz Lisp at UCB. A couple of points: The ".obj" file was a binary file that contain machine instructions and data. It was "fast loaded" and the file format was called "fasl" and it worked well. The issue of building an application wasn't an issue because we had "dumplisp" which took the image in memory and wrote it to disk. The resulting image could be executed to create a new instance of the program, at the time dumplisp was run. Emacs called this "unexec" and it did approximately the same thing. Maybe your discussions with my group predated me and predated some of the above features, I don't know. I was Fateman's group from '81-84. I assume your source control comments were about the Lisp Machine and not Franz Lisp. RCS and SCCS were a thing in the early 80's, but they didn't really gain steam until after I arrived at UCB. I was the one (I think... it was a long time ago) that put Franz Lisp under RCS control.
- Animats 1y ago
  I was doing this in 1980-1983. Here's some code.[1] It's been partly converted to Common LISP, but I was unable to get some of the macros to work. This is the original Oppen-Nelson simplifier, the first SAT solver. It was modified by them under contract for the Pascal-F Verifier, a very early program verifier. We kept all the code under SCCS and built with make, because the LISP part was only part of the whole system. [1] https://github.com/John-Nagle/pasv/tree/master/src/CPC4 https://github.com/John-Nagle/pasv/tree/master/src/CPC4
  - e40 1y ago
    Do you remember who you discussed it with? It had to be either Sklower or Foderaro, unless you talked with Fateman. Were the macros originally from another dialect of Lisp?
    - Animats 1y ago
      Franz LISP had, I think, MacLISP macros, while Common LISP has a different system. I talked to Fateman at some point. Too long ago to remember about what.
  - specialgoodness 1y ago
dtagames 11mo ago
You've hit the nail on the head. It's the inability to ship product from a Lisp machine that killed the idea. The fungibility of Lisp all the way down turned each machine into a one-off lab of its own. And this tech arrived after the industry had started moving from bespoke solutions provided by hardware companies to packaged software from specialized firms. Since Lisp machines aren't good at maintaining a duplicatable environment, they're not terribly useful for commercial software production nor as a distribution target. Source: I was a mainframe compiler developer at IBM during this era.

varjag 1y ago

Lisp Machines had versioning file systems IIRC. Kinda like on VMS. Was SCCS really that far ahead?

johnisgood 1y ago
You are correct, see: https://en.wikipedia.org/wiki/Versioning_file_system#LMFS https://en.wikipedia.org/wiki/Versioning_file_system#LMFS. Also: https://hanshuebner.github.io/lmman/pathnm.xml https://hanshuebner.github.io/lmman/pathnm.xml It is worth mentioning that while it is not versioning per se, APFS and ZFS support instantaneous snapshots and clones as well. Btrfs supports snapshots, too. HAMMER2 in DragonFlyBSD has the ability to store revisions in the filesystem.
rst 1y ago
Ummmm... yes. The problem with versioning file systems is that they only kept the last few versions; for files under active development, it was usually difficult to recover state older than a week or two. (SCCS handled collaborative development and merges a lot worse than anything current, but... versioning file systems were worse there, too; one war story I heard involved an overenthusiastic developer "revising" someone else's file with enough new versions that by the time the original author came back to it, their last version of the code was unrecoverable.)
kragen 1y ago
Yes, because on VMS (and presumably Genera) 20 versions of a file took 20× as much disk space as one version, so you wouldn't keep unlimited versions. In SCCS the lines that didn't change are only stored once, so 20 versions might be 2× or 1.1× or 1.01× the original file size.

raverbashing 1y ago

> "So we could ship a product." This was an alien concept to them. This mentality seems to have carried over to (most) modern FP stacks

whstl 1y ago
Nah, it carried over to scripting languages. Most of them still require a very specific, very special, very fragile environment to run, and require multiple tools and carefully ran steps just so it does same you can do with a compiled executable linked to the OS. They weren't made for having libraries, or being packaged to run in multiple machines, or being distributed to customers to run in their own computers. Perhaps JS was the exception but only to the last part. Sure it mostly works today, but a lot of people put a lot of the effort so we can keep shoving square pegs into round roles.
- raverbashing 1y ago
  You are correct unfortunately
- jacquesm 1y ago
  Don't get me started. I tried to use a very simply python program the other day, to talk to a bluetooth module in a device I'm building. In the end I gave up and wrote the whole thing in another language, but that wasn't before fighting the python package system for a couple of hours thinking the solution is right around the corner, if only I can get rid of one more little conflict. Python is funny that way, it infantilized programming but then required you to become an expert at resolving package manager conflicts. For a while Conda seemed to have cracked this, but there too I now get unresolvable conflicts. It is really boggling the mind how you could get this so incredibly wrong and still have the kind of adoption that python has.
  - ErroneousBosh 1y ago
    [flagged]

rjsw 1y ago

Franz Lisp could create standalone executables from very early in the project, the compiler is one.

e40 1y ago
Correct. To continue the puns, it was called Liszt.

MangoToupe 1y ago

> The hardware was not very good. The hardware was never very interesting to me. It was the "lisp all the way down" that I found interesting, and the tight integration with editing-as-you-use. There's nothing preventing that from working on modern risc hardware (or intel, though please shoot me if I'm ever forced back onto it).

e40 1y ago

I worked on Franz Lisp at UCB. A couple of points: The ".obj" file was a binary file that contain machine instructions and data. It was "fast loaded" and the file format was called "fasl" and it worked well. The issue of building an application wasn't an issue because we had "dumplisp" which took the image in memory and wrote it to disk. The resulting image could be executed to create a new instance of the program, at the time dumplisp was run. Emacs called this "unexec" and it did approximately the same thing. Maybe your discussions with my group predated me and predated some of the above features, I don't know. I was Fateman's group from '81-84. I assume your source control comments were about the Lisp Machine and not Franz Lisp. RCS and SCCS were a thing in the early 80's, but they didn't really gain steam until after I arrived at UCB. I was the one (I think... it was a long time ago) that put Franz Lisp under RCS control.

Animats 1y ago
I was doing this in 1980-1983. Here's some code.[1] It's been partly converted to Common LISP, but I was unable to get some of the macros to work. This is the original Oppen-Nelson simplifier, the first SAT solver. It was modified by them under contract for the Pascal-F Verifier, a very early program verifier. We kept all the code under SCCS and built with make, because the LISP part was only part of the whole system. [1] https://github.com/John-Nagle/pasv/tree/master/src/CPC4 https://github.com/John-Nagle/pasv/tree/master/src/CPC4
- e40 1y ago
  Do you remember who you discussed it with? It had to be either Sklower or Foderaro, unless you talked with Fateman. Were the macros originally from another dialect of Lisp?
  - Animats 1y ago
    Franz LISP had, I think, MacLISP macros, while Common LISP has a different system. I talked to Fateman at some point. Too long ago to remember about what.
- specialgoodness 1y ago

dtagames 11mo ago

You've hit the nail on the head. It's the inability to ship product from a Lisp machine that killed the idea. The fungibility of Lisp all the way down turned each machine into a one-off lab of its own. And this tech arrived after the industry had started moving from bespoke solutions provided by hardware companies to packaged software from specialized firms. Since Lisp machines aren't good at maintaining a duplicatable environment, they're not terribly useful for commercial software production nor as a distribution target. Source: I was a mainframe compiler developer at IBM during this era.