5 ms·

Very interesting, thanks. Why do you suppose Lisp-M isn't more widely used?

jff 10y ago
Lisp machines were expensive, the early ones at least took a very long time to boot, and I think there are weaknesses to the Lisp "image"/"world"/whatever model that Lisp-M partisans aren't quite willing to acknowledge. They're still extraordinarily cool machines.
- throwanem 10y ago
  > there are weaknesses to the Lisp "image"/"world"/whatever model that Lisp-M partisans aren't quite willing to acknowledge I'd be interested to hear this expanded upon.
  - mikelevins 10y ago
    Old-fashioned Lisp and Smalltalk systems presented a programming model in which the language process is your running program, but it doesn't yet know how to do the right thing. Your job is to interactively teach it how to be your application. This you do by teaching it one little piece at a time until it is transformed into the application you want. This process is facilitated by the ability to at any point save the state of the process for later resumption. These saved states are called "heaps" or "images" or "worlds". Start up one of them and you are more or less instantly returned to the last state you were in when the process was last running. LispMs extended this model to the entire machine. There are advantages and disadvantages. The advantages are legion, and they can enormously accelerate development in the hands of someone comfortable with that mode of working. There are two main types of disadvantage. One is that, since you are interactively modifying a live, running system, if you make a mistake, the mistake becomes part of the running system. If you save the image with that mistake in it, it becomes part of the system in future sessions, too. The second problem is that it becomes troublesome to separate your application from the scaffolding that you've used to build it. To take a very simple example, suppose you construct a few simple data structures for testing purposes. Those test structures then become part of the running system, and there is a risk that your application will inadvertently come to depend on their values, leading to obscure bugs if they change or if the application is deployed without them. There are reasonably straightforward ways to deal with both classes of problem, and properly-designed Lisp and Smalltalk systems include tools that help solve these problems, but it's appropriate to acknowledge them as problems. I like old-fashioned Lisp and Smalltalk systems, and I like image-based development. I prefer the programming model in which I am teaching the process to be my application, and I'm much more productive in such an environment than in the now more-mainstream, model where programming is more like building something from a blueprint than it is like teaching something to behave the way I want. But that doesn't mean I don't acknowledge the problems of image-based development. They exist. They are solvable, but they do exist.
- lispm 10y ago
  > very long time to boot Actually a typical Symbolics 3600 didn't boot much longer than a SUN... my NXP1000 Lisp Machine boots in three minutes from a very large image.
  - convolvatron 10y ago
    i'm not trying to be fussy, but we would boot the 3670 overnight when the GC stopped being able to catch up with itself. because as i recall it took a couple hours
    - lispm 10y ago
      A full GC could take easily take half an hour on a machine with large virtual memory. Booting then was much faster.
