“EZGUI is a RAD tool”

Yet, some new users initially find EZGUI, especially its visual designer, very confusing.

Paradox ?

Let me explain. I have been trying to fully grasp this paradox with my software and here are some observations of mine which may be helpful. Now remember that not all customers are the same so there is no way one can easily sum up all new users with one model, but I have seen a trend or pattern over the years with my customers and my conclusions are based on this.

Chris Boss doesn’t think like most programmers !

If you have ever even thought this for one moment, don’t feel bad. I won’t be insulted. I have to admit, this is most likely true. The more you use my software the more one will likely appreciate why I say this. Most people when they use my visual designer, their gut reaction is, “this is so different than what I am used to”. That is true. I did not design my visual designer to be like any one elses tool. I did not copy Visual Basic. I did not copy PB Forms. I did not copy FireFly. So what gives, you may ask ?

Even my GUI engine and its concepts, some find a little confusing at first. Why does EZGUI do so many things so differently than what you may be used to ?

Consider the background and history of EZGUI.

There is a good reason my visual designer is not like others, especially designers for use with PowerBasic. When I first started programming in PowerBasic (I was using PB 5.0) there was no DDT. There was no PBForms. There was no FireFly. There was no PwrDev. Actually there was no visual design tools for use with PowerBasic at all. You see, Powerbasic was not viewed as development tool for full blown Windows apps at the time, even by Powerbasic. Thats why the product was called PB DLL (or a DLL compiler). Even Powerbasics advertising touted it as an addon tool for use with Visual Basic, for those who wanted to write fast DLL’s for VB. Now I face a critical problem back then.

I wanted to write full blown Windows applications (which PB DLL could do), but one had to understand the Windows API to do so. There was no DDT back then, only pure SDK style coding. So I began an inhouse project to make writing apps easier. I had to find a way to be able to build an application quickly and easily. I was (and still am) a firm believer in building reusable libraries and so it began. My GUI library came to life. To make a long story short, it was not called EZGUI intially, but once I decided to make it a commercial product , EZGUI was born.

As I started building my GUI library, I quickly noticed that without some kind of visual drag and drop designer, building a user interface was slow going. Nobody that I can remember back then even knew how to build a drag and drop designer. There was no code on the PB forums to teach one how to do this. For me, it was a matter of a lot of research and trial and error. EZGUI was the first commercial product to attempt visual design for PowerBasic.

It wasn’t all about the designer.

What many have not realized over the years, is that EZGUI was (and is) not all about the Visual Designer. I did not design EZGUI to be a visual designer. The product was (and is) a GUI engine , a GUI library. Visual drag and drop, was simply a necessity for building apps faster and generating UI code. This is why the early generations of EZGUI’s designer were quite limited. They did the job, but that is all. It was all about the GUI engine though. That was the primary concern. The power of the product is the GUI engine.

The quicker new users realized this about EZGUI, that the power is in the GUI engine, the quicker they became productive with it. Each new version of EZGUI, the designer improved, but the GUI engine is where it was all about.

I see you are a coder !

Over time my customers most likely would begin to realize something about me. “Chris Boss, you are a coder aren’t you !”. Yes, that is a very correct description of my mindset. You see, I date back to writing DOS applications, before Windows became popular. I have a lot of experience in writing custom software for local businesses, most in the DOS days. From this past experience there are certain qualities that I have developed, when it comes to programming. First, I am a coder. I personally feel programmers need to code more and depend less upon visual designers. Many programming tools today are more App builders, than they are programming tools. This was the big problem with Visual Basic. Too many VB’ers could quickly lay out a user interface (which was easy), but when it came done to the coding part, that is where some fell short. You see, in the wrong hands, Visual Basic is just an app builder. If you can draw it, you can build it. That may be fine for the user interface part, but once you get past that, one must still know how to code. Thats where things can go wrong very quickly. Coding is an art, a skill. Even in the world of todays programming languages, especially dot.net stuff, I feel that programmers want the tools to do all the work. Maybe this is why dot.net programmers can’t give up managed programming languages. They do so many fancy things quickly, so a programmer can get a false sense of security. “See what I can do with dot.net” one may think, but how much of it have you really coded though ?

Myself though, I am a coder. I do believe in library code, both high level and low level, but the power comes from coding, really ! EZGUI’s runtime engine was designed for coders and the more quickly one appreciates this, the faster they will learn how to use it. Ask any long time EZGUI user and likely they will agree, that the “power is in the GUI engine” (the runtime). Now this may not sound very promising for many drag and drop developers today, but what I can tell you is this, once you see the power of the GUI engine and start tapping into it, you will find that you can do so much more than you imagined possible. I really believe this.

The Designer is only a high level tool for the GUI engine.

EZGUI’s Visual Designer is the first thing many new users see and the experience is not always the best for some. Why ? If you come to the designer from the aspect of your current programming experience, whether it be Visual Basic, PB Forms, etc., likely you may be disappointed at first. It does everything differently that your current tools. Nothing seems familiar. And likely you are right. Instead of just starting right in and trying to build an application, you really need to slow down and take the time to read as much of the help file as possible. You need to start learning about the GUI engine first. Actually you may be better off starting with the code samples in the codeclips folder. You see, the codeclips are not designer generated apps. They are hand coded. Hand coded you say ? Yes and there is something important here.

