6 ms·

All ideas are old ideas

76 points by llambda 14y ago

charlieflowers 14y ago
This really got me thinking about the ideas that we can mine from old, neglected systems that lost the marketing battles and are simply considered obsolete now.
- ChuckMcM 14y ago
  So one of the things I've been working on in my 'spare' time is a simple training computer. One of the things I have been very careful to do is document what sources of information and inspiration I'm using in that design/implementation (all pre-1992) in order to insure that should someone try to throw a patent troll lawsuit at it I would be well equipped to defend. Sad really.
zaptheimpaler 14y ago
chris - In the 8/17 post you said there would be a big announcement coming up soon. Any updates on that? I think there was some speculation that it would be Python support - that would be awesome!
kemiller 14y ago
Something I've always wondered is how image-oriented languages like smalltalk handle deployment, version management, etc. How do you make a frozen, repeatable bundle? I realize that may be the wrong question, that those things are irrelevant, but if so, why are they irrelevant? What is it about those environments that compensates?
- pnathan 14y ago
  one way to do it is to load the entire system into the image and actually just straight up deploy the image as an executable.
  - kemiller 14y ago
    I guess I don't understand where the line between code and data lies, then. Is there a store for variable data that is separate from the image? EDIT: To clarify, I know that Lisp and Smalltalk have a fuzzy-to-nonexistent line between code and data. What I want to know is how you'd manage that in practice. If I'm changing an existing piece of software, I don't want to expose production users to its incomplete state, so I can't change the running production site directly. (Right?) But if I'm developing locally, or even in a staging version, I don't want to transfer my test/sample data. Maybe a better question is, "What is a typical workflow like for modifying production software?"
    - pnathan 14y ago
      I'm not sure there's a line between the two. To quote an old lisp saying, code is data is code. If I want to do an image deploy, what I'll do is load the libraries into the image as part of the build, set up a 'main' function that the executable will trigger, then main will read any config files and go. This image will be an actual executable for the OS. The receiver will execute the executable and not know the difference. edit: In terms of version control, each deploy to production would generate a tag.
    - tomjen3 14y ago
      In languages like Smalltalk and Lisp, there often is no difference between code and data. The famous Lisp parenthesis exist exactly because your source code is both code and data (specifically, nested lists). Though if you were making a program that should be deployed at the end user you would properly make it read and write files or communicate with a server over the internet and obviously that kind of data cannot be put into the image.
    - gphil 14y ago
      I think the idea is that the code and data are dealt with and versioned in the same way (a common saying about Lisp code is that the "code is data.") I haven't actually used any of the environments mentioned in the article, but I believe that the code, as well as the entire state of the running program, can be snapshotted and versioned in these environments.
- ken 14y ago
  Just because you have a feature, doesn't mean you have to use the feature. When I did it, I just started a fresh image and loaded all my new code (checked out from the repository) into it. Or sometimes I probably just used the existing image. I don't remember. Unless your code depends on something being not defined, or you deleted a lot of old code, it wouldn't really make any difference. If I ever had a lot of code, I could have built the image offline (though Lisp compilers are pretty fast). If I had a lot of code to build and database migrations to handle on a live database, it could have gotten hairy. I guess that's just the price I would have had to pay for the added flexibility of being able to build my image offline. IME, complex database migrations in production can get hairy on any language/platform. It's not really that much different from Python or Ruby, is it? They have a "repl" and an "image", except they're much weaker and not formally defined, or portable, or able to be saved or loaded, or anything like that. But if Python 4 was released today and Guido said "there's now functions to load and save images!", it's not like every Python deployment in the world would stop working. Everyone would have a new mechanism they could use, or not, as they liked, but it wouldn't affect their existing procedures.
- billsix 14y ago
  Originally they used change sets. That didn't scale particularly well. Monticello is a distributed versioning system that was later developed for Squeak smalltalk. http://wiresong.ca/monticello/ http://wiresong.ca/monticello/ . The Cuis project, a fork from squeak, imports/exports projects from your filesystem, regardless of whatever external VCS you use. http://www.jvuletich.org/Cuis/Index.html http://www.jvuletich.org/Cuis/Index.html
  - deleted 14y ago
    [deleted]
pnathan 14y ago
I am very glad to see the Light Table team taking a hard look at the 70s & 80s work. It's very... heartening. Personally, I am wondering when light-table mode for emacs/common lisp will come out. :-)
- bitdiddle 14y ago
  talk about blast from the past, I spent a few years looking at a Symbolics machine, though I rarely saw that Genera login, the machine stayed up for days on end. light-table mode for emacs/common lisp would be neat. As a schemer I think what would be really awesome is to see light-table merged with the emacs/guile/geiser work. Geiser is also trying to resurrect the lisp machine.
