Remember the Computer Science Past Or Be Condemned To Repeat It?

theodp writes "In the movie Groundhog Day, a weatherman finds himself living the same day over and over again. It's a tale to which software-designers-of-a-certain-age can relate. Like Philip Greenspun, who wrote in 1999, 'One of the most painful things in our culture is to watch other people repeat earlier mistakes. We're not fond of Bill Gates, but it still hurts to see Microsoft struggle with problems that IBM solved in the 1960s.' Or Dave Winer, who recently observed, 'We marvel that the runtime environment of the web browser can do things that we had working 25 years ago on the Mac.' And then there's Scott Locklin, who argues in a new essay that one of the problems with modern computer technology is that programmers don't learn from the great masters. 'There is such a thing as a Beethoven or Mozart of software design,' Locklin writes. 'Modern programmers seem more familiar with Lady Gaga. It's not just a matter of taste and an appreciation for genius. It's a matter of forgetting important things.' Hey, maybe it's hard to learn from computer history when people don't acknowledge the existence of someone old enough to have lived it, as panelists reportedly did at an event held by Mark Zuckerberg's FWD.us last Friday!"

Comments

It's not the programmers making the decisions

[cultiv8]

It's managers and executives who make the decisions, and to them whether it's a browser or mobile app or SaaS or whatever the latest trend is, who cares if you're reinventing the wheel as long as profits are up.

Re:It's not the programmers making the decisions

[fldsofglry]

Also in line with this: I can't imagine that way patents work actually help with the problem of inventing the wheel. You almost have to reinvent the wheel to create a working solution that won't get you sued.

Re:It's not the programmers making the decisions

[sjames]

Actually, it was Babbage who faced such idiocy from Parliament:

On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.

And you thought the clogged tubes thing was bad.

Re:It's not the programmers making the decisions

[TheRaven64]

There was a point made at the 30-year retrospective talk at last year's European Smalltalk conference. If you have two languages, one of which allows developers to be more efficient, then you will end up needing fewer developers for the same amount of work. Unless your entire company uses this language and never experiences mergers, then this group of developers will be outnumbered. When you begin a new project or merge two projects, management will typically decide to pick the language that more developers have experience with. If you have a team of 100 C++ programmers and another team of one SilverBulletLang programmers, then it seems obvious that you should pick C++ for your next project because you have vastly more experience within the company in using C++. The fact that the one SilverBulletLang programmer was more productive doesn't matter. In the real world, languages tend not to be silver bullets and so the productivity difference is more in the factor of two to five range, but that's still enough that the less-productive language wins.

Re:It's not the programmers making the decisions

[Xest]

That's such a cop out and it's not true. Most the managers making these decisions are technical managers who come from development backgrounds themselves.

There is a problem at a more fundamental level, even outside of determining what buzzwords to use for a product and it's prominent even in some of the higher echelons of web society. The most obvious I'm going to point out is that of HTML5 - it's a braindead spec full of utterly amateur mistakes that could've been avoided if only Ian Hickson had spent 5 seconds understanding why existing things were the way they were and why that mattered.

An obvious example is that of HTML5's semantic tags, using a study to determine a static set of tags that would be used to define semantic capabilities in a spec that was out of date before the ink had even dried was just plain stupid. The complaint that we needed more readable markup rather than div soup to make writing HTML was naive, firstly because amateurs just don't write HTML anymore, they all publish via Facebook, Wordpress and so forth, and secondly because there's a good reason markup had descended into div soup - because genericness is necessary for future-proofing. Divs don't care if they're ID is menu, or their class is comment, they're content neutral, they don't give a fuck what they are, but they'll be whatever you want them to be which means they're always fit for the future. In contrast HTML5 tried to replace divs with tags such as aside, header, footer and so forth which would be great except when you have a finite number of elements you end up with people arguing about what to do when an element doesn't fit. Do you just go back to using divs for that bit anyway or do you fudge one of the new tags in because it's kinda-loosely related which means you bastardise the semantics in the first place because we now don't really know what each semantic tag is referring to because it's been fudged in where it doesn't make a lot of sense?

The real solution was to provide a semantic definition language, the ability to apply semantics to classes and IDs externally. Does that concept sound familiar? It should because we had the exact same problem with applying designs to HTML in the past and created CSS. We allowed design to be separate from markup with external stylesheets because this had many benefits, a few obvious ones:

