Remember the Computer Science Past Or Be Condemned To Repeat It? 479
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!"
It's not the programmers making the decisions (Score:5, Insightful)
We don't shun those who should be shunned. (Score:5, Insightful)
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.
Paging Linus (Score:3, Insightful)
http://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgotten-empires-apl-languages/#comment-6301 [wordpress.com]
Computer science worked better historically in part because humorless totalitarian nincompoopery hadn't been invented yet. People were more concerned with solving actual problems than paying attention to idiots who feel a need to police productive people's language for feminist ideological correctness.
You may now go fuck yourself with a carrot scraper in whatever gender-free orifice you have available. Use a for loop while you're at it.
Re:It's not the programmers making the decisions (Score:5, Insightful)
Re:It's not the programmers making the decisions (Score:3, Insightful)
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.
That hasn't changed either. Just the specific subject of the idiocy has changed. Idiotic managers are timeless. Lady Ada probably had the same thing to say about Charles Babbage.
Cheers,
Dave
In Browser (Score:5, Insightful)
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. [youtube.com] Nice logic you have there.
Re:The thing about repeating the past (Score:4, Insightful)
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 (Score:5, Insightful)
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:We don't shun those who should be shunned. (Score:2, Insightful)
I can tell that you're young simply because you used C++ in a debate where someone slightly older would have used C. Either that, or you're a Windows programmer.
C utterly dominated open source (and thus the Slashdot community) until about 5 years ago. That's when the overwhelming number of university switched to C++. Of course, before that it was Java, so you can see the trend.
Unless you're a Windows programmer, I'd stick with C, which is infinitely simpler, and provides you freedom to maintain competency in other languages, many of which have far cooler features than C++ will ever be able to provide.
A symptom of popular culture in the '60s (Score:5, Insightful)
All Mozart's Works are Open Source (Score:5, Insightful)
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.
indeed, too many bad code monkeys, few engineers (Score:5, Insightful)
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.
Back to chariots and horses (Score:2, Insightful)
Chariots were masterpieces of art. They were often made of precious metals and had elegant design work. They were environmentally friendly, using no fossil fuels whatsoever. They didn't cause noise pollution, or kill dozens of people when they crashed.
Aircraft makers should learn from the past. They have totally functional designs, no semblance of artistry anywhere. Accommodations are cramped, passengers treated like cattle.
We should go back to the good old days, things were so much better back then.
No. I've loaded decks of punch cards and distributed printouts. But who could afford a computer of their own? Nobody. He can have his good old days...no way *I* want to go back!
The past was nice but today is not then (Score:5, Insightful)
Re:What past was he from? (Score:4, Insightful)
Also those old programs did a lot less than many of our new programs. People often forget that when complaining about performance.
That's not to say, of course, that modern programs couldn't be written more efficiently. Because of Moore's Law and other considerations, we have moved away from spending a lot of time on performance and efficiency.
Re: We don't shun those who should be shunned. (Score:2, Insightful)
I'm offended that ruby keeps getting thrown in with this Node/NoSQL stuff. Node has a couple of real use cases, but outside of that its a waste of time. NoSQL has a couple of real use cases, but outside of them it's not something you build around.
Ruby on the other hand is a really interesting language that has the benefit of being so flexible that its made for creating DSLs. Puppet, Chef, Capistrano and Rails just off the top of my head. Do some libraries have memory leak issues? Yes. Does its thread handling suck? Yes. Does jRuby fix all of that? Yes. Does Torquebox let you deploy on hardened JBoss infrastructure? Yes. Is the rails community driving a huge chunk of the web to embrace PostgreSQL over MySQL...? Yes.
Ruby and specifically jRuby is a powerful development platform with a great community around it. It is not deserving of being thrown in with the likes of Node as a fad. The biggest issue I see in Rails code is developers that try to do everything in Rails instead of leveraging their database but the popularity of PostgreSQL and its features are even starting to change that.
Re:The thing about repeating the past (Score:4, Insightful)
Re:Back to BASIC (Score:4, Insightful)
Lisp is easy to get good programs from. You just have to stop thinking in non-Lisp ways. What confuses people is the functional orientation, but if you don't understand functional style of programming then a lot of modern stuff will pass you by. Procedural stuff is very easy in lisp too.
Re:Back to BASIC (Score:3, Insightful)
Re:Net, CPU and GPU bound (Score:5, Insightful)
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.
Common rediscovered problems. (Score:4, Insightful)
There are a few problems which keep being rediscovered. In many cases, the "new" solution is worse than the original one.
Re:Back to BASIC (Score:5, Insightful)
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:You hate Gates but... (Score:2, Insightful)
Yes, many people don't realize how he got to his position. He started Microsoft by writing a BASIC interpreter for a machine that he had never seen before. He had to make an emulator for it on a PDP-10 based on its specs, then write BASIC on the emulator in a matter of weeks. He had to write in machine code and fit it all in 4k.
It worked the first time it was executed on the real hardware. Good luck finding somebody today who could do that.
dom
Re:We don't shun those who should be shunned. (Score:4, Insightful)
Re:Back to BASIC (Score:4, Insightful)
For example, deeply embedded processors running on an RTOS (not embedded Linux or something), or even bare metal, with memory limitations and hard real-time constraints measured in tens of microseconds is not the best environment for Lisp (or any GC language for that matter).
It's the best environment for Forth, and conversely, Forth is the best language for than environment.
Re:It's not the programmers making the decisions (Score:5, Insightful)
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 (Score:5, Insightful)
Re:Back to BASIC (Score:4, Insightful)
But there's a famously quoted statement by Guy Steele, who wrote some of the Lisp language specs and Java language specs. "we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp." ( http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg04045.html [mit.edu] )
Going from C to C++ is easy, I did that. Going from C++ to Java is easy. I did that too. Going from Java to Lisp is damn difficult, at least for me. But the fact that teaching mainstream C, C++, and Java developers Lisp is difficult merely makes it unlikely Lisp will be popular. It does not prove Lisp is a poor language.