Hand coding, teaches more about EZGUI than anything else.

Unlike other programming tools, EZGUI as the unique ability to be used purely as a hand coding tool. I actually have some customers, who write commercial quality software using EZGUI, who hand code everything. They don’t use the designer. Not only is it possible, but some hand coders can produce apps faster and better than those who use the visual designer. These programmers are the ones who can honestly attest to the fact that the “power is in the GUI engine” and that being a coder is where you truly see that power. Now this does not mean I don’t want you to use the Visual Designer. I actually do. But you have to experience EZGUI using hand coding to understand the mindset behind the product.

The GUI engine was designed for fast hand coding.

Everything about the GUI engine, speaks ease of use when hand coding. For example, many DDT and API programmers wonder what happened to all the API constants they are familiar with. They are gone. EZGUI commands were purposely designed for minimal character typing. This is why is often uses property strings for commands, where a single character represents a property. If possible the command names are kept as short as possible. Constants are few in EZGUI, mostly used to define events and little more. EZGUI was designed for coders and they are the ones who quikcly grasp what it is all about. Even EZGUI’s use of character coordinates, rather than dialog units or pixels, speakes ease of coding. Actually EZGUI’s character units are superior to dialog units and easier to visualize in the mind (which coders require). They are scalable, but while dialog units often do not translate perfectly to pixels (because dialog units can’t handle fractions of a unit well at times), EZGUI uses floating point numbers for character units, so they can always translate perfectly to pixels, while still being scalable. EZGUI even provides functions for converting between pixels and character units, so you can work with both.

EZGUI is both high level and low level. It is high level when it really can make a difference, but it is also very low level so you always have the power to do almost anything.

The power is in the engine.

The average EZGUI user only uses a small portion of the EZGUI command set and they are always learning new ways to tap into parts of the command set they haven’t used yet. The ley to EZGUI is to always opt for an EZGUI command rather than resort to the Windows API. API programmers are more likely to start integrating API code too quickly into their apps. You see, EZGUI was designed so that in most cases one should never have to use a single API call at all. That is the mindset one shoudl develop. Always try to do it all without the API. You will find that your apps compile faster (no API includes required) and that your code is more readable and easier to maintain.  The GUI engine is so powerful it can do a lot for you that you don’t realize. Actually the runtime has a number of built in engines which are doing a lot of the work for you. This is why you don’t need any dialog procedures or window procedures. This is why you don’t use window messages. EZGUI is event based and it generates nearlly all the events one may usually require.

This does not mean that you can not add API code to EZGUI apps. EZGUI was designed so one can easilt integrate API code with it, when EZGUI can’t handle some task. But if you don’t learn how to do as much as possible using the EZGUI command set, you won’t appreciate when it is the proper time to integrate API code. EZGUI provides advanced features such as hook procedures and functions to return API handles, so you can integrate API code when necessary. But you have to do it the EZGUI way. You need to learn EZGUIs own command set first, before trying to integrate API code in your apps. So new users, no matter how experienced with the Windows API, should try to stick to EZGUI commands only.

The Designer was built upon the GUI engine.

The more you understand how EZGUI apps are written and the EZGUI command set and mindset, then the more you will appreciate its Visual Designer. The designer was designed to optimize the EZGUI command set. The code it generates is easy to read, but only for those who grasp how an EZGUI app works and the command set. Learn that first. This is why you don’t see familiar things such as window styles for controls. Simply put, you don’t need them or use them. The more you understand about how EZGUI impliments certain events such as low level mouse button events such as %EZ_LBUTTONDOWN, the more you will understand working with events in the designer. EZGUI uses subclassing to access such low level events, but subclassing is only to be used when you require a low level feature. Normally EZGUI generates the most common events (ie. %EZ_Click) without the need for subclassing. The designer knows what events require subclassing and what do not. So to get certain events, when you select them in the designer, it will generate the necessary code to impliment subclassing of the control (EZ_Subclass command). By just using one event which impliments subclassing, this makes multiple events now available. For example just by selecting the %EZ_FreeNow event in the designer (which requires subclassing), you will get access to many other events as well. So to appreciate the designer, you really need to understand the GUI engine.

The Smart Parser, a curse and a blessing.

When I first designed the Smart Parser, we were having debates in the beta forum (prerelease) about the best way to handle integrating visual design and coding. Many users wanted more control of how they edit code, so they did not want a built in code editor. They wanted to be able to use the PB IDE, Jellyfish or any other favorite code editor. This meant the designer had to support many different external code editors. There needed to be a way to allow the designer to control the UI creation code, while allowing the user to edit the rest of the code. The solution was the Smart Parser. Now while initially many find it confusing, it actually does make sense and it does work very well. One critical aspect here is the speed of code generation. You see, my own impression of many who use DDT and PB Forms (and powerbasic in general) is that they write apps with only a few dialogs/forms. EZGUI on the other hand was designed so one can build very large applications, possible with dozens if not hundreds of different forms. This required I design a parser which could handle the UI changes, but with minimal effort in reading (parsing) the source code. The smart parser does an excellent job of this, but with one restriction. It considers certain blocks of code as “protected”, meaning “don’t touch it”, since the Designer will always regenerate that code block. The routines which add the controls to a form are a perfect example.

