Slashdot Mirror
Whatever Happened To Programming?
Mirk writes "In a recent interview, Don Knuth wrote: 'The way a lot of programming goes today isn't any fun because it's just plugging in magic incantations — combine somebody else's software and start it up.' The Reinvigorated Programmer laments how much of our 'programming' time is spent pasting not-quite-compatible libraries together and patching around the edges." This 3-day-old article has sparked lively discussions at Reddit and at Hacker News, and the author has responded with a followup and summation.
THE DUMBING-DOWN OF PROGRAMMING (1998): "My programming tools were full of wizards. Little dialog boxes waiting for me to click "Next" and "Next" and "Finish."...Dumbing-down is trickling down. Not content with infantilizing the end user, the purveyors of point-and-click seem determined to infantilize the programmer as well."
Not to mention that he can't grasp the awesome power of 300 APIs (sorry, "technologies") each with three letter abbreviation names starting with J that make up the resume of a typical Java programmer.
Agreed, but the problem is that most of those "technologies" are bloated, designed by committee, buzzword-loaded crap. The problem is *not* that we have found better ways to share code than we used to. I mean, I'm all for crafting beautiful, optimally efficient snippets of code that do one thing perfectly. But have you ever noticed that you can do things in a couple of hours now that 10 years ago would have taken weeks? Being able to cobble together a prototype fast is *hugely* useful and important. Now who was it again who said that premature optimization is the root of all evil? Hmmm...
"I think a better analogy would be to say that today's programmers are more like a Cargo Cult."
Responses to the recent MS-random-browser thread ("the faulty shuffle is close enough", "this guy's being pedantic", "knowing algorithms is a bad use of company time") are pretty good evidence of that.
http://developers.slashdot.org/article.pl?sid=10/02/28/1837223
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
It's time to build a dedicated open-source GUI/CRUD browser that can handle desktop, MDI, data grids, tree controls, and CRUD-like applications with grace.
You mean, like Access? Or, in some way, even SharePoint?
From the article: "...it’s a tedious exercise in impedance-matching, requiring lots of time spent grubbing around in poorly-written manuals that tell you everything the code already told you (because it was generated with JavaDoc or Rdoc or whatever), and none of the high-level stuff that you actually need to be told."
Ah, so the real problem is poor documentation.
I work all day in a programming language written by one of the biggest software companies in the world. The documentation is complete, detailed, and accurate. For large things, there's an accompanying "concepts" doc. While I have (very rarely) run into something that needs clarification in some sort of corner case, I've never come across any part of their language, libraries, or objects that wasn't thoroughly documented, with examples.
On the other hand, I don't think I've ever come across an open source product that had barest minimum of documentation. What does exist is typically out of date (and observations of such are met with "read the changelog!" - lame). There's certainly nothing that explains the major concepts in the code - at best, there's some guide to functions or objects, and usually that only because it can be autogenerated. Sometimes there are examples - though more typically, a few mini examples are the only documentation.
Documentation writing sucks. Programmers don't enjoy it. It's highly amusing to me that the two areas that are the least fun for programmers - GUI design and documentation - are the two worst parts of open source projects.
BTW, in the 80s, programmers were excited about OOP because it promised rich object libraries. Someone would create objects to do X and we'd never have to code X again - no one, ever! And now everyone complains programming is just stringing together libraries.
Advice: on VPS providers
but it's still a shuttle ;-) I meant more like the Aries platform(s) that was meant to use existing Shuttle parts and designs in order to quicken the pace to be ready by the Bush administration's deadlines. But it's not an ideal platform when judged by itself. It's a hack that traded time for elegance and economics.
Table-ized A.I.
The probability that a theory predicts correctly, gets higher when the theory gets simpler.
The probability that a program is useful in new situations, gets higher when the program gets smaller.
This has been proven mathematically with algorithmic information theory.
However, Keeping It Simple, Stupid, is very hard and costly, and most people have an instinct for hoarding that gets in the way.
Kim0
Agreed, mostly. If you have an XML parser for free (e.g. in a web browser), them XML is a great way to push structured data around. If you have to roll it yourself, it's horrible. Using libraries, it's somewhere in-between, depending. If you're going into a toolchain that expects XML or if you're working with a lot of structured text data, XML is probably a good choice. That said, it's quite possibly the most overused technology. Far too many people just automatically use XML where CSV file or tab-delimited text file would do the same job with tens of thousands of lines less code.....
And regular expressions are for light text processing and/or single-use (write-only) tools. Using them where a parser would normally be used is the quickest way to create fragile code that breaks constantly. :-) Been there, tried to maintain that, then ripped it all out and wrote a token-based parser.
Check out my sci-fi/humor trilogy at PatriotsBooks.
In 1900, a guy in a patent office figured everything had been invented. I hate that attitude. My operating system, LoseThos, http://www.losethos.com/ has tons of new ideas. Things have changed since 1970's mainframe operating systems!
When God goes to war, He drops big bangs.
What annoys me is that we have had thin clients for decades: using remotely hosted software has been mature for as long as I can remember. VT100 emulation even works across a modem link. Want a GUI? the X Window system has been around for over a decade as well.
I like the Lynx browser: it uses external programs for also most everything. Even things like YouTube can work if you hand off the .flv to a video player. Browsers should not be acting as an OS replacements with their own schedulers. IMO, browsers should not be handling client-side scripting at all: hand that Java Applet off to an interpreter.
Don't get me started on the "pixel perfect" cult.
I think the guy's point was that Knuth wrote that in the 70s, and it's now the 10s - a gap of forty years in which he has capitalised off his earlier work but not really brought anything that revolutionary to the table since. His original work stands as a classic, bring together a vast amount of highly relevant information and algorithms for the programmers of the 70s/80s. It has a lot less relevance in this age because most of his work is now part of some standard library or framework.
I've written plenty of things as useful as TeX but that doesn't mean I'd call Knuth an idiot.
All those moments will be lost in time, like tears in rain.
I agree from a different view that goes like this. Good programmers/software engineers are expensive so companies like to pay cheaper people. To enable use of cheaper people tools and processes are introduced.
One such tool is languages that have buckets of libraries or core tools that the new people merely have to extend or tweak.
Knuth is lucky that most things he needed didn't exist then so using libraries wasn't an option. If everything he needed already existed he'd have picked a different area to work in.
The thing is, most people want to rewrite the code because it is too hard to understand. In which case they probably don't understand it when they do the rewrite and end up making at least as bad mistakes as the original authors.
_If_ they fully understood it, in most cases it wouldn't be so hard to just attack the most problematic parts and improve them - for example in quickly written code there is often a lot of cruft where only a few lines can be changed to make the code simple, smaller and overall better while being almost certain that it still does _exactly_ the same thing (if necessary under a few assumptions documented with asserts).
Admittedly this might end up with everything being rewritten, but with an understanding of the old code and the new code, with change control, and a way to do regression testing where you can say: the bug is in these at most 100 lines of code, which reduces greatly the debugging costs of the rewrite.
The difference is maybe that you actually have to know why and how those theorems work. Because else you could not use them. Not knowing why a certain mathematical rule is applicable means that you cannot apply it, not knowing whether its use would be "legal" from within the mathematical ruleset.
This is not the case with library functions. All you have to know is what you want to accomplish, you drop that info into the help file, it spits out a function (most of the time not really the best one, but one that will more or less do the trick) and it will also tell you what you have to drop into that function to make the magic happen.
Now, math has been a while ago for me, but I cannot remember it being THAT easy.
Except that there's a little issue with that nice theoretical model: leaky abstractions.
If you blindly use functions (actually methods) without an understanding of what they do internally, you will get burned.
This is why crap code deadlocks. This is why crap code leaks memory. This is why crap code can't run on anything except a specific version of Windows with a specific version of IE.
I'd mod you up if I had points.
Most of the code I call "crappy code" is stuff I'm asked to look at because somebody found a reproducible defect, I look at the code, blink twice, and wonder how we haven't had a "oops, all of our data is gone" scenario yet. Fortunately I keep daily backups around...
And, of course, when I ask the original developer to "fix it", they can't seem to figure it out, even when giving step-by-step instructions how to reproduce the defect, over, and over, and over, and over.
I've looked at some of these CGI apps "web developers" put out, and I wonder if they have any brain cells between their two ears. Just using some sort of MVC architecture would be a good start to fixing 99% of the problems I see with shitty web code, and at least keep things somewhat more organized (if only just slightly)
Few programmers start to write a program by designing a new OS, etc., so your analogy is simply a strawman. How about this car analogy: when designing a new car you are allowed to use only already existing auto parts; you are not allowed to custom design hardly any part on the "new" automobile. This is the real analogy with patching together existing library routines to build a new program: connecting together a set of already existing auto parts to make a "new" car. Does this better analogy still sound just fine? Obviously depends on what one is reusing and how complicated that was to engineer.
Speaking as an ex-over-the-road truck driver, it is a bad analogy because truckers do care about what they are carrying. They have to because they have to comply with different weight and bridge laws in each state. Truckers need to know if the load could shift, leak, etc.
And, no trucker wants a load that is not what the manifest says. Makes delivery difficult and if the load is inspected and the contents of the trailer does not match the contents of the bill of lading then the driver might have be in serious trouble.
Shippers may require the route not go over a certain altitude, through certain areas (New York City for one), or require a specific delivery time frame ("You have to be there on Wednesday between 6AM and 9AM").
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
Part of the issue is that "programming" is no longer what it used to be, yet everyone still uses the term.
It's the difference between BBS and "Web 2.0". It used to be that geeks only could get a modem and some BBS software running which would allow them to connect to the entire world. Now my grandmother can tweet about the birds at her feeder, and someone in Tajikistan can read about them.
There is a fundamental split now between "designing and writing code" and "programming applications". You want to "program applications". The author and a number of people posting here want to "design and write code". These are two very different things.
I previously worked in a job "programming applications" for customer service reps. I had a stupid-easy gui toolbox, and pre-written database calls. All I did was link the two together, and provide some feedback for the operator. Currently, I'm in scientific computing, writing some bare-bones code to parse an obtuse, undocumented data structure into a usable format. I've got none of the nice easy stuff I had before. It's raw file reads and writes, slowly stepping through lines of output, trying to figure out wtf is going on. No gui, no buttons, nothing but some console output.
Based on the article and comments here, it seems that we almost need to split "programming" up into some clearer terms. There's building a car, and there's driving one. There's writing raw code, and there's using pre-made tools to do a job quickly and efficiently. If I wanted one of those things done well, I wouldn't hire someone who was an expert at the other. Right tool for the job and all....
Velociraptor = Distiraptor / Timeraptor