Object oriented programing should die!

As should templated programing, overloaded operators and your fancy build systems and generally any of your computer programing methods which you imagine are elegant and cute. Ok maybe I am overstating this a bit. Perhaps there are some cases when it’s genuinely useful to have an object or overloaded operator. Maybe I am just very angry and frustrated after spending a week trying to build a code whose core functionality can be self contained in three small text files and whose build system takes an hour to build linking to about dozen libraries all of whom eventually break and none of which are needed. Yet these libraries are embedded in fancy objects, methods and classes whose real functionality could be accomplished using a stupid do loops, a structure with some logical switches.

I am a physicist but since every respectable scientist should be capable of coding up and simulating the physical system they are studying I have spent about half my career writing and debugging simulation code. I am old enough to remember when the evangelists of object oriented programming came preaching about the ‘good news’. They were going to make our codes wonderful, elegant and powerful. They took our simple Fortran codes and turned them into unrecognizable secret incantations of derived classes, type-casted functions and virtual functions. There is nothing more cruel than not knowing where and which function you are ‘really’ using when it is broken.

Next they came for our simple make file. We needed cmake lists, builders automatically figuring out all the libraries, building and linking everything one could ever need. They would do everything for us, except when it didn’t, in which case you loose. They gave us code which writes code..endless layers of complexity. It seems every time a ‘well trained’ computer scientists or physicists turned computer scientist would touch our codes there would blossom levels of complexity and obfuscation which if left unchecked would suffocate your code and then consume all your time to maintain and debug.

In order to deter any future programmers wanting to bring their ‘elegance’ to our codes, I have decide to lay out my poor physicist’s rules of coding:

1. All codes will break especially codes under active and continuous development: Yes all code will one day not work. Either an update to the OS, libraries or something else will break the code one day and sooner than you think. If your code is under active development then for sure it will be broken, probably at least once every several commits. It will break regardless of how clever and thorough your regression system is. Since all code breaks then fixing and maintaining a code base is what will ultimately consume most of your resources. This gets to my second point.
2. Simplicity and comprehension of code should take precedence over any thought of elegance and compactness. If you can use a stupid for or do loop then do it, don’t give me iterators, or overloaded functions. You see since this code will break, some poor person one day will have to understand which function broke and when in the chain of program logic. This sort of crap makes that job infinitely harder and for what? It looks cool, I know I understand that. It makes you feel smart. But not everyone is so smart as you and they will have to read and fix this elegant monster.
3. Don’t make your code do everything. Many codes start humbly enough, they do one thing and then a computer scientist gets a hold of it and now it integrates using all the integrators known to man, cooks for you, watches your weight and so on. In the end all this murders the core usefulness of the code. Do one thing well.

To illustrate all this I will tell you a story:

Once there was venerable elderly physicist who had over many years created a useful code to model a specific sort of physics. Written in Fortran, he had built it up into a fairly useful tool adding more and more details of the physics he was modeling. Then came along a computer programer, he promised to put his tool into this grand code which would model everything. In the course of a year he took this code and rendered it unrecognizable buried in levels and levels of derived classes, iterators, virtual functions linking to libraries and parsers upon parsers upon parsers. This brand new code worked for while, the computer scientist proclaimed success and moved on to ‘improve’ more codes..until it didn’t. It stop building on some systems, but the physicist didn’t want to go back to his old code since in the meantime he had added some more useful physics to the core code, solved some important modeling problems and he already had his simulations set up for this code.

Then another group of computer scientists came along. They were going to fix this code more..make it work on more platforms and types of processors, parallelize it, improve the build system. In the meantime more useful physics was added to do things that needed to be done. It became an even bigger monster and worked for a while. But every time a brand new build was required, it took at least a week of consulting and tweaking the ‘super-smart’ build system to make it build. Now after several years of these improvements to build systems and Byzantinely written classes, the good physics and integrators lie trapped in this beast, unable to be built, waiting to be liberated from this monster.