The love affair with OOP needs to end

IOT (Internet of Things), maker devices (ie. Raspberry PI like devices) and mobile PC devices (ie. phablet) all require software which can perform on minimal hardware. So how does one get such performance ? How can the hobby (“maker”) developers be helped to produce better software ? How can software be improved in reliability ? And what does all of this have to do with Object Oriented programming ?

There is no easy way to say this.

The love affair with OOP needs to end. Now I don’t mean all OOP is bad, nor do I mean that OOP should be gotten ridden of.  In its proper place, OOP can be useful. The problem is that rather than simply being a useful feature of a programming language, sadly it has grown out of proportion and has become the one and only way to code for most developers. When OOP was first introduced, they “promised the moon” , giving the idea that OOP would solve all problems. Now that the honeymoon is over and reality has set in, one finds that OOP has its own baggage that comes along with it. To illustrate:  It is kind of like physical tools. Have you ever watched one of those infomercials about some kind of “do it all” tool which replaces almost every tool in your toolbox ? They promise that it does “everything” and that you can get rid of all those other “useless” old fashioned tools. So one puts down their hard earned money and buys into the idea of the “does everything tool”. After awhile though one finds that, while it may be useful, the ‘does everything tool” has many limitations and often the old fashioned tool we got rid of actually did a better job. At times even the old fashioned hand tools (ie. hammer, hand saw, etc.) do a superior job compared to their so called “super powered” counterpart. It is the same with programming tools.

Procedural programming is tried and true

Whether most want to admit it or not, procedural style coding is a tried and true method of coding. True, at times some OOP may solve some problems or make things easier, but in many cases a procedural style of coding can do just as well, but with a few advantages. Procedural coding often produces smaller and faster applications. Procedural coding at times may even be easier to maintain and it tends to produce code which is much easier to follow the code flow. Just compare the difference between an old time pure C programmer’s software and a more modern C++ programmers software. While C++ can do as well as pure C at times, it is so easy to get caught up with all the OOP stuff that one falls into the “OOP does everything trap” and before you know it, the software gets more complicated and it loses some of its performance benefits. Other programming languages have the same problem. In the BASIC world, often once some go down the path of OOP, it is easy to fall into the trap of OOP does everything and some versions of BASIC are more OOP oriented than others. OOP needs to be relegated back to simply just another tool in the toolbox.

Does it really matter ?

Yes, it does. Now much of what I am saying may be more of a personal perspective for some people, but it is worth considering the option of what might be called “hybrid” programming. What is hybrid programming ? It is the willingness to use whatever fits best for the task at hand, even if it means merging different styles of coding into one application or even using different styles for different applications. Now some may think, isn’t modular design more important and isn’t OOP the best way to produce modular software ? This is the perfect example of how one can easily “not see the forest because of the trees” as they say. One can get so caught up with the idea of modular design, they may fail to realize that procedural coding can also be used to write modular software. The difference though is that procedural coding uses functions and procedures (subroutines) to make code modular, while OOP uses classes, methods and properties. Procedural software can be modular. One can have code reuse with procedural code. Us old time programmers call those procedural modules, “libraries” (have you forgetten about them?).  The problem with procedural coding is that building libraries is a decision of the programmer, while OOP (classes) forces modular design. So a simple question needs to be asked: Rather than force modular design by the use of OOP, why aren’t we teaching procedural style programmers how to build quality libraries ? Also, why can’t we at times use classes for modular design when it makes sense and use procedural libraries when it makes sense ?

Principles versus laws

A principle is far more powerful and meaningful than is a law. A law may force a person to do something, but it fails to take into consideration those cases where the law may be too limited in scope to handle the issues. A principle is a concept where it provides basic guidance of the reasons or motives for some general problem, but it can handle a greater scope than a fixed law. In programming, something similar can be done. Rather than force modular design by a “law”, or object oriented programming, would it not be better to define a principle of the need to design modular code which can be reused. So when OOP fits, use it. So when procedural style coding fits better, use it, but using the principle of modular design. One can just as easily build a flat API library as one can a class library.

