Hacker News Reader

Comment by AlexanderDhoore | Hacker News Reader

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.

View on HN

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

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.

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.

I think one needs to be curious for knowledge.

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.

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!

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.

"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://support.ircam.fr/docs/om/om6-manual/co/Microintervals...

> 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!

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

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.

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.

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.

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.

Reply on news.ycombinator.com