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

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.

The world of computers is changing drastically. Now mobile computer devices are what everybody seems to want. The choices of operating systems for such mobile devices continues to grow, but the experience for users is not as impressive as one would hope for. Why ?

Microsoft touts its new Windows 8 (aka. Metro) interface as fast and fluid. While it does solve some problems, it creates some new ones, which I personally feel transcends all modern operating systems. What is that ?

I have been programming for a couple decades now. My early experiences with computers was the Commodore 64 and CPM computers. The C64 was an amazing machine, despite it only have a 1 mhz CPU. Just think about that. The C64 only has a 1 mhz CPU while todays computers have CPU’s rated in the gigahertz and with multicores. To appreciate what could be done with such an minimal computer, do a google searching for words Commodore  and GEOS.

see:  http://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)

http://www.commodore.ca/history/company/turks_geos.htm

Todays computers are extremely powerful, but the user experience does not match that power. In my early days of programming custom software for IBM compatible computers I progessively saw the improvment in CPU power. I remember when a decent computer costing thousands of dollars would have CPU speeds of 25 or 32 mhz. Oh that was so fast, I thought. Then along came 386/486 class CPU’s in speeds over 100 mhz. After 100 mhz, for some reason I lost track of the CPU improvements. Now today it is nothing to have a CPU which is 1 ghz or better. Multicores have improved the experience for multitasking operating systems. Yet something was missing.

Simply put, speed and fast executing software. Why ?

Seeing the direction Microsoft has taken with Windows 8, it has become obvious. The WINRT demonstrates in its COM (object) approach. The old style procedural based API’s of the WIN32 are gone and it has been replaced with an object oriented API, based on COM interfaces. I understands COM’s usefulness for building reusable components, but to base an operating system on COM, in my opinion only adds more bloat to an already bloated operating system.

Now before I go any further, let me say that I am not against the use of COM or Object Oriented Programming (aka. OOP).  The problem is that COM and OOP are over used in operating systems at the expense of the hardware. The advances in hardware have been lost because of the poor design of software and operating systems. It also appears that the same problems we see in Windows exists in most other popular operating systems, whether it be Android, IOS, etc.

Since my knowledge is with Windows, I will use it as the core example of my discussion. In the old days, Windows software was written using C. The Windows API’s were procedural in nature. Now the WIN32 API’s, while powerful are also quite difficult to learn (at least quickly). It was not easy to write software in the old days using C and Microsoft obviously realized this. So the solution was to provide some kind of better framework to make building applications and Microsoft Foundation Classes was born (MFC). The idea was to make programming easier by providing easier to use and higher level API’s. Yet, it appears that MFC was not enough so other approaches were developed and in the last decade the dot.net era began. Dot.Net and languages like C# and VB.NET were developed to supposely make programming easier for the programmer. Now ease of use, in my opinion, is truly demonstrated when someone with absolutely no knowledge of a skill is introduced to the technology and one sees how quikcly they grasp the technology. I had a chance to experience this myself, since I have been away from Microsoft programming languages for over a decade. I use PowerBasic and I have a long history with Basic. To me, no other programming languages speaks “easy” than does good old BASIC. If you were to ask many old time programmers what language they first started with, likely they would say Basic.

Basic gets a bad reputation because of its early years when it was interpreted. Of course an interpreted language will be slower than a compiled language, but sadly many programmers who first experienced Basic, may not have realized that Basic could be compiled. Even the early years of Visual Basic (1.0, 2.0 and 3.0) were plagued by compilers that generated PCode rather than machine code. Because of this, I feel that some programmers left Basic in favor of more cryptic languages like C, which had power and great compilers. Now myself, my path was different. I saw the beauty of the Basic language, while coming to grip with its biggest weakness (speed). Do you realize that in he days of the Commodore 64, someone actually created a real Basic language compiler (made by Abacus). Wow, what a different Basic was with a real compiler. Easy to use language, but the power of a compiler.

I also had another different experience from many who first learned Basic. Realizing that speed was dependent upon machine language, I also learned 6502 machine language programming. Now rather than turn me off to Basic it only enhanced my use of Basic. I actually wrote my own Basic like compiler (albeit very simple) so I could build a video game which was published in Compute Gazette (October 1987 issue, called Chopper Pilot a non-violent family friendy game).  In the days afterwards when I started building custom software for local businesses, I stuck with Basic and was always on the search for a better compiler (ie. QBasic 4.0, PDS 7.1). I even wrote modules in assembler, when it was necessary. My PDS 7.1 software was so complex, when compiling I could not compile them from the IDE. To get all the features I needed when linking, I had to compile from the command line (automated with batch files).