Programmers using other tools like to add code before and after the control creation commands. EZGUI’s designer does not allow this. Now of course if you hand code you can do anything you want, but when using the Designer it imposes restrictions. If a routine is protected, simple put you can not edit any code in it. The designer must protect and control all code in those routines.

This technique produces clean code for all the UI creation and it makes sure you code always works as intended by what you designed in the designer. It allows for very fast code generation, event for very large projects with many, many forms.

The work around !

Some programmers get very confused by the limitations of the Smart Parser, but there is a work around and that is the GUI engine. You see, I recognized the problem with not being able to edit the UI code and rather than slow down the parser, I chose a different routine. I added features to the GUI engine which give you features not found in the API normally. For example EZGUI has a number of unique events designed to allow better control of the order code is executed. It has the %EZ_Loading event which occurs from within any control (or form) creation command, so that before EZGUI attempts to create the control/form you requested, it will generate an event (%EZ_Loading) and in that event you can actually modify the parameters of the controls creation command and change them dynamically. Also if you want to manually subclass a control you can call EZ_SubClass in the %EZ_Loading event and it will be just as if you had hand coded EZ_SubClass before the control creation command. There is also an %EZ_Loaded event which occurs right after the control is created so you can have code executed right after the control creation command is called. Forms also have the %EZ_Started event, after the form becomes visible the first time.

EZGUI’s event engine solves a number of problems for both hand coders and those who use the Visual Designer. This means that the protected code generated by the designer does not really limit you. You can add code in the events of the control and it will act just as if it was written before or after the control creation command. I know this is different for many, but not only does it work, but it works very well and is actually better in some ways.

In the Designer, you can tell it to generate the %EZ_Loading event for a control (%EZ_Loaded always occurs).

The smart parser actually is a good balance between control and speed. The designer needs to control some of the code, while you benefit from the faster speed of the parser. If you build very large projects you will appreciate this.

The light goes off eventually, so be patient.

Have you ever seen in cartoons when a character finally gets a great idea or something finally makes sense, they draw a lightbulb turning on next to their head. Actually this well illustrates how learning to use EZGUI occurs. Initially many are confused, because EZGUI is so different, especially the designer. The key is to ask lots of questions. If you give up in learning EZGUI without asking me (via email or the forums) any questions, then the result will be your of your own doing. You see, I not only expect new users to ask lots of questions, but I want them to. I know EZGUI is different and that written documentation just never does it justice. You need to ask those questions and lots of them if necessary. I had one new user who literally emailed me nearly 70 times before the light turned on so to speak. The point is that the light will eventually turn on for you too. This is the “tipping point” for most EZGUI users. For some it takes a few days. Others may take a few weeks, but it does usually happen. But guess what happens when the light turns on in the mind ? Everything starts making sense all of sudden. The reason is that there is a mindset behind EZGUI. There are good reasons it does things the way it does. The nice thing though is that this mindset is quite consistant in EZGUI. Once you get one thing all sorts of others things start making more sense. And this is where the fun begins.

The fun begins !

When things start making sense fo new EZGUI users, something amazing happens. They in short order go from confused to “wow, I can do this and that” ! They get excited. The start becoming productive. From here it only gets better, because once you see the power of the GUI engine, many realize that they can do so much more than they could before. Even those who those think they really know the Windows API quite well, may find that EZGUI does so much more than they imagined. I have said this before and I will say it again. Do not under estimate the power of EZGUI. You have no idea how much research into the Windows API I have done to build this engine. EZGUI 5.0 , the latest version, is so advanced that I doubt many Powerbasic programmers using the Windows API alone could do even half the things it can do. While DDT programmers are using the simple drawing command set of DDT, EZGUI users are doing 2D and 3D animation, low level high speed graphics and more.

Commercial quality apps !

I did not design EZGUI to be a tool for novices (aka. the EZ in EZGUI). Yes, I designed the command set to be as easy to use as possible. But EZGUI was designed for professional programmers who need to be able to build quality commercial applications. The stability of the GUI engine is one example of why commercial programmers love using EZGUI. The power of the GUI engine allows them to build applications that even their C++ peers would find hard to do, and especially with the amazingly small footprint of EZGUI.  Like any tool designed for professionals, there is a learning curve. This means to get the most out it, requires a certain degree of commitment. Unless you reach that point where the light in the mind turns on and you get it, EZGUI will be a disappointment to you. It was meant for those who were committed to learning the EZGUI way of doing things. The nice thing though is that once you start getting productive with it, things start moving very quickly. Some customers are writing dozens and dozens of commercial applications with EZGUI at a fast pace. It provides an advantage for their businesses. Fast, quality applications which can do amazing things, with an amazingly small footprint. Yes, the power is in the GUI engine and once you realize that, some exciting things can happen. And I am here with you along the way to help you get the most out of it.

 It is time to put to rest the idea that Basic is old fashioned, obsolete and a dead programming language.

 Not your fathers Basic.

 Basic has come a long way since the days of GW-Basic or QBasic. It has changed. It has matured. It has grown. What remains of the Basic many remember are two things.

 Basic is based on a more Natural (English like) syntax than any other language.

