The Software Developer

The last decade has seen object oriented programming (OOP) dominate the programming world. While there is no doubt that there are benefits of OOP, some programmers question whether OOP has been over rated and ponder whether alternate styles of coding are worth pursuing. To even suggest that OOP has in some way failed to produce the quality software we all desire could in some instances cost a programmer his job, so why even ask the question ?

Quality software is the goal.

Likely all programmers can agree that we all want to produce quality software. We would like to be able to produce software faster, make it more reliable and improve its performance. So with such goals in mind, shouldn’t we be willing to at least consider all possibilities ? Also it is reasonable to conclude that no single tool can match all situations. For example, while few programmers today would even consider using assembler, there are times when low level coding such as assembler could be warranted. The old adage applies “the right tool for the job”. So it is fair to pose the question, “Has OOP been over used to the point of trying to make it some kind of universal tool, even when it may not fit a job very well ?”

Others are asking the same question.

I won’t go into detail about what others have said about object oriented programming, but I will simply post some links to some interesting comments by others about OOP.

Richard Mansfield

http://www.4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf

Intel Blog:  by Asaf Shelly

http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/

Usenix article:  by Stephen C. Johnson (Melismatic Software)

http://static.usenix.org/publications/library/proceedings/sf94/johnson.html

Department of Computer. Science and IT, University of Jammu

http://www.csjournals.com/IJCSC/PDF1-2/9..pdf

An aspect which may be overlooked.

I have watched a number of videos online and read a number of articles by programmers about different concepts in programming. When OOP is discussed they talk about thinks like modeling the real world, abtractions, etc. But two things are often missing in such discussions, which I will discuss here. These two aspects greatly affect programming, but may not be discussed.

First is, what is programming really ? Programming is a method of using some kind of human readable language to generate machine code (or scripts eventually read by machine code) so one can make a computer do a task. Looking back at all the years I have been programming, the most profound thing I have ever learned about programming was machine language. Seeing what a CPU is actually doing with our programs provides a great deal of insight. It helps one understand why integer arithmetic is so much faster than floating point. It helps one understand what graphics is really all about (simply the moving around a lot of pixels or blocks of four bytes). It helps one understand what a procedure really must do to have parameters passed. It helps one understand why a string is simply a block of bytes (or double bytes for unicode). It helps one understand why we use bytes so much and what bit flags are and what pointers are.

When one looks at OOP from the perspective of machine code and all the work a compiler must do to convert things like classes and objects into something the machine can work with, then one very quickly begins to see that OOP adds significant overhead to an application. Also if a programmer comes from a background of working with assembler, where keeping things simple is critical to writing maintainable code, one may wonder if OOP is improving coding or making it more complicated.

Second, is the often said rule of “keep it simple”. This applies to programming. Consider classic Visual Basic. One of the reasons it was so popular was that it was so simple compared to other languages, say C for example. I know what is involved in writing a pure old fashioned WIN32 application using the Windows API and it is not simple, nor is it intuitive. Visual Basic took much of that complexity and made it simple. Now Visual Basic was sort of OOP based, but actually mostly in the GUI command set. One could actually write all the rest of the code using purely procedural style code and likely many did just that. I would venture to say that when Visual Basic went the way of dot.net, it left behind many programmers who simply wanted to keep it simple. Not that they were poor programmers who didn’t want to learn something new, but that they knew the value of simple and taking that away took away a core aspect of their programming mindset.

Another aspect of simple is also seen in the syntax of some programming languages. For example, BASIC has stood the test of time and continues to be the language of choice for many hobby programmers. If you don’t think that BASIC is still alive and well, take a look at this extensive list of different BASIC programming languages.

http://basic.mindteq.com/index.php?i=full

While some of these BASICs are object oriented, many of them are also procedural in nature. But the key here is simplicity. Natural readable code.

Simple and low level can work together.

Now consider this. What happens when you combine a simple language with the power of machine language ? You get something very powerful. For example, I write some very complex code using purely procedural style coding, using BASIC, but you may be surprised that my appreciation for machine language (or assembler) also comes to the fore. For example, I use the BASIC language GOTO and GOSUB. How some would cringe to hear this. But these constructs are native to machine language and very useful, so when used properly they are powerful even in a high level language. Another example is that I like to use pointers a lot. Oh how powerful pointers are. In BASIC I can create variable length strings (which are simply a block of bytes) and I can embed complex structures into those strings by using pointers. In BASIC I use the DIM AT command, which allows me to dimension an array of any fixed data type or structure within a block of memory, which in this case happens to be a string.