My first try at GUI app development came with Windows 3.1 and Visual Basic 1.0. While the minimal object features of Visual Basic were acceptable and useful (since I had no other way to write a GUI app) the core Basic language was still there. The problem with Visual Basic was not the language, but its lack of power, since it compiled to PCode and there was little documentation about extending Visual Basic using the Windows API. I eventually upgraded to VB 2.0 and then later to VB 5.0 Pro, the first version for me which was a real compiler. Sadly Visual Basic got the reputation as being for hobby programmers, while C (and later C++) was for professional programmers. I dabbled with DOS C compilers, but never liked the syntax so kept coming back to Basic. What I did not realize was that the C world was making great changes and Object Oriented Programming became the fad. OOP looked good on the surface and made great promises, which some today feel that if failed to keep. Then dot.net changed the world. Visual Basic as we know it was dead and replaced by a Basic like, C# imitator. I have read how many of those who made the transition to VB.NET, quickly moved on to C#.  Then along came things like WPF and XAML.

After Visual Basic 5.0 (a short stint) I moved on to PowerBasic and never looked back. It was very hard, because in those days PowerBasic lacked GUI tools. I have to learn the WIN32 API’s too.  PowerBasic 5.0 was marketed simply as an addon to Visual Basic for building DLL’s. Yet, I made the jump to becoming a WIN32 programmer and I had the important thing. A real Basic language compiler, with the low level features of C (things like pointers) and it produced fast and small executables. Now the key for me, was not the language, but interfacing with the operating system.

So what was it like learning the Windows API ? Not easy at first. Now I see why early C programmers had such a challenge. The API documentation is very poor when it comes to teaching you how to do things, so programming Windows applications in C must have been a nightmare to say the least. But I had one advantage. The compiler I was using was Basic, not C, so amazingly the code was quite readable and not as difficult as it would have been had I used C. So I began the process of learning the Windows API.

So what did I learn about the Windows API during this stage ? Two things. First, the WIN32 API’s are extremely powerful and if an application is well coded it can run very fast. Second, Microsoft in my opinion didn’t grasp the meaning of “simple and easy to use”.  The WIN32 is too low level at times and the syntaxes of the API’s at times can be quite confusing. No wonder, Microsoft was looking for a way to make things easier.

So what direction did Microsoft (and actually most other operating system developers) go in to make things better ? They jumped on the OOP bandwagon and objects and classes took over Windows development. The one good thing this accomplished was Microsoft started adding some more high level features to the operating system and the programming languages. This is likely the reason many programmers today love dot.net so much. It is not because the dot.net languages are truly so powerful. It is because the compilers, rather than target the operating system, target a GUI framework (dot.net runtimes) which does all the hard work. The concept is actually a good one, but I think it fails for one primary reason. Rather than purely a procedural framework, Microsoft has gone the OOP route and everything is an object or class now. This adds complexity to the framework which I feel tends to bloat the operating system rather that improve it. The concept of namespaces, while good in theory, also adds to the complexity of the framework (and now operating system in Windows 8′s WINRT).

While there is a place for OOP, I feel it has taken over the programming world to its detriment. It adds overhead and complexity which forces us to lose the power of the current generation of computer hardware. Also the programming worlds love affair with C++ and C# (and java) which are cryptic languages increases software complexity and makes it hard to maintain. So why do I feel this way ?

Coming back to Microsoft programming languages after a decade. Because the current PowerBasic compiler is not ready for building Metro style applications, I felt I needed to see what Microsoft currently was offering. I downloaded the latest beta of Visual Studio and began to take a quick at where programming has gone in ten years. All I can say is , I was shocked and I mean that. First, the most obvious, was the size of the environment. I use a compiler which only takes up about 10 meg of disk space. My own GUI tools which I developed using PowerBasic also takes about 10 meg of disk space. When I saw Visual Studio requiring over 2 gigabytes of disk space to install, I was not impressed.

