5 ms·

Lisp 1.6 from the IBM 1130

59 points by BruceM 14y ago

BruceM 14y ago
I find this sort of software archeology fascinating. I wish there was a lot more of it ... I'd love to see runnable copies of T, EuLisp, Sk8, FramerD and so many other things. It often feels like we lose so much of our history.
- AlexanderDhoore 14y ago
  I'm in college, and I think they should teach us some computer/software history. In every other science (not that CS is a science) they teach people by telling them the stories of history. In chemistry, physics they go over all great discoveries and explain what/who/how. Then students understand how thing got to the way they are. And that gives them a vision for the future. In our field, we just say: "What we have now is the best, because everything gets better all the time. Therefore old technology is not interesting." The most intesting stuff I learn when I'm researching history.
  - BruceM 14y ago
    I (obviously) agree wholeheartedly. It is worth pointing out that sometimes historical software is used for instruction, like Unix v6, but that doesn't seem to be common. A gating factor here is that much of the time, old software doesn't run, isn't available in source form, the old hardware is long gone and there aren't emulators, etc. We also probably over-glorify some things from the past. :) Making the Texas Persistent Store build again is a bit of a chore as it is C++ from 1994 and things have changed a good bit. But even things that last had a release in the last decade don't build any longer (like framerd). Much less something like SHRDLU which was written in MacLisp and ran on ITS!
    - noblethrasher 14y ago
      I think AlexanderDhoore is interested in learning the history of computer science the same way you learn the history of everything else: by studying primary sources.
  - keithpeter 14y ago
    "What we have now is the best, because everything gets better all the time. Therefore old technology is not interesting." Not so sure we do (non-expert here). I suspect certain choices were made in the past, often as a result of hardware limitations, which have now become too hard to change. The only examples I can come up with right now are music related; midi encoding implies a discrete pitch class system with semitone spacing. Work-rounds are needed for micro-pitches. CD format reflects the limitations of video tape in the early digital recording era. http://en.wikipedia.org/wiki/44,100_Hz http://en.wikipedia.org/wiki/44,100_Hz http://support.ircam.fr/docs/om/om6-manual/co/Microintervals.html http://support.ircam.fr/docs/om/om6-manual/co/Microintervals...
    - rbanffy 14y ago
      > I suspect certain choices were made in the past, often as a result of hardware limitations, which have now become too hard to change. Save that into C:\AMEM.TXT!
  - flyinRyan 14y ago
    I think this is because CS in most universities is just training you to go grind in IT. It's not a proper education like the other fields anymore.
  - omaranto 14y ago
    They often don't go into historical details in math, either. So CS is not alone and may in fact inherit this ahistoricalness from math.
    - noblethrasher 14y ago
      My math program offered a (difficult) upper division History of Math course at least. But to your point, I'd categorize undergraduate mathematics as being atemporal rather than ahistorical. On the other hand, computer science programs (at least of the so-called "Java School" variety) seem to have an antipathy for the past rather than a mere disinterest.
  - rbanffy 14y ago
    > The most intesting stuff I learn when I'm researching history. To say nothing about cringing when someone makes the same design mistake someone else made in the 50's ;-) Even worse: thanks to better hardware, they get away with it this time.
    - VLM 14y ago
      The IT version of the Tacoma Narrows bridge happens every time a project fails, usually for a reason similar if not identical to zillions of other failures in the last 50 or so years. If we as a group admitted that past failures could be avoided by proper engineering, that would open us all as a group to malpractice suits or the equivalent. This willful and intentional ignorance of history is the IT equivalent of what cops call the "blue code of silence" or the "blue wall". See the first part of Brooks and his silver bullet. So knowing why things failed in the past is a secret sauce that tells you as an individual how to avoid failure in the future that others will not know how to avoid, HOWEVER as a group "we" cannot have that knowledge without a pretty big paradigm shift probably involving lots of legal unpleasantness. This is an interesting analogy to scalability issues when growing a startup. One dude can admit his strategy needs changing pretty quickly, but a bureaucracy cannot change quickly if at all.
  - VLM 14y ago
    "Then students understand how thing got to the way they are. And that gives them a vision for the future." Maybe its intentionally avoided because it could be very depressing. My aunt knows all about virtualized server images and oversubscription issues and allocating networked storage appropriately to avoid thrashing and all the fun of moving images from one clustered machine to the other and dealing with images that make weird assumptions about being run natively rather than as an image, and backups of a large virtualized data center, and disaster recovery of virtualized data centers. Talking to her is just like talking to a 2013 vsphere admin. However she's not a 2013 vsphere admin, shes a retired mainframe VM op/sysprog from 40 years ago in the 70s. Nothing has changed since then other than some meaningless numbers and some trademarked marketing terms. Nothing is new in IT, and nothing EVER changes except trivia like numeric quantities and trademarked marketing terms. Not just the product lifecycle, but the concept lifecycle is very much like formulaic Hollywood movies. Once you know its a romantic comedy you know exactly whats going to happen, from the first marketing to the final announcement of unavailability.
    - pjmlp 14y ago
      The sad thing about it is that people keep on reinventing stuff and selling it to young developers. For example, Modula-2 and Turbo Pascal compilers were already having Go like compilation speed back in the mid 80s. Smalltalk and Lisp Machines environments offered features that current IDEs still don't quite achieve, while offering desktop operating systems fully coded in GC enabled languages. Oberon language family used for doing desktop operating systems in a GC enabled systems programming language, used for several years at Zurich Technical University. Distributed computing in the early 80s. And many other things.
      - BruceM 14y ago
        Can you blame them really? How do you run a Lisp Machine environment today? Or Oberon System 3 or v4 (I never tried anything later)? It is easy to reinvent and re-sell stuff when everything before is pretty much no longer available. I've had a few conversations lately with people who worked on some of this stuff. A lot of history is totally gone.