Appreciating machine code also affects my view of performance. Every CPU cycle counts. This is one reason I use BASICs GOSUB command. It allows me to write some reusable code within a procedure, without the need to call an external routine and pass parameters. The performance improvement is significant. Performance also affects how I tackle a problem. While I want code to be simple, I also want it to run as fast as possible, so amazingly some of the best performance tips have to do with keeping code simple, with minimal overhead and also understanding what the machine code must accomplish to do with what I have written in a higher level language. For example in BASIC I have a number of options for the SELECT CASE structure. One option can optimize the code using jump tables (compiler handles this), one option can optimize if the values are only Integers or DWords. But even then the compiler can only do so much. What happens if a large SELECT CASE has to compare dozens and dozens of string constants to a variable length string being tested ? If this code is part of a parser, then it really can slow things down. I had this problem in a scripting language I created for an OpenGL based 3D custom control. The 3D scripting language is text based and has to be interpreted to generate 3D OpenGL calls internally. I didn’t want the scripting language to bog things down. So what would I do ?

The solution was simple and appreciating how the compiled machine code would have to compare so many bytes in so many string constants, one quickly realized that the compiler alone could not solve this. I had to think like I was an assembler programmer, but still use a high level language. The solution was so simple, it was surprising. I could use a pointer to read the first byte of the string being parsed. Since the first character would always be a letter in the scripting language, this meant there were 26 possible outcomes. The SELECT CASE simply tested for the first character value (convert to a number) which would execute fast. Then for each letter (A,B,C, …) I would only compare the parsed word to the scripting language keywords which started with that letter. This in essence improved speed by 26 fold (or better).

The fastest solutions are often very simple to code. No complex classes needed here. Just a simple procedure to read through a text string using the simplest logic I could find. The procedure is a little more complex than what I describe, but this is the core logic of the routine.

From experience, I have found that a purely procedural style of coding, using a language which is natural and simple (BASIC), while using constructs of the language which are closer to pure machine (or assembler) in the language produces smaller and faster applications which are also easier to maintain.

Now I am not saying that all OOP is bad. Nor am I saying that OOP never has a place in programming. What I am saying though is that it is worth considering the possiblity that OOP is not always the best solution and that there are other choices.

Here are some of my other blog articles which may interest you if this one interested you:

Classic Visual Basic’s end marked a key change in software development.

http://cwsof.com/blog/?p=608

Is software development too complex today ?

http://cwsof.com/blog/?p=579

BASIC, OOP and Learning programming in the 21st century !

http://cwsof.com/blog/?p=252

Why BASIC ?

http://cwsof.com/blog/?p=171

Reliable Software !

http://cwsof.com/blog/?p=148

Maybe a shift in software development is required ?

http://cwsof.com/blog/?p=134

Stop being a programmer for a moment !

http://cwsof.com/blog/?p=36

With Windows 8 soon to be released, while I look forward to the benefits of Windows 8 for touch devices (aka. tablets), I am also sad about the direction software development is going in. The Metro UI may be nice for consumer apps, but the sandbox approach in my opinion limits creativity for two reasons. One is the forced user interface. The idea of all apps being so flat in nature, no multiple windows and always having to click a BACK arrow button to navigate a user interface, somehow does not feel creative and it lacks variety. The second is the state of development tools. The over dependence upon object oriented programming methods has made software development more complex, not less.

What first excited me about the computer was the possiblities. Even back in the days of the Commodore 64, with its limited power, it seemed like the possiblities were endless. I was amazed when some very talented programmers created the Geos environment for the Commodore 64. Geos was written in assembler of all things and the power it unleashed from this computer was just astounding. Today we have computers which have CPU’s with a thousand times more power than the C64, over 50 thousand times more memory and more than a million times as much disk space and yet the PC seems more limited than ever. Where is the performance we should have ? Where is the ease of development we should have ?