1) Designers could focus on CSS without getting in the way of those dealing with markup making development easier

2) We could provide external stylesheets for no longer maintained sites and have the browser apply them meaning there is a method to retrofit unmaintained sites with new features

3) Our markup is just markup, it just defines document structure, it does one thing and one thing well without being a complete mess of other concepts.

Consider that these could've been benefits for building a semantic web if HTML5 had been done properly too. The fact that Ian Hickson failed to recognise this with HTML5 highlights what the article is talking about exactly. He's completely and utterly failed to learn the lessons before him as to why inline styling was bad but on a more fundamental level demonstrates a failure to understand the importance of the concept of separation of concerns and the immense benefits that provides that was already learnt the hard way by those who came before him. His solution? Oh just make HTML5 a "living spec" - what? Specs are meant to be static for a reason, so that you can actually become compliant with them and remain compliant with them. Spec compliance once you've achieved it shouldn't ever be a moving target. That's when you know you need to release a new spec.

It's a worrying trend because it's not just him, I see it amongst the Javascript community as they grow in their ambition to make ever bigger software but insist that Javascript is all they need to do it. The horrendously ugly fudges they implement to try and fudge faux-namespaces into the language in a desperate attempt to alleviate the fact the Javascript was just neve

Re:It's not the programmers making the decisions

[captainClassLoader]

What I've seen in the 3 decades I've been in the industry is that the number of programmers using OldVanillaLang versus SilverBulletLang is less of an issue - Managers are often willing to go with a more resource-efficient solution, given that IT/MIS departments are often considered overhead on the bean counter spreadsheets. The thing that keeps managers on the OldVanillaLang track is the answers to the questions: "Supposed my SilverBulletLang guys leave - Who takes over their code? How do I evaluate SilverBulletLang developers in interviews? And since they're rare, can I afford them?"

A (very) recent OSCON talk

[zmughal]

John Graham-Cumming gave a talk at OSCON 2013 titled "Turing's Curse" that speaks to this same idea. Worth a watch.

We don't shun those who should be shunned.

[Anonymous Coward]

It's pretty damn obvious why this is: as an industry, we no longer shun those who should definitely be shunned.

Just look at all of the damn fedora-wearing Ruby on Rails hipster freaks we deal with these days. Whoa, you're 19, you dropped out of college, but you can throw together some HTML and some shitty Ruby and now you consider yourself an "engineer". That's bullshit, son. That's utter bullshit. These kids don't have a clue what they're doing.

In the 1970s and 1980s, when a lot of us got started in industry, a fool like that would've been filtered out long before he could even get a face-to-face interview with anyone at any software company. While there were indeed a lot of weird fuckers in industry back then, especially here in SV, they at least had some skill to offset their oddness. The Ruby youth of today have none of that. They're abnormal, yet they're also without any ability to do software development correctly.

Yeah, these Ruby youngsters should get the hell off all of our lawns. There's not even good money in fixing up the crap they've produced. They fuck up so badly and produce so much utter shit that the companies that hired them go under rather than trying to even fix it!

The moral of the story is to deal with skilled veteran software developers, or at least deal with college graduates who at least have some knowledge and potential to do things properly. And the Ruby on Rails idiots? Let's shun them as hard as we can. They have no place in our industry.

Re:We don't shun those who should be shunned.

[symbolset]

These guys were openly publishing their brilliance before hiding how your shit works was even a thing. Believe it or not once upon a time if you invented a brilliant thing in code you shared it for others to build upon so you could learn and grow and benefit. Hiding it for profit wasn't even thought of yet. It wasn't just undesirable: the thought did not even occur. That was the golden age of much progress, as each genius built upon the prior - standing upon the shoulders of giants reaching for fame. Now that we're in a hiding era we go around and around reinventing the same shit over and over, suing each other over who invented it first. It is madness. In the process we have moved backwards, losing decades of developed wisdom.

Re:We don't shun those who should be shunned.

[TheRaven64]

The designers or Ruby wanted Smalltalk with Perl syntax. I find it amazing that anyone could look at Smalltalk and think 'the one thing this needs to make it better is Perl syntax'. And you can substitute pretty much any language for Smalltalk in the last sentence.

