3 ms·

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

by 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.

by jff 10y ago

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.