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.
It isn't even a question of faster ... a lot of those "glued-together solutions" don't scale and are impossible to debug and maintain.
Warning! Before you read the linked article or its followup too deeply, be aware they are not by Donald Knuth. Instead, the author has a brief quote from Donald Knuth in his first blog, and the other link is a followup story. So, "the author" referenced in the Slashdot summary is NOT Donald Knuth. I made the mistake of reading the followup article first, and then when I read the original, I found a brief quote from Donald Knuth which tipped me off to the fact that the author was not Donald Knuth, and as far as I can tell, Donald Knuth doesn't even know this author.
If I can be modded down for being a troll, can I be modded up for being an orc, or a balrog?
I wouldn't separate that too much. Some of us exist that can do the "hard stuff" and might even find and fix a bug in some of the libraries from time to time. However, when we're just making an app that works and fits in with the environment, a lot of the "hard stuff" has been done and is likely to be less buggy and more consistent with the environment than redoing the whole thing ourselves. Then, if it's open source, we can just fix bugs we find in the "hard stuff" and focus more on what we're actually doing.
Hell, things like basic sockets and other things that are fairly easy, really--every once in a while I forget to back that up or something stupid and instead of just doing it all from memory and by hand, I just copy and paste it off the internet, then rework it to my liking (by this time, I know the commands, but copy and paste is just faster). Of course, some times I like to do things that have already been done, only try to do it in a new way, just as an exercise (I'm down to programming as a hobby at this point).
I wouldn't be too harsh on copy and pasting, though. It can be a great learning exercise if you peel it apart and actually understand exactly what is going on and the different ways you can alter it. It's also a great way to get to know an open source library and be able to fix any bugs you find, or even add features to it, if that's your fancy. That's generally how I've done anything in that regard, to be honest.
I've dealt with Chinese and Indian outsourced code before - it's rather interesting. They take fragments of code they find via Google, paste them together, and do the bare minimum of editing to make it compile and say 'okay, we've fulfilled our contract, ship it.' This is what suffices for 'programming'.
On the other hand, I am still solving interesting problems with real programming at my current company, so I still think it's a lot of fun. The key point is that the programming is part of the /problem solving/. Code pigs have no concept of problem solving, just making the program work (by which they mean compile, or matching the sample screens). Engineers are solving problems, and the program is just a part of that. At my present job they really don't care what language I do things in as long as the job gets done, because solving the problem in the most practical manner is the most important thing. In practice this means I use C for things that actually do require high performance and minimal memory usage (this is still an issue in embedded programming), Python for everything else that I can, and domain specific languages for things like servo controllers or FGPAs.
The 'pasting not quite compatible libraries together' approach is a Java/COBOL thing of minimizing the damage incompetent consultants can do. I've seen it time and time again - once an Enterprisey Java programmer encounters sufficient complexity, a hormone kicks in and they create a framework to simplify this complexity. It does so, initially, but eventually ends up being 2-10x as complex as the original problem they were trying to simplify. But they see this as a net positive because they have a new acronym to put on their resume.
So basically, like every single damn post I've seen on here lamenting the state of programming, and repeating every damn comment I've made again and again, it boils down to 'solve problems as efficiently as you can'. Absolute rules, in programming or religion, are for people who are too simple to handle complexity. This is the difference between an engineer and a code pig.