My next task was to dig and in and see how one builds a Metro app. Visual Studio gave me choices. Visual Basic was the obvious choice so I tried it. Not only was my brief experience with Visual Basic 5.0 Pro absolutely of no value here, the entire process of building an application didn’t make a bit of sense to me. Now I know I have not kept up with Microsoft programming languages for 10 years, but I am advanced and experienced WIN32 programmer. Using the WIN32′s I can build some amazingly complex applications. I also have done work with OpenGL (chose it because it was more procedural in nature than directx) as well. But nothing, and I mean nothing, in Visual Studio made sense to me. One look at things like XAML and I was wondering, have we gone back to using interpreters and parsers ? The amount of typing one must do using XAML to define a user interface is bloated, compared to using the WIN32′s directly and compared to my own GUI engine which has a simplified command set, is definite waste of time. Maybe XAML has some value as an intermediate language between a Visual Designer and the programming language, but that is all.

The next thing was trying to understand the layout of any application for Metro. In Win32, you have a simple starting point called WinMain. Not really that hard to grasp. PowerBasic makes it even easier with its own simpler PBMain function. I had difficultly trying to figure out where the code is suppose to go and where the entrance point is of an app. The last thing I came across which is where I decided, maybe Visual Studio is not the way to go is th overuse of objects and namespaces in the language. For example, I noticed one generated subroutine was being passed an object, which appeared to be a namespace object. Knowing that Visual Studio has intellisence, I figured I could start writing the objects name and intellisense would drop down a list of methods or properties. What shocked me, was that the namespace object had so many levels. I started typing some NAME and when the drop down list appeared I selected one item, so got something like NAME.Something, but then another drop down list appeared and I got something like NAME.Something.Somethingelse and then another drop down lost appeared and I selected another item until I got to about five or six deep and that was it for me. Has programming languages become simply a “select this, select that” tool where the IDE simply just keeps giving you choices ?

So a programmer with all the years of experience I have, even low level WIN32 programming and some machine language, finds Visual Studio to be so complex and confusing that I just can’t understand how people can write software anymore.  Object Oriented Programming and its offshoots (COM, namespaces) have corrupted the world of programming and yet everyone is wondering, why is it so hard to develop a tablet computer which produces a truly “fast and fluid” experience ! The problem is that programming has gone the route of overcompexity. Now sure, objects and even COM may have some uses, but when the operating system is riddled with OOP, no wonder we have a terrible experience.

I recently had a conversation with a new friend, who years ago worked with software development. In the conversation I was asked, what programming language do I use and I explained PowerBasic. The first assumption he made was, “It is OOP based” right and when I said I don’t use OOP he was surprised. The next thing floored me. I explained to him how I designed my own GUI engine (for Windows) which does not use OOP nor dot.net. I then explained to him some of the major features in the runtime engine so he had an overview of what it can do. Now EZGUI 5.0 has features like Forms/Controls command set, Graphics engine, 2D sprite engine, 3D OpenGL engine with scripting language, drag and drop engine (build your own Visual Designer), thread engine, subclassing engine, superclassing engine, ownerdraw engine plus a number of custom controls not found in the operating system (Canvas control with low DIB engine plus sprites, glCanvas control with 3D script language, Turtle Graphic (vector based) control, MCI control (for multimedia), drag handle control, masked edit control, files listbox control, property listbox control and more). What was interesting when I asked the friend, how big do you think this entire GUI engine library is ? I then told him the main runtime is only 700 KB in size. He quickly corrected me and said, “you mean 7 megabytes”. I said no. It was 700 KB in size and with the OpenGL control and some secondary DLL’s it came to about 1 megabyte total. It is what he said next which made me think.

“That is impossible” !

Yes, he thought that a GUI engine with all the features I mentioned, could not be that small in size. Using the WIN32 API’s directly, using a procedural coding approach (and using PowerBasic), yes it was possible. Likely a similar thing could be done using plain old C, but Basic is so much easier to read, why use C.

What I am finding out, is that the OOP approach to software development has produced operating systems which are so bloated they could never run on less than 1 gigabyte of memory (plus plenty of virtual memory). Even Linux (current generation) is getting bloated like Windows. Likely Android and IOS suffer similar problems. Maybe if we would like to see better operating systems and in the process need less powerful hardware, we should rethink how we create our software.

If you doubt some of my suggestions here that OOP has played a role in software being bloated or too complex, click on the tags section for words like OOP and read some of my other articles and see the links I post about what some experts in the field are saying.