The Software Developer

Now don’t think I don’t like Windows 8 from the title of this article. I just think that one of the key issues Windows faces right now, may be the product of this weakness.

Everything is going mobile and for mobile battery life is everything. The question of whether to use ARM over Intel all comes down to battery life. Now Intel CPU’s seem to not look so good because power usage, but maybe the real problem is with Windows and how software is developed. What do I mean ?

Because I started programming in the days of DOS (even before that), 640 KB memory and no hard drives, using the resources of a computer efficiently were a high priority. Compiled code had to be small. Compilers had to be fast and produce small executables. Apps had to use memory careful, even disk space carefully. The new generation of programmers have grown up on computers with huge amounts of memory and diskspace. They grew up on processors which had their speeds defined in gigahertz, rather than megahertz. They have been spoiled.

To add to this, somehow object oriented programming design, rather than simply providing one more tool for programmers has somehow become the core model for programming, as if anything else is the product of ignorance. I hate to burst the OOP bubble, but it has not produced the benefits everyone thought it would and I believe it may be at the core of the Windows problem. One has to appreciate how human readable code is converted to machine language to appreciate this. If you mention to programmers that OOP requires a few extra “hoops” to jump through to accomplish a task (aka. pointer to a pointer to a pointer), their first reaction is “big deal”. Computers are so fast that it makes little difference. It is that mindset which actually makes programmers fail to appreciate the value of performance.

The problem is, that this may be true for a single line of code, but when you multiple this by millions upon millions then it adds up to a lot of waste. Also the nature of object design does not lend itself to minimal machine code generation. Objects are so complex at times that they can actually lose efficiency.

You may say this it does not matter anymore, but I think it does. Herb Sutter in his talk “Why C++ ?” discussed how both in mobile and in large data centers (which service all this mobile stuff), performance once again has become critical. I will go one further, even C++ because it leans towards OOP more than C, may slow things down because the more you depend upon OOP, the slower things can become.

I had an interesting experience. I was talking to a friend, who I learned used to work in the software industry years back. He asked me what programming language I use and I said Powerbasic. He was surprised when I said I don’t even use OOP at all. I was describing what I was able to do with PowerBasic and the GUI engine I built using it (EZGUI is non-OOP based and relies totally on the WIN32 APIs). As usual I noted how fast my code ran and how small it was (both vital to performance), because of how it was created and because of using PowerBasic.

I started to tell him about all the features in this library. Just think, EZGUI is actually a GUI framework of sorts (a middleman between your app and the WIN32) and it contains the following:

• GUI engine for forms and controls (all the standard WIN32 controls and most of the common controls) and support for most often used features
• Common dialogs, even being able to customize them
• thread engine
• subclassing engine
• superclassing engine
• ownerdraw engine
• customdraw engine
• graphics engine (GDI and proprietary)
• 2D sprite engine
• 3D OpenGL engine
• multimonitor support
• theme support
• drag and drop engine (ie. build your own visual designer)

it also has a number of custom controls built in, which go beyond the ones provided by Windows such as:

• masked edit control
• shape/hot spot/splitterbar control
• drag handle control
• turtle graphic (vector graphics) control with built in turtle graphics macro language
• canvas control with built in proprietary 2D Sprite engine
• opengl canvas control with built in proprietary 3D OpenGL scripting language
• files listbox control
• property listbox control

