Lisp 1.6 from the IBM 1130
ibm1130.org
ibm1130.org
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.
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.
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!
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://support.ircam.fr/docs/om/om6-manual/co/Microintervals...
Save that into C:\AMEM.TXT!
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.
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.
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.
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.
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.
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.
I am reaching my 40's and back on the university we had lots of books and papers since the early days of computing. Given my interest in compiler development, I just devoured everything I could get my hands on.
So although I started coding around 1986, I managed to get hold of lots of information.