Yes, the power of the PC has been lost, rather than found. True there is some really amazing software today, but in comparison to the software of the past in the early days of the PC, I find less and less than really makes an impression. Software development has become more complicated too. By changing programming technologies every few years, we tend to throw away quality code which may have taken months or even years to develop. That is counter productive, not progress. In a world where we have the most advanced technology for something like farming than ever in history, yet millions are still starving. Why ? Because of waste. Software development is similar. As computer technology improves year after year, we also have a great deal of waste. Visual Basic was simply gutted and replaced by a totally foreign language (VB.NET), wasting the resources of years of VB development, despite the fact that Visual Basic was one of the most popular programming languages ever.

The reason I program in PowerBasic, despite all the hype about Visual Studio and the latest Microsoft tools, is because I want a language which is simple, natural and familiar. I want to be able to code with a language I have known for years rather to have to keep changing languages and coding styles year after year. Yet, despite is being a language which has been around for decades (BASIC) it continues to grow and to provide more and more of the power of the PC. It was interesting how when I wrote articles for BetaNews.com that when ever I mentioned Basic, I got a lot of grief from readers who considered me old fashioned and out of touch. One of those readers though was intrigued by regular comments about Basic, especially PowerBasic and one he day he decided to purchase PowerBasic and try it. He posted a comment on one of my articles about his experience and simple put, he was surprised. Why ? Because PowerBasic was more powerful than he imagined and it was refreshing to use a real compiler which produces fast and small applications.

The reason PowerBasic continues to improve is because it does not leave behind the past. I maintains compatibility with some very old Basics, yet has features only found in more modern languages. It also is very low level, so one can have complete control of what an application does. You don’t have to use pointers for variables, but they are there if you want them. You don’t have to code in assembler, but inline assembler is there is you want it. The point is that every new version of PowerBasic gives you more and more power to control a PC.

Also my own GUI tool, EZGUI, is in its fifth generation (written in PowerBasic) and while RAD development and ease of use are primary goals, the ability to access the power of the PC has also been an important goal. This is why EZGUI is both low level and high level. Yes, even the low level stuff has been made easier by eliminating much of the mundane stuff which one really should not have to worry about, yet there is a lot of low level capabilities in EZGUI. Backward compatibility has also been a high priority. Each new version maintains compatiblity with previous versions as much as possible. Customization has also be important. Rather than treat everything as some kind of blackbox which is unchangable, I found making ways to customize things open the doors to more possiblities. Windows ability to customize has been there since Windows 95 and it is still there in Windows 8, yet few programmers take advantage of it. The common dialogs can be customized. Controls can be customized. You can build your own controls with unique features using existing controls as a base class (window class, not code class). You cany build your controls from scratch too.

I wrote EZGUI 5.0 without any object oriented coding at all and it still amazes customers the amount of power in such a small library. What has contributed to this has been the use of procedural style coding rather than using OOP, modular design (code reuse) and the Powerbasic compiler (produces small and fast executables). Also my desire to always keep tapping into the power of the PC has made a difference. For example the Windows API has had its DIB (device indepedent bitmaps) engine since Windows 95, yet it amazes me how it provides so much power and control when drawing bitmaps. I used it to build my sprite engine. I used it to add image filters for drawing bitmaps. I have also been impressed with the power (and ease of use) of OpenGL. Fortunately video card (GPU) manufacturers, despite the fact the OpenGL 3 and 4 have deprecated much of OpenGL’s original API’s were smart enough to maintain backward compatibility with OpenGL 1 and 2. Backward compatibility makes a lot of sense. Backward compatibility is productive, benefiting from the old while still being able to add the new.

Programming languages need to go back to the basics (a pun of course). They need to be made simpler. They also need to go back to being real compilers again (nothing beats optimized native code). While I understand the need for scripting languages for cross platform development, when it comes to native apps nothing can beat quality generated machine code. We as programmers need to be less wasteful. Just becauses modern CPU’s are super fast, does not mean that counting CPU cycles (compiler makers) is no longer important. Just because we have huge amounts of disk space does not mean that we should waste that space. Programmers should start experimenting with going back to the basics of procedural coding styles to see if it can produce smaller and faster (and easier to maintain) applications. Sure, you can use OOP once it awhile when it really might be useful, but you may be surprised at how efficient procedural coding can be.

