What is missing in programming today ?
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.