Tuesday, June 19, 2012

Money matters

I never thought that any development in Graph Theory would have anything to do with war between countries. But it seems to. Sometime during the cold war era, the Americans were solving the problem of how to break up the extensive soviet railroad network with the least effort. So which are the places to bomb and destroy railway lines such that there is a maximum disconnect between railway stations ? You just find a "min-cut" for the graph of towns and connecting railway lines. The same min-cut helps in efficiently blowing up oil pipelines and electricity supply as well. And so, in due course of time, we got a few more pages added to the book of the Theory of Graphs.

Well, the deeper point is notice what motivates innovation. During times such as the cold war, innovation in America was driven by a country-wide feeling of competition, threat, fear or maybe mass hysteria. It can lead people to work harder and think harder. There was rapid development in not just missile technologies but also space missions, electronics, energy and of course, computing. Now, the cold war is over and the emotions have cooled down. But people are still doing smart things.

My guess is this. I feel that the collective demographic feelings can only partly explain the rapid developments in that period or any period. For any creative effort to truly succeed, someone has to finance all the efforts. In that period, the governments were rather generous in funding research into all areas that were deemed important. So a lot of money went into missions to the moon and it bore spectacular results. Today, the money is flowing into different areas and that is where all the action is happening. The things that people value can change from time to time but the research projects which click are the ones where the funding is active. Of course, people can build great things without much money (software) or without much secrecy (Open Source Software). But they won't be able to send a man to Mars and certainly cannot build a controlled nuclear fusion reactor. My point is that development is not stalled because of limits of human intellect, but because nobody really values it enough to spend hard-earned money on it.

An article by an astrophysicist named Neil Tyson here makes the same point very elegantly. Elected governments may say that their first priority is to build "clean and green" renewable energy projects but how can we find if the powerful folks really serious about it ? I'd simply look at the kind of money they are spending on it.

Monday, February 13, 2012

Monstrosity as in C++

I am writing this piece out of a renewed terror of C++, particularly after reading some of the items from "Effective C++/More Effective C++" by Scott Meyers (http://aristeia.com/books.html) and now moving on to "Modern C++ Design" by Andrei Alexandrescu (http://www.moderncppdesign.com).
I have been using C++ for practically most of the last 10 years but it still succeeds in throwing up dark corner cases and quirks. Particularly jarring are some of them which go against my intuition of how the code should behave. My experience is in the same vein as here and here. More criticism of C++ is easily found all over the web, some of it coming from star programmers like Linus Torvalds as well. Whenever I am comfortable with using C++ and reading C++ code, it is just when the code uses the small sub-set of C++ that I use and I know. And everyone just seems to use their own favorite sub-set of C++.
An example is the items in the books by Meyers. Many of them are very informative and it never feels like a drab listing, thanks to the lively style of Meyers' writing. Most appreciable are items about class design and efficiency matters. In contrast, most troubling items are those that attempt to explain, cope with or "engineer" around C++ syntax. Operator overloading still tops my list of nonsense and unnecessary features. If it’s just syntactic sugar, it is making everyone a diabetic.
To be fair, C++ has had to deal with supporting new features as well as maintaining backward compatibility with C. It is feature-rich and multi-paradigm. It seems that individual features of C++ like Classes, Inheritance, Templates, Exception Handling and others are very useful and well thought of. However, when these facilities combine in a real world code, they have a devastating effect. Explanations of smart "techniques" to somehow handle each and every combination case increasingly venture into the territory of the obscure and the ugly. Lack of garbage collection and memory/system issues only worsen the situation. So when Meyers tries to work out such complex issues, it just strikes me that such situations should just be avoided at all costs. There should be simpler ways of doing such things. Knowing C++, it is apparent that there would be many ways of doing the same thing, some simple, others not so.
I hope to write something more over the next weeks about C++ and particularly, "simpler" ways of doing things and anything truly useful, like compile time checks.