Programmers often criticize procedural coding styles by using terms like “spagetti code”. Guess what ? A modern Basic using procedural coding is not spagetti code and can be just as modular as any OOP written code. The term “spaggetti code” comes from the days of interpretted Basic before Basic provided subroutines or functions. The make code modular using that kind of basic required a lot of GOTO’s and GOSUB’s along with line numbers used for labels rather than real names. Modern Basic has come a long way from there.  Modern Basics, like PowerBasic, can be used to produce extremely modular code. I know, because my entire GUI library is based on modular design. This is why it is so efficient with so many features packed into such a small size.

So this programmer will be coding for the Desktop side of Windows 8, since it currently provides me with more access to the power of the PC. I will be as helpful as possible with the people at PowerBasic to help them eventually move to Metro (Windows Store apps) and I hope they can produce a compiler which does for Metro what PowerBasic does for the Desktop (Windows in general). The important thing though is to provide programmers as much access to the power of the PC as possible.

To answer this question in one word:

Simplicity !

What do I mean ?

To be honest I get tired of negative comments by mainstream programmers when I ever mention that I program in Basic. Actually I program in a modern high powered Basic called PowerBasic.  Everybody today seems to program in C#, Javascript or some other cryptic language. The majority assume that variations on C (C++, C#,Java) provide the most power when it comes to programming, but they miss the boat on one key aspect which is simplicity. This is why I prefer Basic over other languages. The code is readable and simple. There is no need for brackets to align code. It uses operators which are very similar to we learn in school when learning math (of course X is a alphabetic character so it needs to be replaced with something else such as * for multiplication). The one thing which I have always felt is important when coding is simplicity. The less lines of code necessary to accomplish a task the better. The closer code is to human language the better. The easier it is to remember code syntax and common parameters the better. The simpler a library is the better.

This is one reason I also object to the overuse of OOP (Object Oriented Programming). Don’t get me wrong, the ability to write classes and to create reusable objects is a valuable asset to a programming language, which is why PowerBasic added it to its compilers. The problem is that while objects have their place, they should not rule the language. In todays modern languages, it seems everything is an object, everything is written in classes. This is a big mistake and I strongly feel that it leads to two serious problems with modern software.

(1) Overly complex software.

The more complex software is the harder it is to write and the harder it is to maintain. Some would argue that OOP makes software easier to work with not harder, but I do not believe this. I strongly feel that procedural based API’s produce easier to understand code and can be written more quickly and they can be more easily maintained. For OOP to work it requires too much thought up front and often it produces an overly complex solution for something which could have been done using a much simpler solution using a procedural method. The obvious proof of how OOP has made software overly complex is the fact that most software today is bloated and slow, despite the improvements made in computer hardware. I really don’t think this can be denied.

There is another aspect to this which I think is important. The more exposure one has to how a computer really works at its lowest level the more one can appreciate what a higher level language really must and is doing. Before the IBM PC became popular, I was learning programming on a Commodore 64. I used interpreted Basic. I also used the Abacus Basic compiler (yes, there were Basic compilers in those days). But I also finally started learning 6502 machine language (not assembler, but real machine language). Learning machine language was extremely valuable in appreciating what the higher level programming languages were actually doing. I wrote some extensions to the Basic interpreter to add more commands to the language. I even wrote my own compiler, so I could write the fastest software possible. The compiler was very BASIC like in nature too.

