The problem with operating systems and programming.

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.