My idea of the ultimate programming language for me !

Today, programming languages are a “dime a dozen” and there are many independent (indie) languages as well as core mainstream languages being used.

Many indie languages tend to target game development, while most business software is developed using mainstream languages like C# and C++ (Microsoft languages) (aka. Visual Studio).

So what would be the ultimate programming language ?

Personally, I think programming has gone astray and is too complex today. One of the most popular programming languages, (classic) Visual Basic, was abandoned in favor of dot.net based languages.  Being a long time BASIC programmer has taught me a number of things about programming which I think could be the basis of a concept for the ultimate programming language. Now before readers of this blog jump on me being a BASIC programmer, let me also add that I have some experience in assembler language and also a great deal of experience as a WIN32 programmer, both with are pretty low level compared to what the average programmer works with today.  Let me explain some of the core principles of software development which I strongly adhere to first.

Nothing beats native coding !

While I appreciate the need to at times shield programmers from the complexity of low level programming and the core of an operating system, like which was done with classic Visual Basic, I have found though that performance is closely tied to lower level programming. If there is one thing I do not want to give up, it is performance. I will at times compromise some performance for the sake of ease of use, but not too much. Native coding allows programmers to push the limits of an operating system to the maximum. The problem with native coding though is that it is often too low level and at times operating system API’s are poorly designed and lose any sense of ease of use. So what is a programmer to do ?

I really liked classic Visual Basic, with its fast rapid application development design. One could prototype an application in no time at all. But experienced Visual Basic programmers often found the language limiting, so they would resort to calling the Windows API directly. The language was also not well suited to low level coding. Something more was needed than what Visual Basic offered.

From the frying pan into the fire !

Over ten years ago I dropped Visual Basic in favor for of another language, PowerBasic. Back then PowerBasic had absolutely no GUI command set at all and no visual design environment. The only way to code a GUI application was to hand code it using the Windows API (WIN32).  C++ programmers gave up coding using the WIN32 many years ago, most likely because it was a bit too low level and complex. So learning to program using the Windows API, even with a BASIC language, was no easy task.  The WIN32 is too low level and cryptic at times. I was one of the first PowerBasic programmers to see the need to an easier way to code a user interface and my own EZGUI 1.0 was born. It was initially an inhouse tool, but then I saw the value of turning it into a commercial product. I also saw the need for drag and drop features so I could build my own visual designer.  My first visual designer was very rudimentary, to say the least, but it worked. But what I learned from the experience was very important. A user interface engine (GUI) was more important than the drag and drop environment. I quickly realized that the Windows API, could have been designed to be more user friendly if they had wanted to and that low level need not mean, hard to use. There is a proper balance between low level features and complexity. Low level, need not mean overly complex. So I began to build my own GUI engine (framework) on top of the Windows API. Unlike some frameworks, it was not meant to replace the Windows API (ie. some cross platform frameworks, which do not fully utilize the native OS), but simply to make what was available easier to access  and less prone to errors. As I built my GUI engine, I did not totally shield the programmer from the Windows API, but instead made it easier to tap into the power which was there.

For example, while other PowerBasic third party developers concentrated on the drag and drop experience, I concentrated on tapping into the Windows API, making core functionality more accessable. For example, the DIB (Device independent bitmap) engine in Windows is very powerful and it offers many possiblities for building very low level, performance enhanced features into 0nes software. The ownerdraw functionality in Windows was a stroke of genious and it also deserved to be more accessable. Dynamic link libraries (DLLs) was also a stroke of genious on the part of Microsoft, making Windows more efficient and dynamic. For example, one problem in a lot of software is when more current API’s are used and the software loses backward compatibility with previous versions of the operating system. Dynamic Link Libraries solves this problem, allow you to load a library at runtime, poll it to see if it supports certain features or API’s and then to use them if available and if not use an alternate means (or simply turn off the feature in your app). DLLs are in my opinion one of the cleanest and fastest forms of libraries for use in an operating system.

OK, I saw the power of the Windows API. True, initially it was like going from the pan into the fire, learning how to use it, but it was well worth it. But there is one big weakness of the WIN32 API. It is not well suited for RAD development.

High level need not mean no low level

In developing my own GUI engine I quickly learned that one need not give up low level, just for the sake of high level RAD development. The two can be blended together in a much more friendly package. But rather than give up one for the other, a more middle of the road approach makes a lot more sense. But how does this effect a programming language ? Classic Visual Basic was designed from the perspective of the drag and drop environment, rather than from the lower level direction. One did not code a Visual Basic app outside of the visual designer environment.