Core Basic hasn’t changed (ie. SUB / FUNCTION / IF THEN / LOOP)

 Beyond this, Basic has changed, has matured. How ? By taking the best from other languages, such as Pascal, C or Fortran, and adding it to Basic, while maintaining the Basic style of naturalness. Any new features added to Basic, must feel natural, for it to be truly considered Basic. Terse syntax from other languages is avoided if possible.

 Programming bias.

 Despite Basics maturity today, some programmers who may like Basic, still avoid it. Not because it is a bad language, but because of programming bias. Especially C++ and C# programmers will carry this bias, as if Basic is as bad as the plaque. Now why should programmers be afraid to use a programming language, which is capable of giving them the power they are looking for from such a language, simply because of bias ? Now that is sad and a shame.

 Oh, give me a break !

 Now, I won’t say that any programming language is the perfect language, since programmers are individuals with different styles and needs, so it would not be right or fair to say that Basic is the only language one should use. But I do believe the unfair bias of many programmers may prevent some from benefiting from a language which just could make a real difference in their software development. Does it make sense to let bias prevent you from using a tool which can help your business ? Even if Basic is not the primary language you prefer to use, it can still be a secondary tool to be used when it could really make a difference (meaning you don’t have to give up for day job, just to use Basic).

 PowerBasic, the one I know.

 I have mentioned PowerBasic in previous articles I have written, because it is what I have used for the last ten years and it is what I know. So its about time I introduce you to PowerBasic and tell those who read my articles, why I use it and how Basic has matured over the years. PowerBasic is definitely not your fathers Basic.

 PowerBasic, is what C should have been years ago.

 There is a reason why many of the Microsoft frameworks needed to come into existance. Simply put, the Windows API was a pain to write applications for. It just was not easy to write Windows applications in the days of Windows 95. You most likely would have to use C and write things like window classes, message loops, window or dialog procedures and you would definitely have to write a lot of SendMessage (API) calls just to make controls do something. It was slow going and a bother to many.

 So Microsoft came up with MFC (Microsoft Foundation Classes) so make things easier, which it did to a degree. But even MFC was not a panacea for some. Over the years, Microsoft programming languages have tried to improve productivity, by adding new frameworks, particularly dot.net. Yes, productivity is much better now, when it comes to writing Windows applications. But at a cost. Herb Sutter in is talk “Why C++?” says it all. Simply put, he brings out that such productivity was at the cost of performance. That is his viewpoint, so don’t argue with me about it.

 But something strange happened. PowerBasic came from obscurity and progressively built a strong base of users. In the old days (back with Powerbasic version 5.0) there was no GUI tools, no GUI command set. Those, like me, who were programming with PowerBasic had to learn how to use the raw Windows API. There was no MFC for PowerBasic. No dot.net. Just the raw Windows API. The strange thing though, was that PowerBasic programmers had two things going for them, that gave them an advantage over the C programmers of days gone by (before MFC).

 (1) The PowerBasic peer to peer forum with a world wide group of excellent programmers.

 (2) PowerBasic, was Basic, so code was more readable, easier to maintain.

 The first challenge of grasping the Windows API, was dealt with because of PowerBasic’s online forum. The forum brought together the best of the best, the cream of the crop. To this day I am deeply impressed with the knowledge of many who visit these forums. Powerbasic takes this forum so seriously, you can not use an alias. Yes, some of have actually lost their privilige to use this forum, simply because they tried to get away with using an alias. This forum is a professional forum, where programmers take seriously sharing with one another the secrets of tapping into the Windows API. They do not hide who they are, but they share their knowledge of the Windows API. Because of this, over the years, a number of these forum users have become experts of a sort in specific aspects of Windows. From these, some have become third party developers of tools which make Powerbasic even better.

 Because Basic is so much more readable and natural than C, code using the Windows API actually is more readable and makes more sense when you see it in Powerbasic syntax, compared to C syntax. PowerBasic is what C should have been, when Windows first came along. Programmers would have had less problems in writing applications and would not have needed bloated frameworks, which may help productivity, but also slow down applications and also make them resource hungry. In the days of Windows 95, you could live with just 8 or 16 meg of RAM. Today, Windows is so resource hungry that it requires at least 1 gigabyte of memory. Powerbasic is so efficient a language, you can still write apps for a Windows 95 computer with little memory, so imagine how well they run on Windows 7 (or with 2 gigabytes memory.

 The power is in the compiler.

 You may laugh, when I say that the people at Powerbasic count CPU cycles, but in the end they get the last laugh. Programmers have wasted the power of the PC for years, simply because they assumed the computer was so powerful they didn’t have to care about the size or execution speed of an application. Computers have gottem more powerful, but we don’t see the benefits, because Programmers have not cared about writing efficient software. Well, at PowerBasic they do care and now with the advent of the tablet computer, they get the last laugh. Because tablet computers have minimal hardware, the bloat in most applications shows up now. As Herb Sutter so well put it, “the free lunch is over”.

 There are two things PowerBasic programmers are confident of when they write software. First, they know the compiler was designed to generate the fastest, smallest possible applications. Second, they are confident that the compiler generates reliable machine code. But the real power in Powerbasic is the language.

 The power is in the language.

 While, PowerBasic programmers may seem at a disadvantage because they have to resort to writing applications using the Windows API, the strength of Powerbasic is the language itself and how it makes it possible to do some amazing things. Access to the Windows API is easy because the language was designed to tap into the API. Powerbasic can make calls into the Windows API, into DLL’s written using C or C++ or Pascal or other languages and it even handles low level COM, which allows it to integrate itself with all sorts of other languages. I am not a COM expert, but there are those who use Powerbasic who grasp COM very well and PowerBasic’s latest compiler (version 10) has strong support for COM interfaces. Powerbasic also has its own object oriented features (classes) built on the COM features of the Windows API. So if you prefer writing classes or using COM, then PowerBasic has features for you.

 But you don’t have to write applications using classes or any OOP at all if you don’t want to. Like me, there are those who prefer 100% procedural style code and you can still do powerful things with Windows, without any OOP at all. The choice is yours though.

 When it comes to building the user interface for applications, PowerBasic for awhile was at a disavantage, but once again their peer to peer forums saved the day. It was from these forums that programmers began to encourage drag and drop design and from this a number of solutions came forward. Powerbasic developed their own Visual Designer and their own simpler UI command set, so anyone can build a Windows application using their proprietary DDT (Dynamic Dialog Tools) command set. It just makes things easier. Then some third party developers, built drag and drop designers which emulates Visual Basic in some ways, but using the pure Windows API for UI coding, which provides an alternate way to develop applications. Third party developers began to create custom controls, such as grid controls and even powerful graphic engines and skin engines. Myself, I went the route of building a GUI engine (a GUI framework) as a third party developer.

 The reason such third party tools became possible though, was the power of the language in the first place. With some other languages, like Visual Basic (5/6) extensions to the language often were written in C++ and not the language itself. With PowerBasic, the majority of third party addons are written in PowerBasic and not C++. We extend the language using the same language.

 Low level is the name of the game.

 The compiler itself generates very fast machine code, but the language was designed with many of the power constructs one would expect from C or C++. For example, PowerBasic can be very, very low level when you need it. You can work with pointers, pointers to pointers, etc. You can have code pointers as well, so it makes it very easy to dynamically call Windows API’s without having the application be totally dependent upon those API’s. I use this often myself. For example, how do you make a DLL, capable of accessing features unique to say Windows 7, but yet still able to run on Windows XP ? Simple. In Powerbasic you just call a few API’s to see if an API exists and what operating system it is, then if it exists you can dynamically load a DLL and call the functions via an address (CALL DWORD command in Basic). If the API is not present then you simply provide an alternate way of handling the task.

 Powerbasic allows you to define specific variables as Register variables for improved speed and it is completely under the programmers control. PowerBasic can even do inline assembler, so you can combine Basic and assembler together.

 PowerBasics string command set is as good as it gets, both ANSI and Unicode. The string functions are optimised for speed as well. Powerbasic uses Windows OLE API’s for storing strings, so you can have huge strings in memory (how about a 100, 200 or 500 megabyte string ?). One nice feature I like is the ability to define structures (TYPE in Basic) via pointers, so I can actually use a string to store the data, but simply access the data via a pointer.

 PowerBasic has functions for working with bits and bit flags. You can even have bit arrays. It has a wide variety of built in data types, even QUAD based integers, 80 bit floating point and variants. You can even do unions and overlay one data type over another.

 Advanced command set.

 PowerBasic has a number of matrix commands for high speed access of a matrix (ARRAY in Basic). For example you can sort an array, but have the indexes to each item (in the proper order) written to a second array so you don’t modify the original array. And it is fast !

 Powerbasic can do TCP and UDP communications, which is a very popular feature of the language. Building applications which interface with external hardware is also popular using serial communications, which is also built into the language. PowerBasic has its Dynamic Dialog command set (for UI’s), graphic command set and printing command set too.

 PowerBasic comes with its own COM browser for generating pure PowerBasic code for accessing external COM objects.

 And if one can’t do it with native PowerBasic commands, then one still has access to the pure Windows API and PowerBasic programmers are known for doing all sorts of things, even if the language does not directly support something.

 What have I done with Powerbasic ?

 While I don’t want to go into detail about my own work with PowerBasic in this article, this much I can say. I keep being amazed at what I can make the Windows API do. There is always new stuff I find that I can do. I started out building a simple GUI engine, to make it possible to build PowerBasic applications without using the Windows API. Today, I do stuff, using PowerBasic, that demonstrates that the Windows API is a powerful thing and still quite viable even with Windows 8. I have learned how to tap into the Windows DIB engine and built my own Canvas control, with low level DIB support and a proprietary 2D sprite engine (no DirectX needed). I have learned how to tap into features like Ownerdraw, so I don’t have to buy a number of third party OCX controls like Visual Basic programmers were known to do, but I can build controls to my own exact specifications. From this I built my own Files Listbox control and Property Listbox control and others. I work with things like threads, complex window regions (you know those apps which are not rectangular, but are shaped like an object), image filters, superclassing and subclassing. I built my own drag and drop engine, just so I could build my own visual designer using it. My most recent task, was to build a real OpenGL based control. You aren’t limited t just one graphic window, but you can have multiple 3D OpenGL child windows all on the same form. It even has its own proprietary 3D scripting languge and can display STL 3D file format models with thousands of polygons. Not bad for Basic !

 This much I can say is that much of the credit of what I have developed goes to the amazing PowerBasic compiler. To be able to produce applications and libraries with an amazingly small footprint, highly reliable and fast, just could not have been done without Powerbasic.

 Can’t do it justice.

 What I say here, just can not do justice to Powerbasic. So if you are thinking of something like GW Basic or QBasic and spaggetti code from Basics of old, when I mention Basic, please realize that Basic has grown up. Basic has matured. Basic today can be on par even with the latest C compilers (Powerbasic is more akin to C, than C++). So when someone comments about Basic being a dead language, Basic being old fashioned or Basic being obsolete, then just remember, they really don’t know what they are talking about.　

OOP is a theory, not a fact !

Object oriented programming is a concept, a theory, about how programming can be improved. From the early days of OOP, object oriented programming was basically promoted as a way to build software faster and better. It supposedly would increase code reusability, code readability and in so doing improve programming. But has it ?

OOP or Procedural ?

As far as I can tell, there has been little research which proves OOP is better than procedural coding. Oh sure, college professors will tell students that OOP is superior, but that does not prove anything. How many college professors are actually writing real world software while being under a time constraint, like a programmer who does it for living ? In the real world, software projects are started and then at times fail, because of being over budget, poorly designed or just plain buggy.

What is software really ?

Software simple solves a problem or handles a task. For example if all you needed from a program was to allow a user to input two numbers and then have the program do a complex calculation, this should only take just a very few lines of code. No complex planning needed here. Just create a form, put two input fields on it and a button with the word “Calculate”. Click the button, read the two text fields, convert them to numbers and calculate and then display a messagebox with the answer. Not so hard was it ?

But, this simple task does not have anything to do with objects. Besides, what is an object anyway ? An objects purpose is to store data per an instance and then allow feedback between the application and that data. In some cases the data is displayed (aka. a control like a listbox), while in other cases the data is simply data related to a task. The idea behind objects is that by building objects which can be reused (or even inherited by a bigger object), that you end up writing less code, because you can reuse objects over and over again. Seems to make sense, doesn’t it.

I recently watched a training video about C++ which discussed objects and the speaker used an example such as an object which is for animals and how both a cat and a human are animals and have things in common, so both can be built upon the basic animal object, so they inherit the base class.

OK, in the real world a cat and a human, while having just a few things in common, are so uniquely different, why would anyone want to even build a software data type (object) so they could save time by somehow merging the two together ? The problem here is that OOP is at times taught using poor examples, which really aren’t of much value any way. Not everything in life is an object. Not everything in a software application needs to be defined as an object.

I find it interesting how in recent years the agile method of software development has been promoted (and it has some merits) so software development can be sped up, yet the question of whether OOP really is all that productive or not may not even discussed.

A different perspective.

You may wonder why any programmer would even suggest that procedural coding can be as good, or even better than object oriented. You have to consider when and how a programmer learned his/her trade. In the early days of computers, many programmers were self taught and not trained in the halls of higher education. In my own case, I did have one actual college course in programming back in the 1970′s, which was fortran, but it was a class where I had to write out programs using punch cards and then have them fed to a main frame computer. Beyond that though, my training has been the product of being self taught. I learned what I needed to learn to solve problems. When I wrote custom software for businesses, I would examine the task and if I lacked something to solve the problem, I simply would do a good bit of reading to find solutions which would work. In the process of developing custom software for a number of years, I learned how to build applications faster by reusing code (building my own libraries and tools) and by learning how to code quickly. I was always looking for ways to speed up development and make it more reliable.

The strange thing about being a self taught programmer though, was that never once did I find myself with a difficult task and the idea of building an Object came to mind. Yes, common tasks could be written as reusable libraries and this especially made a difference in user interface code (ie. menus, scrolling screens, etc.), but the idea of objects never came up. It wasn’t until I moved to Visual Basic, that the concept of objects with properties and methods even came into view. But even there, I could deal with the UI stuff as far as properties and methods, but the rest of the code was written purely using procedural code. Each iteration though of Visual Basic became more object oriented than the previous one. True, Visual Basic, is not considered object oriented by some today compared say to C++, but is was object oriented to a degree and for a procedural programmer it had a lot more OOP than one was used to.

Machine language affects ones viewpoint.

In the old days, a programmer had to use every way possible to speed up their software and machine code was critical. The compiler one chose and how well it generated machine code was vital. Experienced programmers likely would venture into assembler to add speed where it would make a difference. That was my experience. Before the days of the IBM PC, I learned 6502 machine language, even writing my own compiler. When I started writing software for the IBM compatible computers using QuickBasic, I also learned some assembler so I could write some very fast routines. My PDS 7.1 (Microsoft Basic) code was so complex, that I couldn’t even compile it from within the IDE, but I had to build batch files to run the compile process, so I could get the optimized features I required.

Looking back over the years, I honestly feel my learning machine language (and assembler) was extremely valuable. It helped me better appreciate what was really going on with the computer. My BASIC code, which was more like human language, was being compiled into low level machine code, so how I coded using a higher level language, directly effected the machine code the compiler generated. This is why the so called “dreaded” GOTO command and its cousin GOSUB , are actually valuable tools for a programmer, despite all that has been taught about it being obsolete and poor programming style. Do programmers really appreciate how many machine language GOTO’s are being generated by the compiler they use, even if you don’t use a higher level language GOTO command ?

Assembler language lends itself more to procedural style coding, than to something like objects, which can effect the mindset of programmers who use it. Maybe this is why I find assembler and a procedural style language like the BASIC I use quite compatible. Many concepts are similiar between the two.

Agile programming and procedural coding.

As a long time procedural programmer myself, I have found that a procedural coding style actually lends itself to faster software development. It is as Agile as one can get. A procedural coder can just write code quickly to solve a task and do this over and over again and in the process some code stands out and the programmer can see that maybe certain code would make a good library routine, so on the fly, a library is built. Not because it was planned out, but it simply made sense and the code was already there and it works, so a programmer just makes a few changes and now we have a routine which is reusable.

I guess I break all the rules for programming that many learn in college. For example, I don’t usually self document my code. Because I use an easy to read language (Basic), the majority of time the code is quite readable. I also use variable names and subroutine names with meaning, which is self documenting. I don’t create flow charts for the code. I just code and do it quickly. Rather than over plan my code, I simply build routines which handle a task. First make the routines work. Once you have that, one can go back and determine whether it needs to be faster or improved somehow. The idea is to build upon working code. The key is to make it work. Then go back and improve it.

Object oriented programming is not agile in my opinion. It requires too much planning. When OOP goes bad, programmers will likely say it was poorly planned. But if OOP requires so much planning, that only experts can master it, then maybe it isn’t as efficient as one may think.

Now where I find planning is critical is in laying out the data that the application will work with. All the software I wrote for local businesses, had a unique database engine written for each application. I would design a database around the task, rather than design the data around a predefined database engine. If a flat file would work, I would use it. If a Btree would work better I would use it. If a custom database was required for optimal speed I would create one.

You would be surprised at how procedural coding lends itself to writing fast and amazingly small applications or DLL’s. For example there is a BTree engine which I wrote back in the mid 1990′s, specifically to solve a problem I had when writing a database for a custom application. In recent years I ported the code to Powerbasic and the resulting DLL is only 17 KB in size. How many database engines do programmers use today, which are only 17 KB in size ? I offer it as freeware for Powerbasic users ( http://cwsof.com/freeware/freetree.zip ).

In writing software I see data, user interfaces, printed data, calculations, tasks. I rarely ever seeing anything as an object or somehow visualize that objects are the purest form every aspect of my software should attain to. Objects, if I were to use them, would only make sense when something really is well suited to being an object. Even then, many times a data structure of some kind defined as an array, makes more sense that an actual object.

Try it, you might like it.

Because many programmers have been trained to think of everything in terms of objects, they may not even be capable of writing an application using a minimal amount of OOP. Yet if you have an opportunity to experiment and try building an application with as little OOP as possible, you may find it a real learning experience. Maybe try it on a small project or even a personal project at home. Try to build an application using purely procedural style coding methods. Make sure though that you build your own libraries of reusable code (as functions and subroutines). Resist the temptation to turn something into an object or a class. You may just find the experience invigorating. Even if this experiment doesn’t change your mind about OOP, you may find yourself using OOP just a little bit less, when procedural code would do the job quicker with less planning.

The benefits of procedural coding.

I really do believe that procedural style coding produces faster and smaller applications than its OOP counterparts will. I won’t spout theory or even try to provide some kind of benchmarks to prove it to you. All I can say is, that I have been a long time procedural style coder and from pondering the results of my own work over the years, I have little doubt that procedural coding has helped me produce amazing results which run fast and with a tiny footprint. If you are looking for edge, when it comes to developing software for the coming generation of mobile computers (aka. tablets), then seriously consider an alternative to OOP, procedural coding.

I am a 100% procedural style programmer and I don’t feel OOP is really all that more superior than procedural style coding. Now there are a number of viewpoints about why OOP is not any better, but for moment, I will state how I view OOP. I don’t have anything against it, but neither do I feel it is some how inherently superior either. The idea that everything needs to be an object is just plain false. Now there are some cases where the concept of objects may ber very useful, but rather than view it as a core programming style, IMO objects should simply be considered just another data type (albeit with some code attached). Just like you choose different data types for different requirements, objects can simply be just one more tool in your toolbox. I just don’t think OOP should take over a programming language so everything tends to be an object.

OOP requires a lot more planning up front, so in the long run if it is used indescrimently, then you will end up taking a lot longer in writing software and make it more complex. When OOP as a data type actually fits the job, then it may just be worth it.

The idea of things like COM, ActiveX and now OOP originally were thought up to encourage code reusability. Some suggest that OOP produces better software because you can reuse OOP objects. In my own experience though, I have found that rarely can one reuse overly complex blocks of code. The more complex code is, whether as an object or as a procedure, the more likely it is too unique for it to be used over and over again. The simpler a piece of reusable code is, the more likely it can actually be used over and over again.

To illustrate:  Imagine you write a routine or an object, which has the sole purpose of drawing a line of text. It may have a few options, such as defining the font to use and the text. Likely such a routine would be used a great deal, so code reusability works well. Now imagine you create a routine or object, which has the sole purpose of drawing a line of text at the perfect center of a circle and only useing a specific style font (always fixed width). Now this may be useful for the current project, but it does not sound like something one may use a lot. Why ? Because it is more specific, tied to a specific project. So the more complex a routine or object becomes, the less likely it will be used over and over again and if one attempts to try to use it in places where it is not well suited, it will be more like a round peg in a square whole.

I believe this may be at the core of one problem with any code reuse, but especially with objects. Objects tend to be much more complex than procedural routines, because you can build complex data types into them and add many layers of code to them (methods). While one may build an object which can be reused, the idea of using that object to build upon to create even larger more complex objects, simply creates all sorts of problems. The idea of inheriting and building upon another object, sounds great in theory, but in reality it could end up making software more complex and slower, because if you build too many times up previous objects, the complex increases greatly.

Procedural style programming tends to encourage building reusable routines which are smaller and more managable. For example, one may have a complex calculation used a lot in a trade and it could be turned into a useful function. It saves a lot of code, because you reuse it over and over again, but it is small and managable and one is less likely to make changes to it which will break other code. Objects tend to be complex, so many changed internally could be common. Procedures and functions tend to be smaller and more task specific, so one rearly needs to change them, unless they are broken somehow, so the code is less likely to cause problems elsewhere in an app.

I strongly feel that code reusability is viatl for faster software development, but that procedural style coding can produce much better and more efficient reusable libraries. Also I tend to build libraries on the fly, rather than over plan them. The reason is that one never knows whether a routine designed to be reused will actually be used that much. Now if I start coding and I see that some code I wrote is being written multiple times, then it becomes obvious that such code should be put into a reusable routine. This decrease the amount of planning that has to go into designing an application, but yet still encourages code reusability. There is no harm in writing code to be used simply once and then to later find, that it would make a good routine. You see, the code has likely already been tested and you know it works and now you know it would be worth the time to convert it into a procedure or function and most of the time it takes little effort to copy a block of code and turn it into a function. If libraries are built this way, then the routines are more likely to be truly valuable. You saw the need to move it to a function in the first place, so it is obvious it can be reused a lot more.

My own GUI engine was built this way. It progressively grew and sections of code which once were embeded in the library, were taken out of a large section of code and converted into a smaller more managable reusable routine.

Now some programmers have some very strong viewpoints about OOP and why it is not as “rock solid” as some would have you believe. Now while I may not agree with every view of these programmers, they do have a number of valid points worth considering. Here are some links to some very interesting articles:

This is my favorite, by Richard Mansfield:  http://www.4js.com/files/documents/products/genero/WhitePaperHasOOPFailed.pdf

Some more articles:

http://blog.dmbcllc.com/2008/05/13/object-oriented-programming-has-failed-us/

http://www.bitwisemag.com/copy/bytegeist/bytegeist1.html

http://www.cs.loyola.edu/~binkley/772/articles/oopbad.htm

I have some customers who do a lot od development for Linux using WINE and EZGUI has turned out to be a great solution, so they can write Windows apps, but they run just as well on Wine.

I recently had someone test my Windows 8 test app, which does all sorts of stuff, such as ownerdraw, sprites, graphics, 3D, custom controls and more and it ran very well on OS/2 (EComStation). EComStation and OS/2 also use a form of Wine so it can emulate Windows to run real Windows apps. So for EComstation users, EZGUI (and PowerBasic) may be good solution. You can write apps which should run reasonably well on EComStation (using Wine), but also run just as well on Windows.