Having worked with machine language it helps me appreciate why many programmers today don’t full appreciate the effects OOP has produced on programming languages. While I do not understand why so many programmers are drawn to languages which are overly abstract (like C++, C#), I do feel that maybe it would be good to encourage the software industry to rethink its love affair with the abtsract. Have you ever notice that when programmers talk about the superiority of C++ over other languages they often refer to the term “abtraction”. Herb Sutter in one of his talks about C++ likes to use the term abtraction as if it is good thing.

One definition of Abstract is:

“Existing only in concept and not in reality”

So why do programmers think that an abtraction is closer to reality ? Now I can see how an abtraction (OOP) may be useful for something that does not actually exist yet, but why would one want to use abstractions to explain the real world or to do real world tasks all the time ?

If I have to write software which does accounting , which is a real world concept, then writing simple code which does accounting math is all I need. Even accounting data does not require objects. Data is data. Accounting data can easily be defined using data types or structures, which is what most closely resembles it. If the data can change, then simply use dynamic data types to allow such changes, but data is still data.

The overuse of OOP , as well as other overly complex development methods has also causes us to lose a precious thing in our software and that is performance.

(2) Lack of Performance.

Simplicity is also key to performance. Simply put, the less work a CPU has to do to accomplish a task, the faster the task is finished. The more complex our code is the more work the computer has to do. Now many would likely take issue with this and say “we are more productive today and our software is plenty fast enough”. I would strongly disagree. Do we really appreciate how powerful computers (even a phone) are today ? I was developing software when computers only had floppy drives (no harddrive), had only 640 KB memory and CPU’s which were less than 25 mhz in speed. Even in the early days of DOS, harddrives were only a few megabytes in size (ie. 20 meg), memory was less than 1 megabyte and CPU’s were slow. Yet programmers could write applications which handled many complex real world tasks. Today the average computer has a CPU which is 1 to 2 ghz in speed and multicore, with really fast GPU’s or Graphic cards, with 2 to 4 gigabytes of memory and harddrives with half a terabyte of space. Yet software is bloated and slow.

Obviously something is wrong. The only answer is how we write software. Possibly OOP plays a big part. Maybe system frameworks are poorly designed. The point is that software need not be so poorly written that it requires huge hardware resources. Maybe all the extra abtraction added to programming languages is producing slow and bloated software.

Having spent the last ten years writing a GUI engine I can appreciate the value of “small and fast”. The original version of EZGUI had a runtime DLL which was 122 KB in size. Now that is kilobytes, not megabytes. Oh how I thought that was so huge ! Today the main EZGUI 5.0 runtime DLL is about 700 KB in size and again felt it was too big by my own standards. Yet when I think about how many features are compacted into that DLL it is amazing that it is as small as it is. I give the credit to Powerbasic for their wonderful compiler. But I also have to say that because it was written using a purely procedural style of coding with no OOP (abtraction) used at all, this I believe was a significant reason why it is as small as it is. Now when you combine the EZGUI 5.0 main runtime with the few other secondary DLL’s that come with it, the total is about 1 megabyte.

Now compare this with say the Visual Basic 5.0 runtimes:

msvbvm50.dll – 1324 KB

comdlg32.ocx – 150 KB

comctl32.ocx – 595 KB

comct232.ocx – 161 KB

mscomct2.ocx – 633 KB

richtx32.ocx – 208 KB

Just to be able to have the support for basic forms and controls plus some of the standard common controls and dialogs, these runtimes totaled  3071 KB (over 3 meg)

Yet at about 1 megabyte (or 1/3 the size of the above VB runtimes) EZGUI has the support for the basic GUI features of the VB runtime, plus the following:

• Thread engine
• Subclass engine
• Drag and Drop engine (build your own WYSIWYG Visual Designer)
• Graphics engine (ie. DIB’s, image rotation, 22 image filters, RTF text, bitmaps, imagelists, icons, polygons)
• 2D Sprite engine with alphablending and antialiasing
• 3D OpenGL based control with 3D scripting language
• STL 3D file format support
• Turtle Graphics scripting language
• MCI control with easy media scripting language
• OwnerDraw engine
• CustomDraw engine
• customize common dialogs
• dynamic region generation (non-rectangular windows)
• game loop engine with precision timing
• low level graphics (ie. direct window DC drawing or copying)
• print engine
• built in custom controls – Canvas, Turtle Graphic, 3D buttons, shape/hotspot/splitterbar,property listbox, files listbox, masked edit
• Theme support
• multimonitor support
• autosize engine
• control search functions
• Layers engine
• Registry access

Now all of that, but at one third the size of the above VB runtimes. Yes it was written using Basic, a simple and easy to understand language. It was written without a single bit of OOP, purely procedural style code. It executes fast.

Now don’t underestimate the PowerBasic compiler I used. The EZGUI runtimes internally uses things like complex data types (structures), code pointers, data pointers, dynamic memory allocation, register variables (for faster code). It directly accesses both the Windows API (WIN32) and the OpenGL API. The point is that software can be written to be faster and smaller, while still being readable using an easy to understand language like Basic, without the need to use OOP. Now PowerBasic does support OOP in those cases where it really is necessary, but I find it is rarely needed.

So why should programing be complex ? It doesn’t have to be.

So why should software be slow and bloated ? It doesn’t have to be.

So why does software have to be hard to maintain ? It doesn’t have to be.

Yes, software development today is missing the key ingredient, simplicity! But it doesn’t have to be that way.