There are a number of important features not provided by Windows which I had to design myself, such as the Sprite engine, 3D engine,  the autosize engine (autosize controls when form is resized) and layer engine (show and display controls on separate layers. Now of course EZGUI does not do everything, but it does a lot and if you need to extend it you can easily integrate pure API code calls to compliment it.

When I gave an overview of what EZGUI does to this friend I posed the question of how big do you think it is ? I told him the main runtime (which has 90% or more of the functionality) is only about 700 KB in size. His response ? (paraphrased)

“You mean 7 megabytes, right” ?

I said, “no, I mean 700 Kilobytes. The total of all the runtimes (DLLs) together come to about 1 megabyte”.

His response was “that’s impossible”!

Just think, when describing all the features first, this friend who was more familiar with OOP than procedural style coding, could not believe that my library could do all it does and be only 1 megabyte in size.

To add to this, years back I was beta testing a product called MediaForge, which was an amazing multimedia development tool and I communicated a lot with its sole developer, Rob Adamson. Rob was a really, really good C programmer and knew his stuff. MediaForge could be extended using plugins written as DLLs, so I wrote my original Turtle Graphics engine as a plugin for MediaForge. It was just an experiment to see if I could do it and how well Powerbasic would do in creating such a plugin. It worked quite. The thing that struck me was that Rob was impressed with the size of the DLL’s I could produce with PowerBasic. It was on par with what he was doing with C.

The problem with Windows today, I believe, is how we write software. Software is bloated and slow, so no wonder the hardware has a tough time keeping up with it. The software is what makes the hardware look bad and this does not appear to be limited to Windows, but even IOS and Android (everybody uses OOP today). According to Herb Sutters talk, he commented how all these platforms have had problems dealing with performance. Why do you think all the mobile devices today are going the route of mult-core CPU’s ? Even dual core is not enough anymore, but now quad cores are becoming the norm. I see a mindset of “well the software is not fast enough, so let’s just add a couple more cores to the CPU and all will be fine”. So what about the software ?

Also look at the problems created by over eager hardware designs of computing devices. Everybody touts “retina” displays and PPI. The 3rd/4th generation IPads quadruples the pixels on the screen and everybody is excited. As a programmer who has been around awhile my first reaction is “the hardware has to do four times as much work now”. If software was slow before, it will be even worse now. Everybody touted the 4th generation IPad with its new more powerful CPU. “Wow”, they added so much more power. Has anyone ever considered that maybe they had to ? When they switched to the retina display, the CPU had to work a lot harder than before. Maybe Apple realized they need to spice up the IPad CPU even more to better compensate. The real question is, “is the performance today any better than in the previous years, overall” ?

Maybe we need to go back to basics and learn how to write better software. Software needs to be more efficient. Performance needs to be a high priority.

I also feel that programming has been made too complex. In the old days, many turned a hobby into a trade by learning programming on their own. Languages like BASIC introduced many to programming. I really don’t feel that many who moved on from BASIC to C eventually, did this because they did not like the language. I feel they likely felt they needed more power and the only languages touted as high performance were things like C. C does not have a natural syntax to it, like BASIC does. C is harder to learn. Even VB.NET has destroyed the BASIC language syntax by moving closer to its C# cousin. OOP has taken over languages to the point where they are not naturally any more, but more complex.

What we need today is programming languages with a more natural, easy to understand syntax (like Basic). We need programming languages which compile lightning fast and produce tiny executables. We need to get away from the overuse of OOP (OOP adds too much overhead and complexity). We need to produce simpler, less complex API’s for programmers to access. API’s need to be built in multiple levels, starting from low level to medium level and then to high level, building on each previous level. Modular design is not limited to OOP, but has to do with the layout and levels one builds into an API (or Library). IMO, Procedural based libraries can be written in such a way that we could likely double the performance of many of our computers todays by just writing software better.

Would you like to see what a programmer is really made of ?

If the average programmer using say “dot.net” likely has a computer with at least a Core i7 CPU, 8 gigs of memory and terrabytes of disk space, then why not make him (or her) , for a couple weeks, be forced to use a computer with an Atom CPU, 1 gig of memory and a 32 gig SSD ? Now see how quickly they start crying out “it’s all too slow, what do I do now” ?

Now many will say, “that is not realistic and it can’t be done”.

I say to you, yes it can. While I just recently switched to a better PC (Pentium D 3.2 ghz CPU and 2 gig memory) because my long time trusty XP PC experienced system crashes multiple times and I had to move to something more reliable, for the previous 6 years or more I have been developing all my Windows software on a Windows XP computer, with a 2.5 ghz Celeron CPU with only 768 megabytes of memory. Celeron CPUs have the same reputation as Atom and have not been known for power. The current Atom CPUs are more powerful today than my XP computers Celeron CPU. The Atom dual cores are extremely powerful compared to the desktops found in the early 2000′s (when XP was released).

How many programmers today would be willing to use a PC with an Atom CPU as their primary development computer ?

I have no problem with such a computer. I can easily compile 60,000 lines of code in just a few seconds using PowerBasic on such a computer.

My entire development system (PowerBasic compiler and EZGUI 5.0 Pro) only take about 20 megabytes of disk space and will run fine on about any PC made in the last 15 years. Visual Studio weighs in at 2 gigabytes or more of disk space. That means I am developing software with a set of tools that take up 1/100th the space of Visual Studio. I even designed EZGUI so one could even hand code their apps (like we used too) if they didn’t like working in a Visual Design environment.

I do like some aspects of Windows 8, even Metro (even though I prefer the desktop), but maybe we need a real programming renaissance today. The power of native coding using native API’s using better compilers could produce some amazing results. If less hardware is required to run the software, cheaper laptops and tablets could be manufactured, since the software would require less.

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

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

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

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

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

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

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

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

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

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

I downloaded a demo of a freeware Ribbon Control from Code Project the other day and the experience was interesting.

I develop software on my main PC, which is a number of years old. It has a 2.5 ghz Celeron CPU, NVidia Graphics card, 768 meg Ram and is running Windows XP Home (sp2). In my opinion this is a decent machine. While I have two other PC’s, one with Windows Vista Home and the other with Windows 7 (64 bit), I prefer to work on my XP machine.

I ran the demo I mentioned and while impressive in appearance, it ran so slow (mouse was sluggish) that it was disappointing. I decided to check the app using the Depends utility to see what API’s the app was calling and it turns out it was a dot.net app, so it was using the dot.net runtime.

While the newer technologies Microsoft provides for software development are impressive, it amazes me that performance is at the bottom of the list of features.  Even some years ago, when I purchased Visual Basic 5.0 Pro, it was interesting to note that the software license prohibited publishing any benchmarks of the software. In the old days (DOS), it was common for compiler makers to tout benchmarks in their advertising. But now, it appears few even care any more.

Why ?

In my opinion it is a mindset. In the old days programmers cared about efficiently using memory, but today no one cares because as they say “computers have so much memory today, it doesn’t matter any more”. In the old days programmers cared about the raw speed of their applications, but today no one cares because as they say “computers are so fast today it doesn’t really matter”. Can you see a pattern here ?

Computer hardware has improved so rapidly that few care any more about performance any more.

But …

A recent situation has brought performance back into view and software developers are paying the price for such attitudes. Tablet PC’s for one has brought hardware performance and software performance back into view. Intel created the Atom CPU for netbooks and also for Tablets (also the new Sandy Bridge CPU’s). These are powerful CPU’s and I mean powerful, but sadly software developers are calling them “slow” and “poor in performance”. Why ?

Not because they are all that bad, but because the bad attitudes towards software performance are coming back to haunt software developers. You see, netbooks and tablets have three issues to deal with that normal PC’s do not. The first is size. Faster CPU’s, bigger harddrives, more memory require more space. Netbooks and Tablet PC’s need to be small as possible, so they have to use less in the hardware area. Second is power consumption. Desktop PC’s can eat power all they want, but Netbooks and Tablet PC’s need to run off batteries so they need to conserve power. This means smaller and less power hungry hardware is required. Third, Netbooks and Tablet PC’s need to have lower cost parts, so they are affordable. People are willing to pay more for a desktop PC, since it is bigger and better and does more. People don’t want to pay twice the price for a Tablet PC, which has less memory, less speed, less screen size and less data storage than their desktop PC.

Because new technologies are becoming so popular (Netbooks, Tablets), software developers are stuck trying to find ways to get their software to run half way decently on these new devices, but they can’t, so in typical programmer fashion, they simply blame the hardware developers and say its their fault.

This problem has really hurt Microsoft in my opinion, since Microsoft is way behind in offering Tablet PC’s running Windows 7. Everybody wants an IPad and there are few Windows based Tablet PC’s coming to market right now. Have you noticed the hardware makers and the Tablet PC’s they are currently offering with Windows 7 on them ? They are not targeting the average consumer (you and me). They are targeting business and corporate markets. Why ? Because they can’t get the price of Tablets down enough for the average person, so a decent tablet which will run Windows 7, requires a more expensive Tablet and only businesses are willing to pay premium dollars for them right now.

The fault in my opinion falls on software developers and not hardware developers. Yes, programmers have had it too easy for too long and now they are paying the price. Even Microsoft is paying the price now.

I get picked on (when visiting programming forums) by other programmers for developing software for legacy operating systems (ie. Windows 95,98,ME) and for using an XP system for development.  Most programmers in my opinion use the latest PC hardware and target the latest technologies. One of the problems with this is that if you don’t make sure you do extensive testing on older PC’s, you have no idea whether your software is performing very well. When I say performance, I mean “raw speed”.

I find that it is better to develop on an “average” computer, rather than a “bleeding edge” computer, because I get immediate feedback on how my software is running. I am a programmer who concentrates on using resources efficiently. If I can write apps that fly on a 500 mhz CPU computer with as little as 256 meg ram, imagine how they will run on the latest hardware.

This is one of the goals of my development tool EZGUI 5.0. Combine it with Powerbasic (which produces lean and mean apps) and you have a development system which can run circles around others. EZGUI’s main runtime DLL has more packed in its 700 KB size DLL, than other development libraries twice the size (or more). EZGUI does not require dot.net (neither does Powerbasic), so it can be used to write applications which will run on Windows 95 to Windows 7.

Lastly, the lack of appreciation for designing software with raw speed and performance, has also hurt society because, rather than use computers for a long time, software developers (and their end users) keep requiring faster and faster computers, so more and more decent computers are ending up in landfills, consumers and businesses are wasting money, always having to “upgrade, upgrade, upgrade” to the latest technology, simply because the new software just won’t run on their perfectly good PC’s any more.

Maybe this should change. Maybe programmers should start caring again about how they write their software and the resources required to run them. Maybe programmers need to work a little harder. Now before you say it can’t be done, let me point out to you that some are already doing this. Even right now, my customers are writing software with amazing user interfaces, which can still run on legacy PC’s, which run fast on the current Windows Netbooks and Tablets and some of them even can fit their software on a floppy disk.