'Web Based' Coding is not the same...

[neorush]

We marvel that the runtime environment of the web browser can do things that we had working 25 years ago on the Mac

I don't remember that code running cross platform on varying architectures. The web as an platform for distribution should not be compared to an actual OS...that doesn't even make sense.

Re:'Web Based' Coding is not the same...

[DutchUncle]

I don't remember that code running cross platform on varying architectures.

Yes. No code runs cross platform on varying architectures - INCLUDING the stuff that supposedly does, like Java and Javascript and all of the web distributed stuff. All of it DEPENDS on an interpretation level that, at some point, has to connect to the native environment.

Which is what BASIC was all about. And FORTRAN. Expressing the algorithm in a slightly more abstract form that could be compiled to the native environment, and then in the case of BASIC turned into interpreted code (Oh, you thought Java invented the virtual machine?)

In Browser

[MacDork]

We marvel that the runtime environment of the web browser can do things that we had working 25 years ago on the Mac.

Did the Mac, 25 years ago, allow people to load code from a remote server and execute it locally in a sandbox and in a platform independent manner all in a matter of a couple of seconds? No. No it did not.

We should then pay homage to the Mac 25 years ago, when it basically did what Doug Englebart demonstrated 45 years ago. Nice logic you have there.

Re:In Browser

[grcumb]

We marvel that the runtime environment of the web browser can do things that we had working 25 years ago on the Mac.

Did the Mac, 25 years ago, allow people to load code from a remote server and execute it locally in a sandbox and in a platform independent manner all in a matter of a couple of seconds? No. No it did not.

We should then pay homage to the Mac 25 years ago, when it basically did what Doug Englebart demonstrated 45 years ago. Nice logic you have there.

Dude, just ignore this guy. Of all people who have the right to indulge in a good, old-fashioned 'get off my lawn' rant, Dave Winer ranks last. This is the man who, for our sins, gave us XMLRPC and SOAP, paving the way for the re-invention of... well, everything, in a web browser.

Port 80 died for this man's sins....

Re:The thing about repeating the past

[symbolset]

Lady Gaga is mentioned because she is both a classically trained artist and sui-generis of successful PopTart art through self-exploitation. Yes, the reference is recursive - as this sort of folk are prone to be. They can also be rude, if you bother to click through, as they give not one shit about propriety - they respect skill and art and nothing else.

When I plussed this one on the Firehose I knew most of us weren't going to "get it" and that's OK. Once in a while we need an article that's for the outliers on the curve to maintain the site's "geek cred". This is one of those. Don't let it bother you. Most people aren't going to understand it. Actually, if you can begin to grasp why it's important to understand this you're at least three sigmas from the mean.

Since you don't understand why it's important, I wouldn't click through to the article and attempt to participate in the discussion with these giants of technology. It would be bad for your self-esteem.

For the audience though, these are the folk that made this stuff and if you appreciate the gifts of the IT art here is where you can duck in and say "thanks."

Net, CPU and GPU bound

[AHuxley]

The best and brightest at Apple, MS, BeOS, Linux did learn from "the great masters" - thank you to all of them.
They faced the limits of the data on a floppy and cd.
They had to think of updates over dial up, isdn, adsl.
Their art had to look amazing and be responsive on first gen cpu/gpu's.
They had to work around the quality and quantity of consumer RAM.
They where stuck with early sound output.
You got a generation of GUI's that worked, file systems that looked after your data, over time better graphics and sound.
You got a generation of programming options that let you shape your 3d car on screen rather than write your own gui and then have to think about the basics of 3d art for every project.
They also got the internet working at home.

Re:Net, CPU and GPU bound

[Darinbob]

Some people seem to think this article is about going back to the past. They miss the entire point. We're not saying that older programs were better, or that older computers were better, or that we should roll back the clock. We're saying that they had to pay more attention to what they were doing, they had to learn more and be broad based, they had to learn on their own, and so forth. When they had good ideas they were shared, they were not continually being reinvented and presented as something new. They didn't rely on certification programs.

Some things are missing

[Gim Tom]