mikelevins 10y ago
They were expensive. Sun workstations that cost five figures were cheap compared to LispMs. Their UI was powerful and efficient, but not easy to learn. They were designed by programmers for programmers. Their UI assumed that you were willing to invest nontrivial time and effort learning a broad palette of specialized tools. Their system design made some pretty different assumptions about how they were going to be used, and the environment they would be used in. For example, LispMs didn't have any kind of security or memory protection. They were wide open systems.
- lispm 10y ago
  If you would have wanted a comparable Lisp experience on a SUN workstation (large bitmap screen, large disk, software, ...) the actual price difference wasn't that much. But there were a lot of underpowered and slow SUNS, which were cheaper. But then you would better not use Allegro CL, Lucid CL or LispWorks on those. 16 or even 24 MB RAM were simply not enough and GC was fighting with the virtual memory pager... The big cost driver at that time was memory and peripherals like disks. The lab I worked for had slow SUN SPARCs. The idea was that you would net boot them and they would get their software from a main server. Relatively cheap. But it turned out a bit slow and clunky. People then often used their office Macs for software development, with Macintosh Common Lisp.
  - mikelevins 10y ago
    True, but the point is that there weren't any really cheap LispMs until it was too late to matter. Besides which, a system that was so much designed for programmers was probably never going to command a very big market.
    - lispm 10y ago
      There was never a really cheap Lispm. The 'cheap' ones were a Mac II + TI microexplorer or the Mac II + MacIvory. But developer workstations were always expensive - Lispm or not - or underpowered. What was also expensive was the software. I got a KEE license on a used machine I was given. I think it cost $50k. Similar Symbolics extensions for their OS could be extremely expensive. The graphics suite did cost several 10k per module (paint, model, render, tools, ...). > a system that was so much designed for programmers was probably never going to command a very big market Well, they could not live from developers alone. They were also looking for end users. Some of the machines were thought as delivery machines, cheaper and with less resources. There were also tools like 'firewall', which were supposed to keep users from getting in contact with the development environment (like debugger, ...). Actually Symbolics also targeted high-end endusers, both with hardware and with software. They had to go beyond government developers - to be able to sell machines/software. There were applications that were kind of development centric, like the iCAD cad system - where one could program 3d models via Flavors extensions. But one huge area for Symbolics was the graphics market. 2d, 2.5d animation, 3d animation, paint/model/render. Much of that was used without programming. The graphics suite was mostly targeted at graphics professionals, often doing 3d visualizations for TV, cinema and games. Many TV stations had their logos animated on Symbolics machines. https://www.youtube.com/watch?v=V4HXPJtym2Q https://www.youtube.com/watch?v=V4HXPJtym2Q https://www.youtube.com/watch?v=V4HXPJtym2Q https://www.youtube.com/watch?v=V4HXPJtym2Q https://www.youtube.com/watch?v=f4Lo0IfUSPk https://www.youtube.com/watch?v=f4Lo0IfUSPk Early: http://lispm.de/symbolics-3/symbolics-3.html http://lispm.de/symbolics-3/symbolics-3.html Later high-end hardware/software for accelerated graphics: http://lispm.de/symbolics-1/symbolics-1.html http://lispm.de/symbolics-1/symbolics-1.html Thus the UI had to be usable for non-programmers doing graphics work. https://www.youtube.com/watch?v=gV5obrYaogU https://www.youtube.com/watch?v=gV5obrYaogU

jff 10y ago

Lisp machines were expensive, the early ones at least took a very long time to boot, and I think there are weaknesses to the Lisp "image"/"world"/whatever model that Lisp-M partisans aren't quite willing to acknowledge. They're still extraordinarily cool machines.

throwanem 10y ago
> there are weaknesses to the Lisp "image"/"world"/whatever model that Lisp-M partisans aren't quite willing to acknowledge I'd be interested to hear this expanded upon.
- mikelevins 10y ago
  Old-fashioned Lisp and Smalltalk systems presented a programming model in which the language process is your running program, but it doesn't yet know how to do the right thing. Your job is to interactively teach it how to be your application. This you do by teaching it one little piece at a time until it is transformed into the application you want. This process is facilitated by the ability to at any point save the state of the process for later resumption. These saved states are called "heaps" or "images" or "worlds". Start up one of them and you are more or less instantly returned to the last state you were in when the process was last running. LispMs extended this model to the entire machine. There are advantages and disadvantages. The advantages are legion, and they can enormously accelerate development in the hands of someone comfortable with that mode of working. There are two main types of disadvantage. One is that, since you are interactively modifying a live, running system, if you make a mistake, the mistake becomes part of the running system. If you save the image with that mistake in it, it becomes part of the system in future sessions, too. The second problem is that it becomes troublesome to separate your application from the scaffolding that you've used to build it. To take a very simple example, suppose you construct a few simple data structures for testing purposes. Those test structures then become part of the running system, and there is a risk that your application will inadvertently come to depend on their values, leading to obscure bugs if they change or if the application is deployed without them. There are reasonably straightforward ways to deal with both classes of problem, and properly-designed Lisp and Smalltalk systems include tools that help solve these problems, but it's appropriate to acknowledge them as problems. I like old-fashioned Lisp and Smalltalk systems, and I like image-based development. I prefer the programming model in which I am teaching the process to be my application, and I'm much more productive in such an environment than in the now more-mainstream, model where programming is more like building something from a blueprint than it is like teaching something to behave the way I want. But that doesn't mean I don't acknowledge the problems of image-based development. They exist. They are solvable, but they do exist.
