2 ms·

"The NYT article talks about computer-supported work in general. I will explain how the Symbolics Lisp environment made the software developer more productive.

"The NYT article talks about computer-supported work in general. I will explain how the Symbolics Lisp environment made the software developer more productive. The Symbolics Lisp Machine was a high-tech solution. There are also useful lower-tech solutions. Many Lisp programmers like the relative 'simplicity' of just an Emacs window with a 'slave' Lisp process (say, SLIME + Emacs). Some of these developers are using just a terminal and Emacs. It gives them an integrated environment that is both simple and effective. The Symbolics Lisp Machine environment is more complex. It has been designed to support the development of novel and complex software, especially AI software. The whole point was to make an individual or a small group very productive and let them manage high complexity. Artificial Intelligence software often was very complex (Cyc is an example for that)." Somehow whenever Lisp is the topic we end up with writing like the above, hand-waving about some mysterious properties of Lisp that will bring us to programmer Nirvana. It seems modern workstations have similar features as the described system, with much higher bloat, which certainly makes it impressive for its time. I wish the article could have put more weight on the modern context and tone down the propaganda a bit.

gumby 9y ago
It's not just Lisp, it's the lispm. This was true of Interlip-D as well (the PARC lisp environment that ran on the Dandelion (AKA Star) as well as other D machines. It had two factors: 1 - Lisp is a dynamic language -- even compiled code can be modified and supersceded. This makes rapid prototyping really easy; it makes exploratory programming really easy, and it makes it easy to incrementally provide core improvements. 2 - As the entire system is in Lisp ("it's Lisp all the way down") there are no barriers (technical nor conceptual) between user code and system code. When I was developing Cyc I make the frame datastructures (Units and Slots in the parlance) first class objects that behaved exactly as if they were part of the base system distribution. They looked like a fundamendal datastructure just like conses, arrays, integers etc, which means people could rite code using them in ways I hadn't anticipated. Coupled with the introspective nature of Lisp you could easily write patches or new functionality that took advantage of what was on the system. And the debugger was always running, so instead of a core dump you could poke around and see what happened with all the dynamic data intact. (In the D-Machine case, on the project I worked on at PARC we actually added some instructions (wrote microcode) to the machine for this purpose). Now, let's compare this (good and bad) with the state of the art today: We definitely have dynamic languages heavily inflected by this work: C++ classes can be indistinguishable from built-in ones, and the entire STL can be written in C++. Clojure, js, etc are mainstream dynamic languages. But what we still have gain mismatches at interfaces: calling into the kernel is expensive; you have a cost in performance and functionality when interfacing between languages (e.g. a lot of boxing/unboxing when you interface C++ to Python, for example) and the build and development tools are typically disjoint from the program under development, which means the code and tool can't introspect about their relationship with each other. On the other hand, a Pascal or C program on an MIT-style Lispm (Symbolics/LMI/TI) had the same calling conventions and datatypes as a Lisp program and could intercall freely and be debugged clearly. And people are less interested in that these days: the dominant mode of programming is to assemble large numbers of black boxes and hope that they work. That gives me the heebie-jeebies, but perhaps that's just snobbery on my part: tons of useful systems are being built that way, and by a much larger set of people than used to be considered programmers. There were downsides of course, many of which are the reason these kinds of architectures no longer exist. The biggest one is the two-edged sword of the simplicity and complexity of Lisp: it's a very simple language with many sharp tools in the toolbox; a new user could very rapidly come up to speed, but most commonly a new user ended up developing a thick rope that they then proceeded to hang themselves with. It's a systems programming language and its very simplicity makes it too complex for most for application development. The same issue affects C++ today: it's an immensely powerful and expressive systems programming language but also a lot to get your hands around. Compare that to Go which explicitly tries to head in the opposite direction. Another "downside" is exploratory programming: I still use that approach but in terms of full disclosure: a good friend of mine denigrates it as "programming by successive approximation". I can see his point. And of course the lack of barriers would make applications quite vulnerable in today's security environment. It's still by far the most productive environment I've ever used, but I'm not sure it has a place in today's world.

gumby 9y ago

It's not just Lisp, it's the lispm. This was true of Interlip-D as well (the PARC lisp environment that ran on the Dandelion (AKA Star) as well as other D machines. It had two factors: 1 - Lisp is a dynamic language -- even compiled code can be modified and supersceded. This makes rapid prototyping really easy; it makes exploratory programming really easy, and it makes it easy to incrementally provide core improvements. 2 - As the entire system is in Lisp ("it's Lisp all the way down") there are no barriers (technical nor conceptual) between user code and system code. When I was developing Cyc I make the frame datastructures (Units and Slots in the parlance) first class objects that behaved exactly as if they were part of the base system distribution. They looked like a fundamendal datastructure just like conses, arrays, integers etc, which means people could rite code using them in ways I hadn't anticipated. Coupled with the introspective nature of Lisp you could easily write patches or new functionality that took advantage of what was on the system. And the debugger was always running, so instead of a core dump you could poke around and see what happened with all the dynamic data intact. (In the D-Machine case, on the project I worked on at PARC we actually added some instructions (wrote microcode) to the machine for this purpose). Now, let's compare this (good and bad) with the state of the art today: We definitely have dynamic languages heavily inflected by this work: C++ classes can be indistinguishable from built-in ones, and the entire STL can be written in C++. Clojure, js, etc are mainstream dynamic languages. But what we still have gain mismatches at interfaces: calling into the kernel is expensive; you have a cost in performance and functionality when interfacing between languages (e.g. a lot of boxing/unboxing when you interface C++ to Python, for example) and the build and development tools are typically disjoint from the program under development, which means the code and tool can't introspect about their relationship with each other. On the other hand, a Pascal or C program on an MIT-style Lispm (Symbolics/LMI/TI) had the same calling conventions and datatypes as a Lisp program and could intercall freely and be debugged clearly. And people are less interested in that these days: the dominant mode of programming is to assemble large numbers of black boxes and hope that they work. That gives me the heebie-jeebies, but perhaps that's just snobbery on my part: tons of useful systems are being built that way, and by a much larger set of people than used to be considered programmers. There were downsides of course, many of which are the reason these kinds of architectures no longer exist. The biggest one is the two-edged sword of the simplicity and complexity of Lisp: it's a very simple language with many sharp tools in the toolbox; a new user could very rapidly come up to speed, but most commonly a new user ended up developing a thick rope that they then proceeded to hang themselves with. It's a systems programming language and its very simplicity makes it too complex for most for application development. The same issue affects C++ today: it's an immensely powerful and expressive systems programming language but also a lot to get your hands around. Compare that to Go which explicitly tries to head in the opposite direction. Another "downside" is exploratory programming: I still use that approach but in terms of full disclosure: a good friend of mine denigrates it as "programming by successive approximation". I can see his point. And of course the lack of barriers would make applications quite vulnerable in today's security environment. It's still by far the most productive environment I've ever used, but I'm not sure it has a place in today's world.