btilly 14y ago
The problem with having your code all in a software image is that the second you do this you lose a large existing toolset that people have invested a lot in mastering. Just think of everything that you know how to do which involves a filesystem. I regularly use editors, grep -r, cd, edit in one directory and run unit tests in another, revision control systems, etc. People have invested a lot of energy into these tools, and have strong opinions about which ones they prefer and why. (Perhaps you prefer an integrated IDE. Doesn't matter, my point remains.) As soon as you move to an image based system, your entire toolset no longer works within the inside of that image. It is, of course, a programmatic environment and replacements for every filesystem manipulation you are familiar with are available. Sometimes those replacements are better (though better is often just in the eye of the beholder). But they are guaranteed to be different. And as you move from one image based language (say, a Lisp dialect) to another (eg Smalltalk), they will be different again. By contrast if you move from one filesystem based language to another, you will still have a learning curve, but there is a large toolset that you do not have to relearn.
- ibdknox 14y ago
  Just to be clear, I'm not advocating giving up the filesystem :) I wholeheartedly agree that too much work has been done there to just forsake the toolchain, but that doesn't mean you can't creatively compromise to get the best of both worlds. Exactly how that will play out will be really interesting to see I think. We've been working on some big changes to the architecture of Light Table that should set us up for figuring that out in the future. A blog post is probably coming next week about some of that.
- groby_b 14y ago
  "The problem with driving a car is that you lose almost all the skills you obtained by driving a horse carriage". Yes, the image interop part is a bit more difficult to solve. I'm not saying it's exactly like the switch from carriage to car, but I'm saying that some changes are worth losing existing skills
  - btilly 14y ago
    Consider that image-based environments have been losing ground to file-system based ones for years. Consider also that core ideas that make image-based environments good can be separated from the image-based system and moved into non-image based systems. Two examples that I would give for Smalltalk are Ruby's borrowing of Smalltalks OO model, and various IDEs borrowing the idea of a refactoring browser. Borrowing the other way is much harder. For instance consider the distributed version control patterns that git enables. Image-based software development communities are sufficiently small and fragmented that they are unlikely to all duplicate the functionality of git. And because of the internal differences, they each would have to reinvent it. By contrast once git became available, it was immediately available for use with C++, Java, Python, JavaScript, Haskell... There are advantages to image-based environments, but do they outweigh the disadvantages? Before concluding that they do, you might want to re-read Worse Is Better.
hermanhermitage 14y ago
It's great to see Chris write this up. It's always refreshing to see someone explore the work of those who have had similar concerns or solved similar problems. Whether they have independently chosen a similar direction or are standing on the shoulders. Provides a good reference for new comers wanting to understand what approaches have been explored before. We live in exciting times. The confusion of (programming) tongues is in full swing; the CPU clock wall is with us; high level features such as closures and GC now have fairly efficient implementations - it seems there are now enough transistors to deliver much of the abstraction that was envisioned by the founders but gave way to pragmatic concerns in the early microcomputer era. I am looking forward to IDEs that manage and simplify complexity, and hardware ISAs that throw a few more transistors at things like STM, tagged data and memory management. I can see a future where I can edit code in a language foreign to me, but see an instant side-by-side (editable) version in a dialect I'm more comfortable with. Switch in another view and drag and drop states in my state machine via direct manipulation, and so forth.
pyrotechnick 14y ago
What has been will be again, what has been done will be done again; there is nothing new under the sun.
- GlennS 14y ago
  Except, you know, computers...
6ren 14y ago
[please refute, not just downvote] Just because something can be done doesn't mean it should be done (maybe it should be done, but for some other reason). I'm suggesting that barriers to modifying systems have had an accidental benefit of favouring standardization. The basic problem is that it's hard to create systems (APIs, generalization, documentation, test-cases, integration with everything else). Brooks claims it's 9 times as much effort as making something that "works for me". If you can't amortise that over many users, it's usually not worth doing the job properly. But if it's just for you, you don't need all that polish, right? Well, no. If you are standing on the shoulders of giants, it's really helpful if those giants are stable, function as you expect, interact correctly with other tools, and have clear documentation for when you've forgotten the details (writing it yourself doesn't make your memory perfect). SOTSOG is really important for building complex systems, because it enables you to push down details to a lower level of abstraction, so you have less clutter to deal with. It's getting the abstractions right that is so difficult (we've all seen it done wrong). There are huge advantages to using standardized systems, that have been improved, tested, documented etc by others. If you want to do something different, it's very helpful if you can start with standardized components around the new part, so you can just concentrate on the interesting stuff, and not need to build the whole world from scratch. Of course, the existing stuff is not perfect - the question is whether it's worth it for you to spend the time needed to make something better. Some issues in assessing this argument: These are ideas have been around for a long time, but haven't taken off. Highly modifiable systems like lisp, despite having clever and devoted users, lack the standardized libraries of less flexible languages like Java. But there is one kind of area where such systems are absolutely brilliant - exploration at the systems level. Many (most?) programming language ideas have been developed in lisp, even though did not become popular in that form, because lisp is great for language exploration, but not for standardization. Similarly, an OS that can be modified on the fly, is great for exploring OS ideas. You can iterate quickly, see the results and so on. Of course, it seems possible that one could have it both ways - a highly flexible system that also had standardized components. But that doesn't seem to happen. Flexibility and standardization are natural enemies, both in differences in the tools that support them... and the kinds of people who use those tools. BTW: There's a middle way. Create tools that can be standardized on. i.e. libraries, frameworks, engines, DSLs. Light table could be perfect for that... but people who use it may want to make tools that are just as flexible as light table, and so don't support standardization.
mark_l_watson 14y ago
I had a Xerox 1108 Lisp Machine from 1982 to about 1987 (and for one month, I ran Smalltalk on it rather than Lisp). Yes, it was awesome compared to using a timeshared VAX (or whatever), but as fantastic as my 1108 was for its time and no matter how much I loved it at the time, I like my development environments today a lot more. Examples: development and debugging of both server side and client side code (GWT on client, something REST full on the server side) with IntelliJ Java debuggers open on both client and server code - hopefully you may only need this once a month but useful when you need it. Repl based development with a smart IDE (like Clojure in IntelliJ or Ruby in RubyMine). Interactive Scala worksheets in the Eclipse/ScalaIDE (sort of like Chris's Light Table). In addition to a lot of NLP work on my 1108, I was also just getting into neural networks back then and my NN simulations ran like mollasses on the 1108. Any of my laptops are many orders of magnitude faster for just about anything I do than my 1108.

76 points by llambda 14y ago

This really got me thinking about the ideas that we can mine from old, neglected systems that lost the marketing battles and are simply considered obsolete now.

ChuckMcM 14y ago
So one of the things I've been working on in my 'spare' time is a simple training computer. One of the things I have been very careful to do is document what sources of information and inspiration I'm using in that design/implementation (all pre-1992) in order to insure that should someone try to throw a patent troll lawsuit at it I would be well equipped to defend. Sad really.

zaptheimpaler 14y ago

chris - In the 8/17 post you said there would be a big announcement coming up soon. Any updates on that? I think there was some speculation that it would be Python support - that would be awesome!

kemiller 14y ago

Something I've always wondered is how image-oriented languages like smalltalk handle deployment, version management, etc. How do you make a frozen, repeatable bundle? I realize that may be the wrong question, that those things are irrelevant, but if so, why are they irrelevant? What is it about those environments that compensates?

pnathan 14y ago
one way to do it is to load the entire system into the image and actually just straight up deploy the image as an executable.
- kemiller 14y ago
  I guess I don't understand where the line between code and data lies, then. Is there a store for variable data that is separate from the image? EDIT: To clarify, I know that Lisp and Smalltalk have a fuzzy-to-nonexistent line between code and data. What I want to know is how you'd manage that in practice. If I'm changing an existing piece of software, I don't want to expose production users to its incomplete state, so I can't change the running production site directly. (Right?) But if I'm developing locally, or even in a staging version, I don't want to transfer my test/sample data. Maybe a better question is, "What is a typical workflow like for modifying production software?"
  - pnathan 14y ago
    I'm not sure there's a line between the two. To quote an old lisp saying, code is data is code. If I want to do an image deploy, what I'll do is load the libraries into the image as part of the build, set up a 'main' function that the executable will trigger, then main will read any config files and go. This image will be an actual executable for the OS. The receiver will execute the executable and not know the difference. edit: In terms of version control, each deploy to production would generate a tag.
  - tomjen3 14y ago
    In languages like Smalltalk and Lisp, there often is no difference between code and data. The famous Lisp parenthesis exist exactly because your source code is both code and data (specifically, nested lists). Though if you were making a program that should be deployed at the end user you would properly make it read and write files or communicate with a server over the internet and obviously that kind of data cannot be put into the image.
  - gphil 14y ago
    I think the idea is that the code and data are dealt with and versioned in the same way (a common saying about Lisp code is that the "code is data.") I haven't actually used any of the environments mentioned in the article, but I believe that the code, as well as the entire state of the running program, can be snapshotted and versioned in these environments.
ken 14y ago
Just because you have a feature, doesn't mean you have to use the feature. When I did it, I just started a fresh image and loaded all my new code (checked out from the repository) into it. Or sometimes I probably just used the existing image. I don't remember. Unless your code depends on something being not defined, or you deleted a lot of old code, it wouldn't really make any difference. If I ever had a lot of code, I could have built the image offline (though Lisp compilers are pretty fast). If I had a lot of code to build and database migrations to handle on a live database, it could have gotten hairy. I guess that's just the price I would have had to pay for the added flexibility of being able to build my image offline. IME, complex database migrations in production can get hairy on any language/platform. It's not really that much different from Python or Ruby, is it? They have a "repl" and an "image", except they're much weaker and not formally defined, or portable, or able to be saved or loaded, or anything like that. But if Python 4 was released today and Guido said "there's now functions to load and save images!", it's not like every Python deployment in the world would stop working. Everyone would have a new mechanism they could use, or not, as they liked, but it wouldn't affect their existing procedures.
billsix 14y ago
Originally they used change sets. That didn't scale particularly well. Monticello is a distributed versioning system that was later developed for Squeak smalltalk. http://wiresong.ca/monticello/ http://wiresong.ca/monticello/ . The Cuis project, a fork from squeak, imports/exports projects from your filesystem, regardless of whatever external VCS you use. http://www.jvuletich.org/Cuis/Index.html http://www.jvuletich.org/Cuis/Index.html
- deleted 14y ago
  [deleted]

pnathan 14y ago

I am very glad to see the Light Table team taking a hard look at the 70s & 80s work. It's very... heartening. Personally, I am wondering when light-table mode for emacs/common lisp will come out. :-)

bitdiddle 14y ago
talk about blast from the past, I spent a few years looking at a Symbolics machine, though I rarely saw that Genera login, the machine stayed up for days on end. light-table mode for emacs/common lisp would be neat. As a schemer I think what would be really awesome is to see light-table merged with the emacs/guile/geiser work. Geiser is also trying to resurrect the lisp machine.

btilly 14y ago

The problem with having your code all in a software image is that the second you do this you lose a large existing toolset that people have invested a lot in mastering. Just think of everything that you know how to do which involves a filesystem. I regularly use editors, grep -r, cd, edit in one directory and run unit tests in another, revision control systems, etc. People have invested a lot of energy into these tools, and have strong opinions about which ones they prefer and why. (Perhaps you prefer an integrated IDE. Doesn't matter, my point remains.) As soon as you move to an image based system, your entire toolset no longer works within the inside of that image. It is, of course, a programmatic environment and replacements for every filesystem manipulation you are familiar with are available. Sometimes those replacements are better (though better is often just in the eye of the beholder). But they are guaranteed to be different. And as you move from one image based language (say, a Lisp dialect) to another (eg Smalltalk), they will be different again. By contrast if you move from one filesystem based language to another, you will still have a learning curve, but there is a large toolset that you do not have to relearn.

ibdknox 14y ago
Just to be clear, I'm not advocating giving up the filesystem :) I wholeheartedly agree that too much work has been done there to just forsake the toolchain, but that doesn't mean you can't creatively compromise to get the best of both worlds. Exactly how that will play out will be really interesting to see I think. We've been working on some big changes to the architecture of Light Table that should set us up for figuring that out in the future. A blog post is probably coming next week about some of that.
groby_b 14y ago
"The problem with driving a car is that you lose almost all the skills you obtained by driving a horse carriage". Yes, the image interop part is a bit more difficult to solve. I'm not saying it's exactly like the switch from carriage to car, but I'm saying that some changes are worth losing existing skills
- btilly 14y ago
  Consider that image-based environments have been losing ground to file-system based ones for years. Consider also that core ideas that make image-based environments good can be separated from the image-based system and moved into non-image based systems. Two examples that I would give for Smalltalk are Ruby's borrowing of Smalltalks OO model, and various IDEs borrowing the idea of a refactoring browser. Borrowing the other way is much harder. For instance consider the distributed version control patterns that git enables. Image-based software development communities are sufficiently small and fragmented that they are unlikely to all duplicate the functionality of git. And because of the internal differences, they each would have to reinvent it. By contrast once git became available, it was immediately available for use with C++, Java, Python, JavaScript, Haskell... There are advantages to image-based environments, but do they outweigh the disadvantages? Before concluding that they do, you might want to re-read Worse Is Better.

hermanhermitage 14y ago

It's great to see Chris write this up. It's always refreshing to see someone explore the work of those who have had similar concerns or solved similar problems. Whether they have independently chosen a similar direction or are standing on the shoulders. Provides a good reference for new comers wanting to understand what approaches have been explored before. We live in exciting times. The confusion of (programming) tongues is in full swing; the CPU clock wall is with us; high level features such as closures and GC now have fairly efficient implementations - it seems there are now enough transistors to deliver much of the abstraction that was envisioned by the founders but gave way to pragmatic concerns in the early microcomputer era. I am looking forward to IDEs that manage and simplify complexity, and hardware ISAs that throw a few more transistors at things like STM, tagged data and memory management. I can see a future where I can edit code in a language foreign to me, but see an instant side-by-side (editable) version in a dialect I'm more comfortable with. Switch in another view and drag and drop states in my state machine via direct manipulation, and so forth.

pyrotechnick 14y ago

What has been will be again, what has been done will be done again; there is nothing new under the sun.

GlennS 14y ago
Except, you know, computers...

6ren 14y ago

[please refute, not just downvote] Just because something can be done doesn't mean it should be done (maybe it should be done, but for some other reason). I'm suggesting that barriers to modifying systems have had an accidental benefit of favouring standardization. The basic problem is that it's hard to create systems (APIs, generalization, documentation, test-cases, integration with everything else). Brooks claims it's 9 times as much effort as making something that "works for me". If you can't amortise that over many users, it's usually not worth doing the job properly. But if it's just for you, you don't need all that polish, right? Well, no. If you are standing on the shoulders of giants, it's really helpful if those giants are stable, function as you expect, interact correctly with other tools, and have clear documentation for when you've forgotten the details (writing it yourself doesn't make your memory perfect). SOTSOG is really important for building complex systems, because it enables you to push down details to a lower level of abstraction, so you have less clutter to deal with. It's getting the abstractions right that is so difficult (we've all seen it done wrong). There are huge advantages to using standardized systems, that have been improved, tested, documented etc by others. If you want to do something different, it's very helpful if you can start with standardized components around the new part, so you can just concentrate on the interesting stuff, and not need to build the whole world from scratch. Of course, the existing stuff is not perfect - the question is whether it's worth it for you to spend the time needed to make something better. Some issues in assessing this argument: These are ideas have been around for a long time, but haven't taken off. Highly modifiable systems like lisp, despite having clever and devoted users, lack the standardized libraries of less flexible languages like Java. But there is one kind of area where such systems are absolutely brilliant - exploration at the systems level. Many (most?) programming language ideas have been developed in lisp, even though did not become popular in that form, because lisp is great for language exploration, but not for standardization. Similarly, an OS that can be modified on the fly, is great for exploring OS ideas. You can iterate quickly, see the results and so on. Of course, it seems possible that one could have it both ways - a highly flexible system that also had standardized components. But that doesn't seem to happen. Flexibility and standardization are natural enemies, both in differences in the tools that support them... and the kinds of people who use those tools. BTW: There's a middle way. Create tools that can be standardized on. i.e. libraries, frameworks, engines, DSLs. Light table could be perfect for that... but people who use it may want to make tools that are just as flexible as light table, and so don't support standardization.

mark_l_watson 14y ago

I had a Xerox 1108 Lisp Machine from 1982 to about 1987 (and for one month, I ran Smalltalk on it rather than Lisp). Yes, it was awesome compared to using a timeshared VAX (or whatever), but as fantastic as my 1108 was for its time and no matter how much I loved it at the time, I like my development environments today a lot more. Examples: development and debugging of both server side and client side code (GWT on client, something REST full on the server side) with IntelliJ Java debuggers open on both client and server code - hopefully you may only need this once a month but useful when you need it. Repl based development with a smart IDE (like Clojure in IntelliJ or Ruby in RubyMine). Interactive Scala worksheets in the Eclipse/ScalaIDE (sort of like Chris's Light Table). In addition to a lot of NLP work on my 1108, I was also just getting into neural networks back then and my NN simulations ran like mollasses on the 1108. Any of my laptops are many orders of magnitude faster for just about anything I do than my 1108.