So, two different posts crossed my transom recently, that I felt I had to respond to. First, and most egregiously, there’s The Daily WTF’s Programming Sucks! Or At Least, It Ought To. Then there is this blog post on Why Functional Programming Doesn’t Catch On. I am of the opinion, having covered much of the computer industry one way or another, that there are no non-trivial, uninteresting problems. The reason is just this- any problem that is boring, trivial, and/or mechanical should be done by the computer. I mean, come on, people! We’re programmers. If anyone anywhere should be able to harness the power of computers to make our work easier, it should be us programmers- the ones harnessing the power of computers to make everyone else’s work easier! If programming sucks, it’s because we’re being incredible stupid. Five lines of code duplicated over and over again, just to set some UI properties? Dear gods, people. Hasn’t any heard of subroutines? Abstraction? How about straight up code generation, or maybe implementing a DSL? OK, maybe if you’re only replicating those five lines a couple of times it’s not worth the bother. But if you’re replicating (with minor variations) those same lines of code over and over again, it’s probably worth it to step back and consider how to abstract things. Abstraction helps up the percentage of interesting code vr.s boring grunt work code, by minimizing the amount of boring grunt work code. If you can turn five lines of code, replicated ten thousand times, into one line of code, replicated ten thousand times, you’ve just turned a 50 KLOC project into a 10KLOC project, doable at least 5 times faster (and probably more like 25 times faster). Get the crap work out of the way fast, so you can get on to the more interesting stuff. I’m not even talking about leaving your language of choice, I’m talking about thinking outside the box, or even just thinking. But learning new languages is an advantage in making programming not suck, because if nothing else, it gives you new tools for your tool box, new ways to consider abstracting the code. And some languages are better than others, and the more you know, the more likely you are to know a good one. And if you don’t know the better language, you can’t use it. My initial response to the DailyWTF post was that it was another classic example of the starving child in Africa syndrome. You’ve seen the pictures. A child in some hell-hole of a third world, generally Africa but parts of Asia and South America qualify as well. The child is hungry, maybe starving, disease ridden, bug infested, and destined for a life that was nasty, brutish, and short. But they’re smiling away, happy as can be, simply because they don’t know any better. Everyone they’ve ever known, seen, or even heard of has been in exactly the same boat they are. That’s just what life is like. I often times think that many programmers are just like that staving child. They put up with, indeed don’t even see anything wrong with, having to write half a dozen lines of code just to set some UI properties, because they’ve never known any better. Bug ridden, virus invested, bloated, slow, impossible to maintain, that’s just what programming is. The second post is convincing me that the situation is much, much worse than that. That it’s not just ignorance is the problem. It’s not just that many programmers don’t know any better, it’s that many programmers don’t want to know any better, and are looking for an excuse, any excuse, to stay ignorant. It’s as if that starving child doesn’t want food, and would reject food if offered. The reason that post is causing to me think this is because I’ve heard this argument before. All of them. See, I lived through the last great paradigm shift, when the industry moved from Procedural to Object Oriented- and heard the dying remnants of the one before that, from unstructured to procedural programming. I’ve heard all these arguments, or should I say excuses, before- from people trying to avoid learning C++ and Java. And excuses are what they are, because it impossible to jump through the hoops. For example: Any example of less than several thousand lines of code is a toy or a trick, and thus irrelevant. Real programs are tens or hundreds of thousands of lines long, and saving a line to two here or there is pointless. Any example more than a dozen lines long won’t be read, and thus is irrelevant. Any example that uses the advanced idioms and features of a language simply proves that the language is too weird, complex, and hard to learn. Any example that doesn’t use the advanced idioms and features of a language is irrelevant because that’s not how programmers competent in that language would write the code. Any example that is not directly applicable to what the programmer is doing right now is irrelevant, because that’s not what real programmers do. 3D rendering to games developers, server programming and database access to business logic programmers, GUI interactions to the desktop applications developer- if you’re not writing my code for me, what good are you? Comparing the productivity of different teams of developers is irrelevant because different programmers are differently capable. Comparing the productivity of the same team of developers in different languages is irrelevant because the the same programmer will be differently capable in different languages. Solving the same problem(s) in the same way(s) is irrelevant because the nature of the solution will favor one language, and that’s not how you’d solve the problem in the other language. Unless you solve the problems in different ways, in which case you’re comparing apples to oranges. Not having a ready made comparison simply means there is no proof of your biased claims. The object code produced by my compiler for my language (which has had thousands of man years of effort put into it’s optimizer) is much faster than the object code produced by your compiler for your language (the optimizer for which was written by some guy in his basement over a long weekend). And this is the way it will always be. The only way for a language to become popular is to have shelves full of books on it at your local bookstore, glossy magazines for your boss to read, thousands of programmers in the language lining up for the thousands of jobs in the language, etc. I.e. the only way for a program to become popular is to already be popular. And since your language isn’t already popular, it’ll never become popular. Your language is hard to learn. My language is easy to learn, because I already know it. People won’t learn what they don’t already know. I heard every single one of these argument used against C++ and Java back in the day. Every single one. If these arguments were valid, then we’d still be programming in Fortran and Cobol. In fact, I’d argue that we still are. What made Cobol suck so bad wasn’t the language. It was the fact that it took five lines of code to set up some UI parameters- and even more so, because the Cobol programmers didn’t abstract, did look for the general case (which is, in general, interesting), but simply replicated the five lines over and over again. I’ve done the “boring” data processing job. Turns out there’s a deep and interesting problem in the middle of that “boring” code. When I sing the praises of this language or that paradigm, I’m not trying to sell you a bill of goods, I’m offering you a way out of sucky programming. Come with me, if you dare- to a magical land full of interesting and deep problems, where drudge work is rare and quickly disposed of. A land of mystery- where the game is always afoot, Watson! Can it be done, how can it be done, can it be done better? Come with me to where programming doesn’t suck, but achieves it’s place as one of the great art forms and engineering miracles of the age. What’s the first step, you ask? Well, first you need to learn a new language…