The Economics of Programming Languages in One Short Lesson

I got tired of seeing the “Does C++ suck” title. So, I guess it’s time for new blog. I got tired of dumb radio stations on my way to work, too. I also get bored a lot working out in the gym. So, to kill the proverbial birds, I got myself an iPod Shuffle to listen to – books. It took me a while to master the art of cancellation of the external noise and now it works great – I hear anywhere between one half to a whole book a week. Recently, I was pointed to one of the Austrian School famous members, late Henry Hazlitt and his book Economics in One Lesson (also freely available online). The essence of the book is debunking the widely accepted fallacies about economy. These stem from taking into account only one social group in a short period in time, while neglecting the “big picture” – the overall, long term, impact of an imposed economic measure on the society. Communism is the prime example of how such fallacies can not survive. It has failed because it was too blatant and extreme to be sustainable long term. The fallacies have survived, though and keep on living, most obviously under the name “socialism”, but also very much present in western-type social democracy. And, although comunism is dead, things are not getting better. In essence, the idea behind the book is that economy does best when left to the laws of demand and supply to regulate it – it will optimize itself much better than any government intervention ever could hope to do. This is not to say that there should be no rules. Clearly, illegal activites are unacceptable and must be sanctioned. Immoral ones, if can’t be legislated, should and will be shunned. I can not do justice to Mr. Hazlitt here, so anyone curious about the idea should read the book – it’s a very easy and interesting read. Or, should I say “hear”?

Now, what does Hazlitt and Austrian School have to do with programming languages, one may ask? There’s something there. Programming language author (or, where applicable, standard body) is a “government” of sorts, setting the rules. Just like the government’s involvement in regulating the economy, programming language author(ity) should not get in the way of accomplishing a goal in the most efficient manner. That’s where the art of programming language economy is. That’s why as much freedom as possible in a language is good. Eventually, the programming community establishes a set of guidelines and best practices for optimally safe and efficient code. The cry “but you can do so and so in language X and people do it and it’s dangerous” is heard all the time. Certainly. You can also jump from the nearby bridge. It doesn’t make the bridge bad. Most people use it as intended – to get quickly and efficiently somewhere they need to be. It’s true that some folks jump from it. Yet nobody proposes to tear the bridge down and switch back to ferry-boats. Well, just like in economy and the bridge above, without looking at big picture, some folks jump (no pun intended) to conclusion that, due to some inappropriate use, feature X is unacceptable and must, by all means, be banned. Hence, we must quick come up with the language that will prevent X from happening. And they come with, say, garbage collected language. Which, make no mistake, is a great thing. Except when it’s mandated. And especially when it’s done in such a way that object destruction determinism is lost. With such aproach, memory management becomes easier at the expense of resource (files, connections) management becoming more difficult. Resources have to be taken care of from outside, causing additional concern and breaking encapsulation. Why not treat programmers as intelligent people and give them means to do garbage collection while letting them decide when to use it, how to use it and when and how not to use it? And then, ah those endless discusions how language X is better and shall “kill” the language Y and everyone should ditch Y because X does Z in a much better way than Y. Again, focusing on a single language feature proves nothing else but exactly that – a single thing being done better. It usually comes coupled with some other thing being done in an inferior way (think speed vs. memory requirements, for example). The overall context defines whether Language X is really better. So, goodness of a language is not solely in its one feature, it’s in all the features as a whole plus in the context (application domain, available libraries, etc) of the language as well. It turns out that it’s a pretty complex issue. Left to develop freely, the best language shall win. The most serious interference and root of many evils are corporate marketing propaganda factories, promising impossible and misguiding people with the sole purpose of locking them into proprietary technology in order to suck their money in years to come. Since it’s not illegal but it certainly is immoral to lie, they are those that should be shunned. Don’t get me wrong, I’m a firm believer in free market and I don’t mind paying. I do mind being dishonestly lured into a cage and held there against my will, though. The bottom line? Put your language out there, make it free and open and trust the programmers. Some people will do stupid things with it. Some people will create works of great value. But, whenever possible, let programmers decide what they want to do and how. Bad things will eventually go away, good things will stick and we’ll all learn valuable lessons of what to do and how as well as what not to do and why. Good programming languages will survive and thrive, bad ones will die. General-purpose languages shall have broad application domain, specialized ones will have narrow one. And that’s the best way to optimize the economy of programming languages.