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'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.