The Software Developer

Let me start with why I designed EZGUI the way I did. No matter what anyone says, writing Windows applications is not easy. For those who are engulfed in writing software using mainstream development tools (aka. Visual Studio) everything revolves around the development environment. From intellisense to drag and drop design, the idea appears to be “make things easier for the programmer”. I agree with the sentiment, but disagree with the method.

For programmers like myself who are engulfed into the world of the WIN32 API’s, programming can be just as complex. The Windows API is by no means simple. I recently downloaded two of the better Visual Designers (demos) created by the PowerBasic community and I have seriously considered how they differ from the approach I have taken with EZGUI. One designer attempts to emulate classic Visual Basic in many ways,  while the other appears to be taking some cues from Visual Studio, with a design environment similar to Microsofts Blend designer. I was impressed with the designer which emulates Blend, but at times I found it bit overwhelming, which is the same experience I have felt using Blend with XAML. I have a good bit of experience with graphic designers for 2D and 3D drawing and for me, I just don’t view visual design of a graphic user interface to be the same thing and I prefer the more old fashioned classic Visual Basic style of laying out of forms. So in this case something more akin to Visual Basic is likely more user friendly.

Now as far as working with code, the two worlds I have to compare are the WIN32 world of PowerBasic developers and the Object Oriented World of Visual Studio. I don’t think WIN32 is easy, but compared to all the OOP stuff in Visual Basic (dot.net) and the huge dot.net framework, even the complex WIN32 is easier in my opinion. If you want some of my feelings about OOP read some of my other blog posts (  ie.   http://cwsof.com/blog/?p=612  )

So back to PowerBasic and the WIN32

The Visual Designers for PowerBasic which have been developed, do a great job of building a powerful front end. One weakness, in my opinion,  though is their dependency upon the Windows API and WIN32 coding. As applications get larger and larger with more complex user interfaces, I find that the WIN32 API’s are like a dangerous iceburg just waiting underneath the water ready to sink the ship. When working with the Windows API, I don’t want any surprises. This means that I personally am more inclined to want to build reusable library code and use it, rather than keep writing (or generating) more WIN32 API code. EZGUI was not originally designed to be a commercial product. It was designed as an inhouse library so I could keep myself as far away from the Windows API as possible. To me this was a more reliable method of coding.

If there is one thing I put far above “ease of use” in my software, it is reliability. I like to use the term “solid as a rock” when I describe my goals for EZGUI. No matter how fancy the user interface or the tools we use to build them, software has to be reliable. This is one of the reasons I don’t like the WIN32 API’s because of the huge set of include (header) files required. One slight change in a new version of the headers and you can break a lot of code. This is why when I created EZGUI using PowerBasic, when I got started using PowerBasic 6.0 I determined to keep the original header files (includes) from that compiler as my core headers. Then as I needed anything which may be missing, I modified my own include files, rather than use the new versions provided with the compiler. I didn’t want any surprises. Also I also determines to write all my own code for the library. No copying others code (even open source or freeware) to save time either. I had to fully understand all the stuff I was doing with the Windows API, before I added new code to EZGUI’s runtime. The library had to be rock solid, “no surprises”.

The Windows API is also not intuitive, in my opinion. Tasks which should have been easy, often are complex or tedious. Why couldn’t the API’s be simpler and easier to use ?

To be honest, I find it confusing that most of the third party developers of Visual Designers for PowerBasic, have preferred to generate SDK (pure WIN32 code, much like old fashioned C) style code, rather than to take advantage of the GUI command set built into the compiler (called DDT or Dynamic Dialog Tools) which does a decent job of simplifying the Windows API and it produces more reliable code in my opinion (it may be simple, but it just works). There needs to be a balance between access to the power of the Windows API and ease of use and reliability. DDT does some nice tricks to make coding easier to read and reliable.

I have considered building a full Visual Designer for use with DDT, but I really don’t want to compete directly with the PowerBasic PB Forms designer. I have a utility designer I sell for generating DDT code, but that is as far as I currently plan to go with DDT. DDT does its job well and PB Forms supports a good portion of the PowerBasic users. For me, I chose a totally different route.

A GUI Framework

I don’t find working with the Windows API, directly, reliable, so building a Visual Designer which concentrates more on the drag and drop experience which generates pure WIN32 code is out of the question. PowerBasics DDT GUI command set is quite usable for many smaller to medium sized applications which have a minimal user interface, so there is little reason for me try to out do PowerBasics own PB Forms designer for those users.

My own needs and goals are far more extensive than that. I wanted to be able to build as large an application as I wanted, with as complex a user interface as possible. One goal was that I didn’t want to be dependent upon a bunch of third party custom controls (like classic Visual Basic programmers). I wanted everything to be possible with just one system. It had to be easy to use, powerful, extensible, reliable and have as small a footprint as possible. While a drag and drop design environment was vital, the designer experience would not be the key to the product. The real power would be in the GUI engine or framework. The framework would be so easy to work with that one could even write applications without the benefit of a Visual Designer if need be (and a number of my customers actually prefer to write apps that way). How many programmers today can write a complex Windows application using just a simple code editor, a single source code file for most of the source code and be able to design the user interface only with code ?

With this idea, EZGUI was born. The Visual Studio world has its framework, dot.net, so why shouldn’t the PowerBasic community have its own GUI framework ? Well, it does and it is called EZGUI (for Easy GUI). But there is one problem ! The Windows API is a complex and large set of API’s. How can you keep a GUI framework small and tight, while tapping into as many features as possible ? I decided on the old 80/20 rule (or close to that ratio). The principle goes like this. That 80 percent of users only use about 20 percent of the features available. I found this true with using the Windows API. So in my mind, the goal was to try to tap into that smaller 20 percent of the Windows API, so it would provide mostly what is needed for 80 percent or more of what a developer needs, to be able to build a complex user interface.

There was a key though which was important. What if a developer needed something not found in that 20 percent ? This is why making the GUI framework extensible was vital. I designed it so it was easy to integrate pure WIN32 code when it was necessary to solve a problem. This is exactly what my customers have done. I encourage them to use only the framework if possible, but in the few instances where something they needed was missing, I explain to them how to extend the GUI framework using the WIN32 API. I even show them how to avoid having to use any of the WIN32 header (include) files when they do this. EZGUI has its own header file which basically has the entire command set declared in it. Most applications can be written without the need for a single Windows API header file. This was by design. EZGUI applications compile very fast because they are not dependent upon a huge number of API headers. The primary EZGUI header file is only 92 KB in size. That is tiny compared to the typical WIN32 application requirements. Previous versions of PowerBasic put the majority of API include (header) code in a single file about 1 megabyte in size. The current version (10.0) uses multiple header files more similarly layed out like Microsofts C headers and it amounts to more than 1 megabyte in size and spans multiple files. EZGUI has its entire command set declares in just three include files which total about 97 Kilobytes in size (primary one is 92 KB and the other two are very small). That is one tenth the size of the include files needed using any other methods of coding using PowerBasic. Compile time is significantly faster and less prone to error.

Compile times for EZGUI applications are very fast, because there is minimal code to compile. Another factor contributes to faster compile times. That is the unique GUI command set in EZGUI. Unlike the WIN32 API’s many tasks only require a single line of code and the syntax of most EZGUI commands have been designed for minimal characters to be typed into the code editor. For example, the code necessary to create a Toolbar control, with all the buttons defined using one of the built in system Bitmaps would look like this:

EZ_Toolbar 50, “#LargeSTD”, “BBBBBBBBB|{New File |Open|Save|Close|Cut|Copy|Paste|Print|Redo}”, “ALONF24X24{1}VT”

By defining certain aspects of the toolbar using simple macro property strings, the amount of code is minimal. The GUI engine handles interpreting the property strings into meaningful API calls internally. The above code defines a toolbar using the large standard bitmap system images, with nine buttons, each with a text string in them and defaults to using the images (indexes) in sequential order for the image icons. This command can even define image indexes which are not sequential, using a single character per button. The images are 24 x 24 pixels and the last string parameter defines all the properties of this control.

Better than XAML, the GUI command set allows you to manually define a user interface but using a syntax which requires minimal code, but is still dynamic since these are actual sub/function calls into the GUI framework. The parameters could be passed variables instead.

Now new EZGUI users actually find there is a difficult learning curve at first. Not because EZGUI was not designed to be easy to use, but because it is so different than what they may have been used to. Once they understand the common syntax of the command set and how things work, often the learning cycle speeds up significantly.

The secret to a GUI framework

One of the secrets to the EZGUI framework is something so simple and obvious, programmers often fail to appreciate its importance. As programmers we get so used to “plug and play” we may find ourselves not wanting to write much code. It is so much easier to just pop in that third party custom control (typically OCX with Visual Studio) rather than create something ourselves. Maybe we want the Visual Designer to do all the work and simply add a little code here and there in some event routines. But you may say, “I don’t have time to write a custom control from scratch” and I would agree with you. But there are problems in being too dependent upon a number of third party controls. Every new third part component added to a project, adds the possibility of some incompatibility between components. Second, most component models today are based on COM (ie. OCX) so the components may need to be registered with the operating system, which prevents apps from being truly portable. The size of the applications also tends to increase significantly. So what I decided for EZGUI was this. First if a third party custom control must be used, I would encourage users to opt for those in DLL form which don’t need any special kind of system registration. This would make them portable, so you can just copy and run. EZGUI’s own framework is built of just DLL’s and they are all portable. Just copy them into the same folder as the application and they will work.

Second, why not design the GUI framework itself to have an extensive set of customization features built in, so you could simply create new controls by using existing ones and simply use some sort of customization feature. Actually, this was a perfect thing to impliment, since the WIN32 API’s already had this built in (albeit not that easy to do), so I could tap into these features in the Windows API, make them easier to use so developers would have almost limitless choices for customization. I chose to impliment both OwnerDraw and CustomDraw for controls which supported them. I provided the mechanisms to use these methods of customization, such as a graphic drawing engine.

The key to EZGUI’s nearly limitless potential is customization. Add to this, access to many low level features in Windows, but made easier, such as subclassing, superclassing, using worker threads and syncronization (critical sections). There are three different Graphic engines, one for the Canvas control, one for the printer and the other for low level drawning into any Windows DC (this is used for ownerdraw).

Filling in the gaps

The interesting thing about the Windows API is that while there is a great deal of power in it, often it is either not easy to accomplish certain tasks or there is no medium or high level ways to accomplish some tasks, which really should have been in the operating system from the beginning.

With EZGUI, I chose to fill in some of those gaps. First, tasks which were a bit difficult using the Windows API’s, I found ways to simplify them or even automate them. For example, there are two sets of ownerdraw commands in EZGUI. Once is more low level, but still much easier than using the Windows API alone. There is also a “simplified” version of the ownerdraw command set, which with just one line of code allows you to draw using a variety of ownerdraw features. For example, I impliment a simplified ownerdraw command set for 2D and 3D colored button controls. Customization need not always be overly complicated.

But the customization features alone were not enough. There were many things missing in the Windows API or at least no medium or high level ways to accomplish some tasks. These I had to build myself. I took on this challenge in a variety of ways. First, I created new controls which simply didn’t exist in Windows. True some of these may exist in the dot.net world, but that is because they are using a large GUI framework, instead of the Windows (WIN32) API. Somebody had to create these new controls, because they didn’t exist before.

I started with easier control concepts, but progressively added more and more to handle a variety of common tasks. Again the the 80/20 rule applied. I wanted new controls which were more generic in their use, but would cover a larger variety of common tasks. I created an MCI control, because multimedia is important. I created my own Canvas control because it was the most useful graphic oriented control to create. I wrote my own Files Listbox and Property Listbox controls.

More was needed though

The downside to the 80/20 rule is that programmers could easily get into a rut using only the more popular and simpler controls. There was a need to actually break the 80/20 rule and find ways to encourage programmers to push the envelope when it comes to user interfaces. One of the downsides of the new Metro interface in Windows 8 is that it tends to encourage conformity, when at times there is a need for something new and fresh which better handles the task. It is not a matter of simply breaking the rules just for the sake of breaking the rules. At times something better may really be needed. To illustrate, most birds fly since that is the norm for birds, but penguins don’t. Why not ? Because they serve a different purpose. They are birds, but they swim in the water like other birds fly in the air. They are a beautiful bird in their own right, but they are different and in their case different works, because they have a different purpose. So too with designing user interfaces. Doing something different just because it is different does not make sense. But what happens when there is a better design, by doing it differently ? Maybe the different task or purpose requires something different, something better.

While in versions 1.0 to 3.0 of EZGUI, I concentrated on the 80/20 rule, with EZGUI versions 4.0 and 5.0 it was time to break the mold. It was time to provide the tools so developers could push the envelope a bit. At a time when the devices we run Windows on are changing more and more, there is a need for more choices in software, not less.

While previous versions of EZGUI contained a built in drag and drop command set, it was time to push it beyond the basics. I needed the drag and drop for building my visual designer, but my customers also benefit from using it too to build WYSIWYG style applications. I improved the drag engine so it could drag multiple objects (controls) at one time, with speed and minimal flicker. Try selecting a couple hundred controls in your favorite designer and drag them all around together and see how difficult a task that is. This is a very useful feature for building enterprise and commercial applications which need the ability to do real drag and drop.

More and more PC users are using multiple monitor setups, so it was important to add that functionality. Because of the different device sizes which applications may have to run on, I added a new AutoSize engine for automatically resizing controls when a Form changes size. This autosize engine is very sophisticated, even with some unique customization features to handle many of those situations where a simple rules based system won’t handle it. I added a number of features to improve the graphics engine. Starting with EZGUI 4.0 I added a 2D sprite engine. Sprites have been around since the days of the Commodore 64 and Atari home computers, so why didn’t Windows have them ? I built my own sprite engine and embeded it into my Canvas control. Sprites can do more than just games, but have many business applications as well. EZGUI does this also without the need for DirectX too.

In EZGUI 5.0 I added a new superclassing engine, which I used to build the latest new control which is the glCanvas control, a hybrid control based on my Canvas control but which adds a 3D scripting language on top to display OpenGL based 3D objects. Now 3D is easier than ever. No need to learn the OpenGL API, the control handles it all via its extensive 3D scripting language.

The point is that, a GUI framework like EZGUI pushes the limit of software development, but it has one more significant benefit.

Windows 8, the desktop and tablets

With Windows 8, all the emphasis is on the Metro (or Windows Store) side of Windows. But the desktop is not only still alive, it can be more powerful than ever. The challenge of building Windows 8 desktop applications, which are not only fast and fluid, but are also emersive and exciting is being able to break out of the mold and being able to design something totally different and something dynamic as well. EZGUI was designed for this challenge (and more will be added in a future version). First, the entire EZGUI framework is only about 1 megabyte in size. The core runtime engine DLL is only 700 KB. Because EZGUI uses only DLL’s in its framework it is portable and you can create applications where you simply copy and run. Because the size of framework is so small and the executables which use the framework are significantly smaller too, you can build applications with an amazingly small footprint. This makes a difference when drive space may be a premium on a tablet. Applications can even be run using SkyDrive. Just copy and run, no installation needed. How about installing them on a jump drive and run anywhere ?

One problem many face is how do you support older legacy computers, while still support Windows 8 ? Applications built using EZGUI will also run on a variety of versions of Windows. Because the GUI framework was designed to be as universal as possible, it will run on Windows XP to Windows 8, dynamically changing itself when possible for the latest versions of Windows. Actually EZGUI applications can run even on Windows 95/98/ME and 2000 also (some features only available on 98 or later and some only on XP and later). System requirements for applications are minimal, so you can write software which will run on more Windows devices, even with as little memory as 256 megabytes or less. How many XP computers are still being used, even in the Enterprise, which only have 256 meg ram ? EZGUI applications can handle it.

At a time when software needs to be more dynamic and be able to run on a greater variety of devices (x86 only though), EZGUI 5.0 provides an amazingly large feature set but with a minimal footprint. All of this is only possible with a GUI framework. This is why I chose to build a framework, rather than simply a Visual Designer front end. But don’t worry. EZGUI comes with its own drag and drop Visual Designer, designed specifically for this unique framework. So whether you are designing for Windows XP, Vista, Windows 7 or Windows 8, EZGUI provides a framework up to the task. EZGUI keeps the desktop alive in Windows 8 and makes writing small footprint applications for tablets much easier.

Do you remember Windows 95 ? Yes, Windows was no longer a 16 bit operating system. Now with a 32 bit operating system, more would be possible with software. How much memory did Windows 95 require ? My first Windows 95 computer was one which I upgraded from DOS/Windows 3.1 which only had 8 megabytes of RAM. So how did an operating system like Windows run so well on so little memory ? The average CPU back then was likely a 386 or 486 class CPU which was in the 25 to 32 mhz range. From todays perspective, such a thing would almost seem impossible. The official system requirements were a 386 CPU, 4 megabytes of RAM and 55 megabytes of diskspace. Most computers today have CPU’s in the 1 to 2 ghz range with 2 to 4 gigabytes of ram. So much power is now in our hands. But is it really ?

So how was Windows 95 possible with so little hardware ?

The operating system was designed around a set of flat API’s (basically function calls). Often refered to as the WIN32 API, the operating system provided a set of low level features which could be used to build applications. The efficiency of that operating system to run on such minimal hardware says a lot. But what many may not appreciate today is that how software which ran on Windows 95 was written is far different than how software is written today. While MFC (Microsoft Foundation Classes) was already being used by some developers at that time, many applications were still written using the pure Windows API’s alone. Doing this created applications with less dependencies. If you examine the Windows programming books available at that time, while some discussed using MFC, there were a number which taught programming using the pure WIN32 API’s alone. Having been exposed to WIN32 programming much later, nearly 15 years after Windows 95, I can appreciate why some programmers chose MFC over the the pure WIN32 API’s, since working with the WIN32 was not an easy task. But the WIN32 API’s though do have one real advantage. Working closer to the core operating system allows one to build applications which are smaller, faster and which requires a minimal footprint (less memory and disk space).

So what happened to Windows development ?

I am sure many programmers have a different perspective on this, but my own experience is quite unique and offers a different perspective on this. My programming started back on the days of CPM, before even DOS. When the IBM compatible PC came along, I started programming in Microsoft QuickBasic, then PDS 7.1 (professional version of QuickBasic). I even wrote some libraries for the compiler using assembler. There were three criteria for my development needs, (1) Fast development (2) Easy to read syntax and (3) Performance. Using a quality BASIC compiler along with a little bit of assembler provided me with all three.

When it came time to move to Windows, like many Basic programmers I quickly latched onto Visual Basic 1.0 (for 16 bit, and later 5.0 for 32 bit). I dabbled with a number of Basic programming languages such as GFA Basic and CA Realizer, but Visual Basic provided the easiest transition for me. But something happened to my programming experience which would change things drastically. I switched to a different Basic language compiler which was more akin to programming in C in Windows, which forced me to start learning how to work with the WIN32 API’s. There were no RAD tools for me to use at the time. Everything had to be coded manually in a code editor without a RAD front end. It was very difficult at first, not so much because the WIN32 API’s were too complex to work with, but because all the documentation about the Windows API were written for C (or C++) programmers. I had to port a lot of C code to Basic, which wasn’t easy because I was not a C programmer. To make things even more difficult, in the C world programmers had quickly adopted MFC, so many of the programming books dealt with MFC, rather than the WIN32 API’s directly. Over the years I would scan online looking for old copies of programming books which dated back to the early to mid 1990′s. For example I just could not find a book which explained how to write custom window classes using the WIN32. The only (and best) one I could find dated back to Windows 3.1, but it was amazing how little had changed since then.

It was interesting to see the direction that Visual Basic followed during these and later years. In the 16 bit days of Windows 3.1, Visual Basic added the VBX custom control format which was a real benefit to Visual Basic programmers back then. It was later replaced by the OCX (COM based) custom control format. While there were many advantages to these component models, the OCX would, in my opinion, introduce a downhill slide in the Windows programming model. I first experienced this when I wrote an application which could be used as a utility for a multimedia development tool. I was a beta tester for a product called MediaForge, a powerful multimedia development tool. The developer of that software was an amazing C programmer with an extensive knowledge of the Windows API. When I sent him my Visual Basic application (an HTML generator utility), the first thing he commented on was whether I could get rid of the OCX’s that had to be distributed with my app. I was forced to use OCX’s for simple things like the common dialogs. It would not be until some years later when I started digging into the WIN32 API’s myself, that I would come to appreciate how bloated some software became because of overuse of the OCX component model. The code needed to impliment a common dialog via the API was minimal compared to the size of the Visual Basic OCX. So what was the problem here ?

Object Oriented Programming changes things.

The real cause for the software bloat was, in my opinion, the overuse of the COM component model and the overuse of object oriented programming model. While they both have their value, their overuse has added a significant amount of extra overhead to Windows programming, far more than most programmers would like to admit. How do I know this ?

(For some more info about the weaknesses of OOP consider these articles:)

• http://www.csjournals.com/IJCSC/PDF1-2/9..pdf
• http://software.intel.com/en-us/blogs/2008/08/22/flaws-of-object-oriented-modeling/
• http://www.4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf

When I started learning how to program using the pure WIN32 API’s, I had a few advantages that the early Windows programmers may not have had. First, I had a chance to see how the WIN32 API remained basically intact over multiple generations of Windows. The few changes made, were easy to work with since Windows from the days of Windows 95 has had a few very important features which have remained steadfast in every generation. One is the trusty DLL (dynamic link library). The DLL design, in my opinion, was simply ingenious. DLL’s are truly dynamic, produce reusable code and they tend to have a much smaller footprint than their OCX counterparts , plus they normally don’t need to be registered with the operating system, meaning the registry need not be involved. You can simply copy and run. The second important feature, associated with DLL’s again, is the ability to dynamically load DLL’s (via the LoadLibrary API), rather than staticly link them at compile time (the DLL is still separate, but the EXE header tells Windows to load the DLL automatically). Dynamic loading allows you to poll the DLL to see if an API exists or not, so you can take adantage of features in later versions of Windows if you like.

The second advantage I had was that I used a BASIC language compiler rather than C. The amazing thing about this was that working with the pure WIN32 API’s was so much easier using Basic, than it would have been using C. The language syntax made code more readable, the powerful memory management built in made coding easier, the compilers built in support for variable lengths strings (using the Windows OLE engine) made things much easier as well. For once, WIN32 code made sense and was readable. I didn’t need to use MFC. I could write applications using the WIN32 API alone.

Interesting results !

Of course to be able to write software faster it only made sense to design RAD tools, but once again the power of the WIN32 API’s proved an advantage. As I went from just a beginner API programmer to an experienced one, I began to solve more and more problems using the pure WIN32 API’s. Of course, every programmer needs some kind of higher level libraries, so I began to build my own. Because I used a Basic language compiler, I had no MFC to fall back on. I had to build my own libraries.

So while building a reusable GUI library was important, I had some basic rules. The library must be in DLL format. API’s which didn’t exist on some earlier versions of Windows, had to be polled for and then loaded dynamically, so the library would be compatible with all versions of Windows from 95 to Windows 8. If possible when an API was not available on an earlier version of Windows alternate code was added to support similar features if possible. At the minimum, the library must support all of its features on at least Windows XP forward.

Since I didn’t even have the benefit of a drag and drop visual designer to help me, I decided that I needed to learn how to build that from scratch using the WIN32 API’s. Any complex task using the WIN32 API’s which took some time to develop, I decided should be put into library code so it can be reused. Code reusability is not dependent upon the object oriented programming model as some may think. Procedural, flat API, programming models can also benefit from high level reusable code libraries. The key to working with the WIN32 API’s is to build such reusable libraries.

So the final results have been interesting. First, I found there are some very powerful low level features in Windows which have been there since Windows 95 and are still fully supported in Windows 8. For example the DIB (device independent bitmap) API’s are very useful and very powerful. The WIN32 API’s offer so many different ways of customizing user interface elements (controls). Such things as subclassing and superclassing are powerful tools. Fortunately I found one of the few books written about how to write custom window classes (controls) using the WIN32 API’s (and the term class does not mean it is object oriented in this case). I have written a number of custom window classes using the WIN32′s, such as my own Canvas control with a low level DIB engine and 2D sprite engine, an OpenGL based 3D Canvas control with a 3D scripting language, a Turtle Graphics control and a Property Listbox control. For me, as a WIN32 programmer, the possibilities seem endless.

But the most amazing thing about all of this was the size and footprint of the GUI libraries I was able to build using the WIN32 API’s. The entire GUI library can fit on an old fashioned floppy disk with room to spare. When I realized that I could write complex GUI libraries and applications which can run on most versions of Windows in use today with a minimal amount of memory (easily 64 meg or less), which are truly transportable (just copy and run, even from a flash drive) and can easily be run on the most minimal of computer hardware (ie. 233 mhz or less CPU), it is very exciting. While most programmers may be stifled by the minimal hardware on some Windows tablets today, for a WIN32 programmer the average Atom based Tablet is far more than adequate, but is a powerhouse.

So if you are looking for an alternative way of writing software which has a minimal footprint, then seriously consider what has been around since the days of Windows 95, the WIN32 API’s.

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