IOT in particular can benefit from going back to procedural style coding

IOT in particular can benefit greatly from using procedural style coding when it makes sense. IOT more so than other situations requires getting the maximum performance using the least amount of system resources (CPU, memory, disk space, etc.) For example, there is no reason why a true Windows 10 (x86) based device could not be made, which supports the full features of Windows on an extremely small device with minimal hardware. Pull out all the OOP stuff, especially DOT.NET and the WINRT and then build procedural libraries on top of the WIN32 flat API and I see no reason why applications for IOT devices could not deliver a full GUI experience on an Intel platform with one quarter the power of the current minimal Atom SOC platforms. Having been a WIN32 programmer for nearly 2 decades and using a programming language designed to work with minimal hardware, I have absolute confidence this can be done.

The proof is in the pudding

Some may laugh and say this is all conjecture. Actually it is a reality. Long time, pure, C programmers and even long time BASIC programmers like myself, likely know how much they can accomplish using just a simple native code compiler and a procedural coding style along with well written libraries. The “proof is in the pudding” as they say. Forgive me for using my own work, but it is the only way I can demonstrate what I am saying. Likely many C (and even BASIC) programmers out there could offer up their own work as examples of what I am saying as proof that using native code compilers and a procedural style library can produce very small and fast applications which can run on minimal hardware.  Here is my own example and hopefully some who comment can provide other examples.

Download the following WIN32 test app I wrote:

Windows API test app

The zip file is only 3.8 megabytes in size. First, try some tests with the app on the slowest Windows device (x86) you have access to (CPU as low as 500 MHZ or less, if you like) . Run the app on a Windows device with the least amount of RAM and disk space you can. Even try it on some legacy computers running Windows XP with as little RAM as 256 megabytes (or less). Note: it does require support for OpenGL 1.0/2.0 for the 3D stuff on your device.

Now examine the app itself. The EXE is only about 170 kilobytes in size. If you have the Dependency Walker utility, check to see what dependencies the EXE has. Aside from a few core operating system DLL’s, it only uses the supplied GUI framework (written in Powerbasic and calling the WIN32 API) which is only about 1 megabyte in total size (a few DLL’s). No MFC is used. No ATL is used. No dot.net. The GUI framework demonstrates the use of a procedural style API (flat API), rather than a class based API. The test app only demonstrates a few features built into the GUI framework, but maybe you can see more from examing the help file for the GUI framework (sorry, but the framework only works with Powerbasic, so most of you can’t use it). The GUI framework is just a standard procedural style Windows DLL (actually 3 key DLL’s and two extra DLLs to store images). The entire 3D engine is contained in a 230 KB sized DLL. The point of this demonstration is simple, to show you how much you can pack into a simple procedural style library (DLL). Now compare the size of this procedural GUI framework library even to the smallest OOP based (class) UI library you use today. Even something as small as MFC (Microsoft Foundation Classes) is 3 to 4 times larger than the procedural GUI framework this test app uses. Yes, the entire GUI framework can fit on an old fashioned floppy disk, so imagine how GUI frameworks built using pure C and a procedural style of coding (a flat API) could change things for IOT devices running Windows today.

Why not C (or BASIC, or Fortran, etc.) ?

First watch this must see video of Herb Sutters talk, “Why C++ ?”

Why C++ ? talk on Channel 9

The point about native code compiling is highlighted in this talk. The need for smaller, faster software is brought to the fore. But I will go one step further than “why C++?” but “why not C” (or any other procedural language). While using a native code compiler like C++ may produce significant performance improvements, I would venture to say that using a native code compiler like pure C (or Powerbasic for BASIC programmers) using a procedural style of coding could provide even greater performance benefits. You never know unless you try.