- deleted 14y ago
  [deleted]
rbanffy 14y ago
BTW, does anyone have documentation detailed enough to capture the fonts used in the 2250 (a vector display, but I assume the font was built-in rather than loaded from storage) and the 2260 (raster, generated at the terminal controller via a grid of magnetic cores)? I did something with the 3270 family [1], but I'd like to do more. 1- https://github.com/rbanffy/3270font https://github.com/rbanffy/3270font
- jaxb 14y ago
  FYI, there's a truetype font that replicates a VT220 -- http://sensi.org/~svo/glasstty/ http://sensi.org/~svo/glasstty/
  - rbanffy 14y ago
    I intentionally avoided the striped raster look. I didn't want to replicate the vintage IBM look, but rather imagine what a 3278 terminal would look if built with today's technology and 60's design.
abecedarius 14y ago
I smiled on seeing Steele was already THE GREAT QUUX. (In the user manual.) http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Audience/The%20Great%20Quux%20Poem%20Collection.html http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Au...
treerex 14y ago
It depresses me that GLS was a better programmer at 17 than I probably will ever be.

59 points by BruceM 14y ago

I find this sort of software archeology fascinating. I wish there was a lot more of it ... I'd love to see runnable copies of T, EuLisp, Sk8, FramerD and so many other things. It often feels like we lose so much of our history.

AlexanderDhoore 14y ago
I'm in college, and I think they should teach us some computer/software history. In every other science (not that CS is a science) they teach people by telling them the stories of history. In chemistry, physics they go over all great discoveries and explain what/who/how. Then students understand how thing got to the way they are. And that gives them a vision for the future. In our field, we just say: "What we have now is the best, because everything gets better all the time. Therefore old technology is not interesting." The most intesting stuff I learn when I'm researching history.
- BruceM 14y ago
  I (obviously) agree wholeheartedly. It is worth pointing out that sometimes historical software is used for instruction, like Unix v6, but that doesn't seem to be common. A gating factor here is that much of the time, old software doesn't run, isn't available in source form, the old hardware is long gone and there aren't emulators, etc. We also probably over-glorify some things from the past. :) Making the Texas Persistent Store build again is a bit of a chore as it is C++ from 1994 and things have changed a good bit. But even things that last had a release in the last decade don't build any longer (like framerd). Much less something like SHRDLU which was written in MacLisp and ran on ITS!
  - noblethrasher 14y ago
    I think AlexanderDhoore is interested in learning the history of computer science the same way you learn the history of everything else: by studying primary sources.
- keithpeter 14y ago
  "What we have now is the best, because everything gets better all the time. Therefore old technology is not interesting." Not so sure we do (non-expert here). I suspect certain choices were made in the past, often as a result of hardware limitations, which have now become too hard to change. The only examples I can come up with right now are music related; midi encoding implies a discrete pitch class system with semitone spacing. Work-rounds are needed for micro-pitches. CD format reflects the limitations of video tape in the early digital recording era. http://en.wikipedia.org/wiki/44,100_Hz http://en.wikipedia.org/wiki/44,100_Hz http://support.ircam.fr/docs/om/om6-manual/co/Microintervals.html http://support.ircam.fr/docs/om/om6-manual/co/Microintervals...
  - rbanffy 14y ago
    > I suspect certain choices were made in the past, often as a result of hardware limitations, which have now become too hard to change. Save that into C:\AMEM.TXT!