As a 66 year old life long geek I actually saw many of the things I worked with decades ago reinvented numerous times under a variety of names, but there is one thing I used extensively on IBM OS/360 that I have never seen in the PC world that was a very useful item to have in my tool kit. The Generation Data Set and by extension the Generation Data Group were a mainstay of mainframe computing on that platform the entire time I worked on it. When I moved on to Unix and networks in the last few decades of my career I looked for something similar, and never found anything quite as simple and elegant (in the engineering sense of the word) as the Generation Data Set was. Oh, you can build the same functionality in any program, but this was built into the OS and used extensively. If anyone has seen a similar feature in Unix or Linux I would love to know about it.

A symptom of popular culture in the '60s

[DutchUncle]

... which really means the late '60s into the '70s. Isaac Newton said that he saw far because he stood on the shoulders of giants. Bill Gates and Steve Jobs were *proud* of knowing nothing about the industry they were trying to overturn. The same free, open, do-your-own-thing attitude (partly based on the new abundance helped along by technological advancement) that permitted startups to overtake established manufacturers, also encouraged tossing out anything "established" as "outdated" whether it was useful or not.

Re:Back to BASIC

[Samantha Wright]

Here's some worthwhile reading on why Lisp has trouble staying put—possibly a little flamebait-y: Lisp is not an acceptable Lisp, The Lisp Curse, and Revenge of the Nerds. The core arguments seem to be (a) it's really easy to invent things in Lisp so no one can agree on how to do it, and (b) the lack of a coherent standard platform means there is no easy target for university courses or job descriptions.

All Mozart's Works are Open Source

[Flwyd]

You can learn a lot from Mozart because you can read all the notes he published.
You can listen to many interpretations of his works by different people.
We don't have the chance to read through 25-year-old Mac symphonies^W programs.
We aren't even writing for the same instruments.

Re:The thing about repeating the past

[Anonymous Coward]

This is perhaps the most masterful parody of the passive-aggressive, cringe-inducingly self-congratulatory hipster attitude that I've seen on this site, and possibly anywhere on the internet, in some time. Bravo.

indeed, too many bad code monkeys, few engineers

[raymorris]

Indeed. Half of today's programmers have roughly zero engineering education, and want to be called software engineers. They have no idea, no idea at all, what their data structures look like in memory and why they are so damn slow. Heck "data structure" is an unfamiliar term to many.

It's not entirely young vs old, either. I'm in my 30s. I work with people in their 50s who make GOOD money as programmers, but can't describe how the systems they are responsible for actually work.

How do we fix it? If you want to be good, studying the old work of the masters like Knuth is helpful, of course. Most helpful, I think, is to become familiar with languages at different levels. Get a little bit familiar with C. Not C# or C++, but C. It will make you a better programmer in any language. Also get familiar with high level. You truly appreciate object oriented code when you do GUI programming in a good Microsoft language. Then, take a peek at Perl's objects to see how the high level objects are implemented with simple low level tricks. Perl is perfect for understanding what an object really is, under the covers. Maybe play with microcontrollers for a few hours. At that point, you'll have the breadth of knowledge that you could implement high level entities like objects in low level C. You'll have UNDERSTANDING, not just rote repetition.

* none of this is intended to imply that I'm any kind of expert. Hundreds, possibly thousands of people are better programmers than I. On the other hand, tens of thousands could learn something from the approach I described.

The past was nice but today is not then

[Coditor]

I'm old enough at 55 to remember the past, and yes I did love APL briefly but lamenting that the present isn't like the past is like wishing it was 1850 again so you could have slaves do all your work. Neither the web nor the modern mobile application is anything like the past, and what we use to write that code today is nothing like what I started with. Trying to relive the past is why old programmers get a reputation for being out of touch. The past is important in that I learned a lot then that still rings today but I can say that about every year since I started. Today is a new day everyday.

Re:Back to BASIC

[cheater512]

Lisp never 'comes back'. It merely recurses.

Re:What past was he from?

[AK Marc]

