During the last decades a lot of technologies were identified of being harmful. Dijkstra began with identifying the Goto statement of being harmful in the 60s. Since then several other harmful technologies were identified. People understood that if-statements should all be replaced by polymorphism (I remember a professor who gave every exam a ‘fail’ that contained an if-statement in the late 90s). Also the new-statement is harmful in real-time systems and I remember an old boss who told the whole team not to use the new-statement in a 100.000 LOC server application written in C#, having – as it’s the nature of C# – new-operations splattered all over the place … challenging … 🙂
But that wasn’t all. Robert C. Martin interestingly mentioned the book ‘structure and interpretation of computer programs’ in one of his on-line lectures and the paradigm of a functional programming language to avoid assignment statements. Which makes perfectly sense in that context. So even an assignment can be considered as being harmful.
What else ? Recently plain threads were considered being harmful in a keynote of Hartmut Kaiser. Off course, no one likes threads in a context where it should be avoided, not to mention the thread-per-object anti pattern (which I first read in one of my most favored books, Utas “Robust Communications Software”). Once I saw an application that utilized three threads per instance of connected hardware. The original version was written for 30 remote devices, leading to 90 threads. A few years later the managers decided to use this software for a huge installation of 2000 devices, leading to 6000 threads, with 512 KB stack space for every thread, which is close to 3 GB RAM in total. That didn’t work out very well on a 32 bit processor 😉 OK, so plain threads are evil too.
Up to now several other technologies have been identified of ‘being harmful’. Things like ‘recursive make’ or static linking, csh programming … The identification of harmful technologies has even its own wikipedia page today: http://en.wikipedia.org/wiki/Considered_harmful
Well, and today is the day I will identify another harmful technology and introduce it to the whole world: Calling member functions is considered harmful !
We all know this situation. A perfectly functioning and bug-free piece of code is extended by a call to a member function of another object. It appears that this change introduces a big risk to the robustness of the function. In a significant amount of cases (as shown below) adding a function call will lead to a software failure. This is caused by the unpredictable nature of object orientated code that hides functionality in abstractions that are never able to fully reflect all underlying details (otherwise it wouldn’t be an abstraction, right ?).
Calling member functions significantly widens – and this way worsens – the fan-in and fan-out of functionality. The amount of overall system state is greatly increased because not only the local state (reflected by the local variables) is taken into account for the program’s execution at this place. Instead also the full state of the called function has to be regarded as well. This tremendously increases complexity, which this way easily rises beyond what a human brain is able to understand.
This technology becomes absolutely unrulable and high-risk, when the called member function itself again calls a member function. This increases the amount of state information even more, and the more state information is involved, the more software failures will appear, as can be shown easily by popular studies. Now imagine that this function also again calls more member functions and this functions call again other ones … Such practice renders a software totally unmanageable. Imagine what could happen if a function calls a function again, that was already part of the call-stack before. Or if a function calls itself again, leading possibly to a vicious recursion. Furthermore the same part of source code can be reached from virtually innumerable other functions, leading to a virtually random sequence of calling orders and a virtually unlimited number of possible different call-stacks. This situation is practically impossible to be tested. Such software is out of control.
It is obvious that the only way to cope with this situation is to prohibit all kinds of member function calls, and – which is most important – today is April the 1st 2015, and in our culture it is tradition to write funny articles at this date. So don’t take this text seriously and if you discover more technology to be harmful (e.g. variables, braces, objects, executables, for-loops, method parameters, void …) just let me know 🙂