lispm 10y ago
> very long time to boot Actually a typical Symbolics 3600 didn't boot much longer than a SUN... my NXP1000 Lisp Machine boots in three minutes from a very large image.
- convolvatron 10y ago
  i'm not trying to be fussy, but we would boot the 3670 overnight when the GC stopped being able to catch up with itself. because as i recall it took a couple hours
  - lispm 10y ago
    A full GC could take easily take half an hour on a machine with large virtual memory. Booting then was much faster.

mikelevins 10y ago

They were expensive. Sun workstations that cost five figures were cheap compared to LispMs. Their UI was powerful and efficient, but not easy to learn. They were designed by programmers for programmers. Their UI assumed that you were willing to invest nontrivial time and effort learning a broad palette of specialized tools. Their system design made some pretty different assumptions about how they were going to be used, and the environment they would be used in. For example, LispMs didn't have any kind of security or memory protection. They were wide open systems.

lispm 10y ago
If you would have wanted a comparable Lisp experience on a SUN workstation (large bitmap screen, large disk, software, ...) the actual price difference wasn't that much. But there were a lot of underpowered and slow SUNS, which were cheaper. But then you would better not use Allegro CL, Lucid CL or LispWorks on those. 16 or even 24 MB RAM were simply not enough and GC was fighting with the virtual memory pager... The big cost driver at that time was memory and peripherals like disks. The lab I worked for had slow SUN SPARCs. The idea was that you would net boot them and they would get their software from a main server. Relatively cheap. But it turned out a bit slow and clunky. People then often used their office Macs for software development, with Macintosh Common Lisp.
- mikelevins 10y ago
  True, but the point is that there weren't any really cheap LispMs until it was too late to matter. Besides which, a system that was so much designed for programmers was probably never going to command a very big market.
  - lispm 10y ago
    There was never a really cheap Lispm. The 'cheap' ones were a Mac II + TI microexplorer or the Mac II + MacIvory. But developer workstations were always expensive - Lispm or not - or underpowered. What was also expensive was the software. I got a KEE license on a used machine I was given. I think it cost $50k. Similar Symbolics extensions for their OS could be extremely expensive. The graphics suite did cost several 10k per module (paint, model, render, tools, ...). > a system that was so much designed for programmers was probably never going to command a very big market Well, they could not live from developers alone. They were also looking for end users. Some of the machines were thought as delivery machines, cheaper and with less resources. There were also tools like 'firewall', which were supposed to keep users from getting in contact with the development environment (like debugger, ...). Actually Symbolics also targeted high-end endusers, both with hardware and with software. They had to go beyond government developers - to be able to sell machines/software. There were applications that were kind of development centric, like the iCAD cad system - where one could program 3d models via Flavors extensions. But one huge area for Symbolics was the graphics market. 2d, 2.5d animation, 3d animation, paint/model/render. Much of that was used without programming. The graphics suite was mostly targeted at graphics professionals, often doing 3d visualizations for TV, cinema and games. Many TV stations had their logos animated on Symbolics machines. https://www.youtube.com/watch?v=V4HXPJtym2Q https://www.youtube.com/watch?v=V4HXPJtym2Q https://www.youtube.com/watch?v=V4HXPJtym2Q https://www.youtube.com/watch?v=V4HXPJtym2Q https://www.youtube.com/watch?v=f4Lo0IfUSPk https://www.youtube.com/watch?v=f4Lo0IfUSPk Early: http://lispm.de/symbolics-3/symbolics-3.html http://lispm.de/symbolics-3/symbolics-3.html Later high-end hardware/software for accelerated graphics: http://lispm.de/symbolics-1/symbolics-1.html http://lispm.de/symbolics-1/symbolics-1.html Thus the UI had to be usable for non-programmers doing graphics work. https://www.youtube.com/watch?v=gV5obrYaogU https://www.youtube.com/watch?v=gV5obrYaogU