PowerBasic, though had the avantage of being very low level and one could code an app using any code editor or IDE you chose. The language was actually based on the compiler, not the IDE.  PowerBasic though lacked the RAD fetaures we all need. Even today, PowerBasic’s best RAD functionality comes from third party tools, rather than from the IDE which comes with the language. The FireFly designer ( http://planetsquires.com  )is the most popular and best all around drag and drop environment for use with PowerBasic. But the approach I have taken with EZGUI Professional, taps into the real power of Windows. It makes the features of the operating system itself more accessable. It better blends high level and low level. Why ? Because, high level is nothing is not built on a better low level engine.

This is where programming language comes in. If I were to build my own programming language today, it would be a blend of classic Visual Basic, PowerBasic and my own EZGUI. PowerBasic is the real work horse here in that it is a native compiler which is fast, fast, fast. It is very low level in that things like pointers, unique custom data structures, inline assembler support and it has one of the best string command sets around in a programming language. The compiler itself it written in assembler so it compiles probably faster than any other compiler and the compiler is stand alone so it is not dependent upon any specific IDE.

Visual Basic demonstrated the value of drag and drop design and third party developers of tools for PowerBasic have seen the need for better and better drag and drop environments. Even my own EZGUI has its own Visual Designer environment, because most programmers need some kind of visual drag and drop environment.

BASIC is one of the most human readable programming languages and it provides a syntax which is easier to learn and faster to code and in my opinion, easier to debug.

The last thing though is the GUI engine or command set of a language. EZGUI is not perfect, but it does demonstrate one thing though. A GUI command set can be easy to use, but still provide low level access to many of the features of the operating system. The real test of a GUI command set is whether it is easy enough to be used stand alone. Imagine trying to build an application without the help of a visual designer. Could you do it ? That was my goal with EZGUI and I believe I succeeded ! I have some customers who pefer to hand code their entire applications, rather than use the visual designer which comes with EZGUI. Before building the RAD environment of a programming language, I feel that it would be better to build the language first as a stand alone language. Make it possible to code an entire application in a simple code editor. If the GUI command set is easy enough to use when hand coding, then imagine the power it would have in a visual design environment. Also the GUI command set should provide low level access so a programmer can customize their apps far beyond what comes with the language. EZGUI would make a good template of how this is possible. EZGUI supports low level ownerdraw, customdraw, subclassing, superclassing, DIB (direct pixel) access and more. High level and ease of use, need not mean no low level features. In EZGUI I provided two ways of accomplishing many tasks. One a mid level, easier way (ie. simplified ownerdraw command set or simplified thread command set) and then a more lower level version so one can have more freedom to customize beyond what the GUI engine was designed to so.

Interested to see how come things are coded using EZGUI commands ? Check on my support forums and take a look at some of the posted code: http://cwsof.com/forums/index.php

I learned an important lesson with EZGUI. For example, I recognized the need for a visual designer for my software tool. One of the problems with many indie programming languages (many BASIC flavors in the Indie language world) was that they often has terrible visual designers. Why ? Because the language was not well suited to writing a visual designer. When I created EZGUI I recognized this and built drag and drop into my GUI engine, so when I started writing a visual designer , the GUI engine had all the core features necessary to build one. The only thing I haven’t written yet is my own code editor control. I could have used an open soource one and add a built in code editor to my designer, but I won’t consider adding this until I write my own code editor control. But when it comes to the drag and drop stuff, EZGUI 5.0 has basically everything necessary for this.

The core GUI engine of a programming language is one of the vital aspects of a programming language. Classic Visual Basic fell very weak in this area. True it supported components, but its native support for low level GUI customization was very limited. Subclassing, superclassing, low level DIB support, etc should have been supported. OwnerDraw should have been supported. Threading should have been supported. And all of this without having to resort to the Windows API.

So what would be the ultimate programming language ?

• The ease of drag and drop design of classic Visual Basic
• The low level power of PowerBasic
• Stand alone compiler like PowerBasic
• The rich core language of PowerBasic
• The flexible and easy to use GUI command set of EZGUI 5.0 Professional
• The low level GUI command set of EZGUI 5.0 Professional (ie. drag and drop)

OK ! I am biased ! But trust me when I say it could work.