Overview
Features
Download
Documentation
Community
Add-Ons & Services
The POCO C++ Libraries Blog

The Economics of Programming Languages in One Short Lesson

Filed under: Uncategorized by alex at 22:47

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.

7 Comments »
  1. On the topic of economics and programming languages, also see Arch D. Robinson’s excellent paper, “The Impact of Economics on Compiler Optimization”:

    http://www.eecg.toronto.edu/~tsa/crgpapers/arch.pdf

    Comment by Andre Pang on March 19, 2007, 17:09

  2. So would you be happy if the delete keyword in C++ was changed to not check for a null pointer? After all, it’s more freedom to the programmer, and you won’t suffer that mandated performance hit…

    Comment by Andre Pang on March 19, 2007, 17:38

  3. delete is fine as is. Those who mind the delete’s performance penalty can use malloc/free. But, in the end, if you want to be safe, one way or the other, you have to check your pointers. That’s just the nature of the beast and has nothing to do with language.

    P.S. I’m writing from Santa Clara, attending “Stroustrup and Sutter on C++”. Maybe I should ask for their opinion about this ;-)

    Comment by alex on March 20, 2007, 06:57

  4. Also, new and delete are very malleable in order to suit various needs. That is the kind of freedom I’m advocating, not the blind (and dumb) “performance at any price” attitude.

    Comment by alex on March 20, 2007, 07:25

  5. An update: Not that I really intended to, but even if I had I would not have to ask because the answer actually came on one of the Stroustrup’s morning session slides:

    “If you don’t care about correctness, I can make it as fast as you want.”

    Comment by alex on March 21, 2007, 17:21

  6. What exactly does correctness mean? Is it the same as reliable in the sense of producing predictable, consistent result or in the sense of no random crashes?
    I am sure I heard the term “correctness” on many occasions but I really don’t know what it means.

    Comment by paschal on March 22, 2007, 14:13

  7. There are many “flavors” of correctness. What I meant in this context was: yes, you can skip checking for null pointer and make code run faster, but you are significantly increasing your chances for failure.

    Comment by alex on March 22, 2007, 23:39

RSS RSS feed for comments on this post. TrackBack URI

Leave a comment