Slashdot Mirror
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!"
10 GOTO 20
20 GOTO 10
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.
sysadmins and parents of newborns get the same amount of sleep.
John Graham-Cumming gave a talk at OSCON 2013 titled "Turing's Curse" that speaks to this same idea. Worth a watch.
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.
http://scottlocklin.wordpress.com/2013/07/28/ruins-of-forgotten-empires-apl-languages/#comment-6301
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.
[Fuck Beta]
o0t!
That's genius: comparing a "$100k/CPU" non-distributed database to a free distributed database. Also no mention that, yes, everyone hates Hive, and that's why there are a dozen replacements coming out this year promising 100x speedup, also all free.
And on programming languages, Locklin is condescending speaking from his high and mighty functional programming languages mountain, and makes no mention of the detour the industry had to first take into object-oriented programming to handle and organize the exploding size in software programs before combined functional/object languages could make a resurgence. He also neglects to make any mention of Python, which has been popular and mainstream since the late 90's.
One of the things that I still see is the idea that when a problem exists, throw more people at it. The mythical man month pretty much threw that to wind for software development, and I am sure there are a whole slew of books that predate it saying essenstially the same thing. Yes advancements do mean that more people can communicate more directly, but there still is a limit and I do not think it is as great as some believe. Define interfaces, define test that insure those interfaces exhibit high fidelity, and let small teams, even a single person, solve a small problem. What technological advance has done is make clock cycles very cheap, so there is less excuse to go digging around trying to change code that will make your code run a little faster. Speaking of interfaces, we know that when data and processes are not highly encapsulated, it is nearly impossible to create a bug free large project. One thing that object oriented programs has done is to create a structure where data and processes can be hidden so they can be changed as needed without damaging the overall software application. Now, many complain because the data is not really hidden, it is just a formality. But really coding is just a formality, and a professional is mostly one who knows how to respect that formality to generate the most manageable and defect free code possible. One thing that has been lost with the generation of rapid development systems quickly spouting out bad code is that code and the ability to tweak it is the basis of what we do.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
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.
neorush
There are a lot of things that if source code was available, other people could build on it and make higher quality products. In the absence of source code, people need to start from scratch often rebuilding the wheel.
Competition for money might get people to strive to make better pieces of art. But on the flip side, this same competition will sue your pants off for any reason they can find so you don't compete with them either.
An on an unrelated note, I had an idea for a zombie video game like Ground Hog day today. When you die, it starts out as the beginning of a zombie pandemic. As you die and play through it over and over, you get secrets to where weapons and supplies are. You find tricks you can use to survive and save people. Eventually you find out who caused the zombie pandemic. You can then kill him before he goes through with it. I'm not sure an ending where you serve in prison is a good ending though. I didn't think it the whole way through, but it sounded like a good premise for a zombie game.
God spoke to me
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.
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."
Help stamp out iliturcy.
He says system performance is the same as it was way back then. He thinks that stuff just happened immediately on those systems because they were running very efficient code. So what. Here's a simple test. Go get one of those computers and set it next to yours. Turn them both on. Mine would be at a desktop before the old one even thinks about getting down to actually running the operating system. Or start a program. On a current system it loads now. As in, right now. Back then it was a waiting game. Everything was a waiting game. He must have simply forgotten or repressed those memories.
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.
Domestic spying is now "Benign Information Gathering"
If the people in the middle ages had only realized it was the rats, and the fleas they brought with them, they wouldn't have suffered from plague for so long. Hindsight is 20/20.
There's arguably a list of things that make a language into "a" Lisp, and not all of the languages that meet those criteria are actually forks or directly inspired by McCarthy et al.'s LISP programming language. GP was referring to this concept, but probably has a much looser understanding of what it means to be a Lisp. Tragically, TFA is mostly about APL.
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
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.
... 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.
For any given software project there is an optimal team size. If the project is small enough, you can keep the team size down to what works with an agile development methodology. If the project is bigger than that, things get ugly. I started my career in a company that considered projects of 50 to 100 man-years to be small to medium sized. Big projects involved over a thousand man-years of effort and the projects were still completed in a few years calendar time. You can do the math as to what that means as far as number of developers working concurrently (I remember one project that had approximately 500 to 600 people working on it).
The methodologies and discipline exist to solve such projects. It isn't efficiient compared to a small project but small project techniques can't solve big problems in time. Usually when you attempt to explain what it entails to management you get a response of, "We don't have time for that." So, the project flounders for twice as long before finally getting put out of everyone's missery.
Oh yeah. Been there. Done that. Over and over. Seen it done right when people used the right approach and I've seen more than my share of death marches that only seemed to convince good developers to look for another line of work.
Cheers,
Dave
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
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.
Ceci n'est pas une signature.
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. 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.
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.
LocalTalk file sharing, AIFF files, 8-bit audio support.
Yeah, but too many of today's programmers think they discovered America themselves.
For instance: As a cyberneticist I'm fond of programs that output themselves, it's the key component of a self hosting compiler... Such systems have a fundamental self describing mechanism much like DNA, and all other "life". While we programmers continue to add layers of indirection and obfuscation ( homeomorphic encryption ) and segmented computing (client / server), some of us are exploring the essential nature of creation that creates the similarities between such systems -- While you gloat over some clever system architecture some of us are discovering the universal truths of design itself.
To those that may think Computer Science is a field that must be studied or be repeated, I would argue that there is no division in any field and that you haven't figured two key things:
0. Such iteration is part of the cybernetic system of self improvement inherent in all living things -- to cease is death, extinction.
1. Nothing in Computer Science will truly be "solved" until a self improving self hosting computing environment is created...
So, while you look back and see the pains of Microsoft trying to implement POSIX poorly, I've studied the very nature of what POSIX tried and only partially succeeded to describe. While you chuckle at the misfortunes of programmers on the bleeding edge who are reinventing every wheel in each new language, I look deeper and understand why they must do so. While you look to the "great minds" of the past, I look to them as largely ignorant figures of self import who thought they were truly masters of something, but they ultimately did not grasp what they claimed to understand at a fundamental level -- The way a Quantum Physicist might acknowledge pioneers in early Atomic thinking... Important, but not even remotely aware of what they were truly doing.
How foolishly arrogant you puny minded apes are...
I think "learning from the old masters" really isn't the problem. It's not that we don't have lots of smart people writing software. I think the core problem is that we haven't figured out how to do upgrades and backward compatibility properly, which the old masters haven't figured out either. You can go and develop a HTML replacement that is better and faster, sure, but now try to deploy it. Not only do you have to update billions of devices, you also have to update millions of servers. Good luck with that. It's basically impossible and that's why nobody is even trying it.
In a way HTML/Javascript is actually the first real attempt at trying to solve that issue. As messed up as it might be in itself, deploying a HTML app to billion of people is actually completely doable, it's not even very hard, you just put it on your webserver and send people a link. Not only is it easy, it's also reasonably secure. Classic management of software on the desktop never managed to even get near that ease of deploying software.
If software should improve in the long run we have to figure out a way how to make it not take 10 years to add a new function to the C++ standard. So far we simply haven't. The need for backward compatibility and the slowness of deploying new software slows everything to a crawl.
You don't like Gates but wish programmers looked towards more "Great Masters?" Bill Gates was a Great Master Programmer.
There are a few problems which keep being rediscovered. In many cases, the "new" solution is worse than the original one.
I had an Atari ST at college. It booted (to a graphical, no less) desktop pretty much instantly, say a few seconds if you had a slew of SCSI peripherals (especially a CDROM drive), but otherwise it was about half a second.
It was ready to go, too. None of this crap of *showing* the desktop and then spinning the busy cursor for another 30 secs...
Simon.
Physicists get Hadrons!
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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.
Actually, from the examples cited, it seems to me to be painfully obvious why in those cases information was not shared.
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.
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.
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.
You play with that newfangled mnemonic bullshit, huh? 1s and 0s too much for you?
goddam kids.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Yes, back in the day it could be said that becoming familiar with assembly could make you a better C programmer. It can still be said, because it's true, and I said it above. That's the point of "spend a few hours playing with microcontrollers", to get a minimal familiarity with that level of intimacy with the hardware.
.NET will make you truly appreciate the value of objects, interfaces, etc.
Are you suggesting that it's not true, that C won't show you things that you don't learn from Ruby? Also the reverse - GUI programming in
Note that I'm not suggesting that all programs should be written in a low level language. Go ahead and use the appropriate language. Perl is great because it has LWP::Simple (very high level) and it has bit shift operators.
What I'm saying is use SQL, sure, and even report generators, but know how they work. If I give you two tables that are 3X3, could you perform a join with pencil and paper? If so, you'll do better work than someone who only uses a report generator and has never looked at the underlying data.
Historically, apprentices would study at the master's feet. They would start by doing menial support tasks (like sweeping floors), moving to copying the master's work as journeymen, then finally after many years becoming themselves masters and actually creating works.
Up to 80% of the cost of software is maintenance. There are very few maintenance programmers. See, most kids want to start out at the master level and skip paying their dues. There's a bug or an enhancement? No problem! just rewrite the program from scratch, do it right this time! It's actually less expensive to rewrite the software than to maintain it, since you save that 80% of the cost. At least in the very very short run.
If programmers were required to do an apprenticeship, doing software maintenance for a couple of years before ever writing something new, they would be exposed to what went before and overall quality would go up. It just seems the know-it-all of youth has been taken too far in the industry and the price is being paid.
There are the 'coder factories' that advertise on late night TV. The people that come out of there, and even out of high-school and Jr Colleges or trade schools are all dropped in the same pool as 'programmers'. Most programmers, at least the better ones, view their code as in many ways an art form. Once upon a time (think '70s) using 'tricks' to save memory was a big thing and was often used as some sick form of 'job security'. From what I have seen most individuals are over that, but not so much commercial software companies that think 'protectionism' is 'protecting their assets'. Much code has been 're-implemented' by doing blackbox reengineering.
There is still a place for the arts in computers and even software, but making things run better, faster, be smaller, use less resources, use 'vertical' AND 'horizontal' computer power, failsafe, encryption, API's, easier to network/interface, secure, better human interface, usability, etc.
Yes, I have studied the history of computing both academically and as a personal interest. That includes anything from mechanics of the babbage engine, digital systems design (that has been useful several times since school in 'doing what everyone says can't be done'), studying the architecture of the Saber System (hardware and software from IBM for American Airlines - now antiquated, but a leap forward in interactive computers, networking, and database architecture). I have worked with some of the architects and developers of the original National Semiconductor UART chips and the IBM HASP system originally written for NASA to keep them from being kicked out of NASA in Houston. Knowing HOW these worked, how the succeeded and failed ALL helped in my systems I wrote for customers (Mainly Fortune 500 types but includes medium to mom&pop shops).
It has been interesting studying some of the big failures and successes of the past, both in computing and business. Seeing the advanced systems before they were appreciated by the public. Seeing the marketing faux pas of large and small companies. For many small companies it is fatal, for large it hurts reputation even if they get through it (Ford Edsel, Apple Lisa, New Coke, we can all name some more).
I don't think EVERYONE needs to get as deep into it as I have, but it would help understanding and appreciation of the history both technical and of the people and times when developing solutions for today and the future.
Education is never lost. It just adds to the tapestry of life.