What past were you from? When I had DOS 3.3 running on my XT (on a hard drive), it booted in a few seconds after POST. When I loaded Windows 3.1 (no network at home at the time, so didn't run W3.11) on an XT with 1M RAM, it would take forever. And DOS 3.3 from floppy was slow, and loud. But 3.3 from HD on an ancient XT was much faster than Windows is today. DOS programs loaded fast, granted I was running 300k programs, not 300 MB programs, but they were still fast on DOS 3.3 back in the day. What were you running on your ancient computer?

Re:Back to BASIC

[ebno-10db]

it gives me somewhat of a sign of relief to see C, C++ and Java/C# be stable in the face of this recurring tide of fad languages

Sheesh, kids today. I remember when C++, Java and C# were the fad languages. I even remember when C outside of the Unix world was a "fad" replacing Fortran, Basic and Pascal. The "classic" languages you grew up with are not the end of programming language evolution.

OTOH I admit that the so-called Cambrian explosion of languages really needs to be followed by a mass extinction. Perl, Python, Ruby, Lua, etc., etc., etc. You could spend the rest of eternity debating their pros and cons, but do we really need all of them? It's great if you want to spend the rest of your life learning yet another genius's "best of" mix of existing language ideas, but it sucks if you just want to get work done. Then there's Clojure, because what the Lisp world really needs is yet another dialect, and F# because, uh, well OCaml has been around a while and we really want yet another variant, and ...

Re:Back to BASIC

[Darinbob]

Macsyma? Emacs itself is more Lisp than C. Zork was a Lisp dialect. Mirai is lisp, and was used to do animation in Lord of the Rings. Lots of expert systems. Several CAD systems and other modelling programs. Data analysis stuff. Whoever uses Clojure is using Lisp and it seems to have some traction. And Orbitz is apparently using a lot of Lisp internally (just to throw out a web site since some people think it's not real if it's not a web site or PC app).

Re: Back to BASIC

[Therad]

and he is still right. ;)

Another interpretation

[wanax]

I've always felt like that quotation had another interpretation, one that's much more favorable to the MPs:

If you're an MP, you've probably had to deal with a lot of people asking for money to fund what is essentially snake oil. If you don't understand the underlying 'cutting edge' technology (both plausible and acceptable), one simple test is to ask a question that you KNOW if the answer anything other than "No" that the person is bullshitting, and you can safely ignore them... and as reported the question is phrased in such a way that it would sorely tempt any huckster to oversell their device. I think Babbage's lack of comprehension was due to his inability to understand the idea that the MP was questioning HIM, rather than the device.

Parent post speaks truth

[Camael]

Actually, from the examples cited, it seems to me to be painfully obvious why in those cases information was not shared.

One of the most painful things in our culture is to watch other people repeat earlier mistakes. We're not fond of Bill Gates, but it still hurts to see Microsoft struggle with problems that IBM solved in the 1960s.

For quite a long period of time, IBM and MS were stiff competitors (remember OS/2 warp?). I doubt MS would inform IBM what they were working on, much less seek help. In fact, it seems to be the exception rather than the rule for software companies to share code with each other. Selling code, after all, is usually how they make money.

'We marvel that the runtime environment of the web browser can do things that we had working 25 years ago on the Mac.'

Im fairly confident that Apple would sue any company that copies its software written for the Mac. Let us also not forget how much problems Oracle caused for Google when they sued over the Java API in Android. Yes, it is efficient to reuse old tried and tested code, but it also opens you up to a lawsuit. So it is not so much reinventing the wheel as trying to find a different way of doing things so you wont get sued. For that, you have current IP laws to thank.

One of the problems with modern computer technology is that programmers don't learn from the great masters. 'There is such a thing as a Beethoven or Mozart of software design,' Locklin writes. 'Modern programmers seem more familiar with Lady Gaga. It's not just a matter of taste and an appreciation for genius. It's a matter of forgetting important things.

The problem here is with equating writing software to producing works of art. People are willing to go out of their way to learn and improve themselves to paint better or make beautiful music because it enables them to express themselves. It's emotionally satisfying. OTOH most software is programmed to achieve a certain utility and the programmer is faced with constraints e.g. having to use certain libraries etc. He is rarely able to express himself, and his work is subject to the whims of his bosses. For most everyday programmers, I think there is no real motivation to 'learn from the great masters'.

An exception might be the traditional hacking/cracking community where the members program for the sheer joy/devilry of it. I understand there is a fair amount of sharing of code/information/knowledge/learning from the great masters within their community.
 

Re:Back to BASIC

[TheRaven64]

The first C book I read spent most of the first chapter justifying why you'd use a high-level language like C instead of assembly. How times change...