- flyinRyan 14y ago
  I think this is because CS in most universities is just training you to go grind in IT. It's not a proper education like the other fields anymore.
- omaranto 14y ago
  They often don't go into historical details in math, either. So CS is not alone and may in fact inherit this ahistoricalness from math.
  - noblethrasher 14y ago
    My math program offered a (difficult) upper division History of Math course at least. But to your point, I'd categorize undergraduate mathematics as being atemporal rather than ahistorical. On the other hand, computer science programs (at least of the so-called "Java School" variety) seem to have an antipathy for the past rather than a mere disinterest.
- rbanffy 14y ago
  > The most intesting stuff I learn when I'm researching history. To say nothing about cringing when someone makes the same design mistake someone else made in the 50's ;-) Even worse: thanks to better hardware, they get away with it this time.
  - VLM 14y ago
    The IT version of the Tacoma Narrows bridge happens every time a project fails, usually for a reason similar if not identical to zillions of other failures in the last 50 or so years. If we as a group admitted that past failures could be avoided by proper engineering, that would open us all as a group to malpractice suits or the equivalent. This willful and intentional ignorance of history is the IT equivalent of what cops call the "blue code of silence" or the "blue wall". See the first part of Brooks and his silver bullet. So knowing why things failed in the past is a secret sauce that tells you as an individual how to avoid failure in the future that others will not know how to avoid, HOWEVER as a group "we" cannot have that knowledge without a pretty big paradigm shift probably involving lots of legal unpleasantness. This is an interesting analogy to scalability issues when growing a startup. One dude can admit his strategy needs changing pretty quickly, but a bureaucracy cannot change quickly if at all.
- VLM 14y ago
  "Then students understand how thing got to the way they are. And that gives them a vision for the future." Maybe its intentionally avoided because it could be very depressing. My aunt knows all about virtualized server images and oversubscription issues and allocating networked storage appropriately to avoid thrashing and all the fun of moving images from one clustered machine to the other and dealing with images that make weird assumptions about being run natively rather than as an image, and backups of a large virtualized data center, and disaster recovery of virtualized data centers. Talking to her is just like talking to a 2013 vsphere admin. However she's not a 2013 vsphere admin, shes a retired mainframe VM op/sysprog from 40 years ago in the 70s. Nothing has changed since then other than some meaningless numbers and some trademarked marketing terms. Nothing is new in IT, and nothing EVER changes except trivia like numeric quantities and trademarked marketing terms. Not just the product lifecycle, but the concept lifecycle is very much like formulaic Hollywood movies. Once you know its a romantic comedy you know exactly whats going to happen, from the first marketing to the final announcement of unavailability.
  - pjmlp 14y ago
    The sad thing about it is that people keep on reinventing stuff and selling it to young developers. For example, Modula-2 and Turbo Pascal compilers were already having Go like compilation speed back in the mid 80s. Smalltalk and Lisp Machines environments offered features that current IDEs still don't quite achieve, while offering desktop operating systems fully coded in GC enabled languages. Oberon language family used for doing desktop operating systems in a GC enabled systems programming language, used for several years at Zurich Technical University. Distributed computing in the early 80s. And many other things.
    - BruceM 14y ago
      Can you blame them really? How do you run a Lisp Machine environment today? Or Oberon System 3 or v4 (I never tried anything later)? It is easy to reinvent and re-sell stuff when everything before is pretty much no longer available. I've had a few conversations lately with people who worked on some of this stuff. A lot of history is totally gone.
deleted 14y ago
[deleted]

rbanffy 14y ago

BTW, does anyone have documentation detailed enough to capture the fonts used in the 2250 (a vector display, but I assume the font was built-in rather than loaded from storage) and the 2260 (raster, generated at the terminal controller via a grid of magnetic cores)? I did something with the 3270 family [1], but I'd like to do more. 1- https://github.com/rbanffy/3270font https://github.com/rbanffy/3270font

jaxb 14y ago
FYI, there's a truetype font that replicates a VT220 -- http://sensi.org/~svo/glasstty/ http://sensi.org/~svo/glasstty/
- rbanffy 14y ago
  I intentionally avoided the striped raster look. I didn't want to replicate the vintage IBM look, but rather imagine what a 3278 terminal would look if built with today's technology and 60's design.

abecedarius 14y ago

I smiled on seeing Steele was already THE GREAT QUUX. (In the user manual.) http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Audience/The%20Great%20Quux%20Poem%20Collection.html http://www.csd.uwo.ca/staff/magi/personal/humour/Computer_Au...

treerex 14y ago

It depresses me that GLS was a better programmer at 17 than I probably will ever be.