Programmers are always on the look out for new ideas for a programming language. So as a software developer with many years behind me, here is my take on an idea which could make a big difference for software development for Windows 8 and the coming “Internet of Things”, if it were to be implimented. This story will take some twists and turns, so don’t get caught up too quickly with the idea of bring classic Visual Basic back.
Classic Visual Basic, a starting point
First, I would start with everything I thought was good about classic Visual Basic. Classic Visual Basic was a very simple development system when it came to user interface design. It was clean, simple and easy to use, even for beginning programmers. Key reasons why it became one of the most popular programming languages around, was how quickly you could prototype an application, it had a simple IDE without too much clutter, it didn’t require a leading edge PC to develop on and the language was based on one of the easiest languages to learn, BASIC. BASIC has a very long history behind it and it has demonstrated over and over again that it is a language worth using. The easy and more natural language syntax makes it a great language for both beginners and professionals. A lot of usable legacy code (non-user interface) is still around from the DOS (BASIC) days and early Windows (Visual Basic). Microsoft set the standard for BASIC back with Quick Basic (and later PDS 7.1). So Visual Basic is a good starting point for building a new programming language. Also I think that some may not realize that one of Visual Basics biggest strengths is something that most consider a weakness today, at least from my experience it is. Classic Visual Basic allowed a programmer to write code in a more procedural style. Some viewed Visual Basic as not going far enough when it came to Object Oriented Programming, but its strength was how easy it was to code using a procedural style of coding, but still offering a RAD development environment. From my own experience, I find that procedural coding can not only be as modular and reusable as OOP, but it allows one to build software with a much smaller footprint, is easier to debug (much easier to follow code flow) and a good approach for building the next generation of tiny applications for the coming “Internet of Things”. Herb Sutter in his talk “Why C++?” discusses important aspects about the importance of building software which performs better and requires less resources. But I would go further. I would suggest, “Why not BASIC ?” and I mean a more procedural style of BASIC with the power of C (not C++), but with the ease of classic Visual Basic.
Lessons learned from experience. Something different.
Visual Basic though, failed in a number of areas. It wasn’t because it was designed poorly, but because the original goals were different. Ease of use and component reuse were key aspects of classic Visual Basic. I don’t think many realized how popular this language would become and how many “hobby” programmers, as well as professionals, would build commercially viable software with it. But its initial strengths would also later be part of its weaknesses. First let me discuss component reuse. COM based components (aka. OCX controls) created a huge market for third party development and Visual basic programmers often solved problems with such addons. One problem though, was that this created a dependency upon COM based components, which were much more bloated (size and resources used) than its simple DLL based counterparts. Applications were not as easily installed. You couldn’t just “copy and run” an app in some instances. Classic Visual Basic wasn’t originally a native compiler (native machine code), but was a PCode compiler instead which slowed things down a good bit. Later a real compiler was added, but from what I have read it was not a native BASIC compiler, but instead a C compiler backend tha was added to provide this functionality. You can better appreciate the difference between a real native code BASIC compiler and using a C backend, when you realize that companies who built addons for Visual Basic (OCX controls, libraries) often had to write them in C, rather than Visual Basic. Visual Basic was limited in what you could write with it. This is why years ago, another Basic compiler maker, Powerbasic, marketed their product as an addon to Visual Basic for writing fast DLL’s which could be used by any language. Visual Basic was not originally designed as a true compiler, like other languages were. This affected how it was developed and later on it showed.
A new Basic programming language, similar in design to Visual Basic, would need to be able to compile directly to machine code well enough so the language could be written in itself. Any runtime GUI library which it would support, should be built using the language itself. This means the core functionality of the compiler must only depend upon the WIN32 API and no runtimes and higher level libraries (static or DLL) would be compilable using the core compiler. When smart devices start getting smaller and smaller, machine code performance is a must. A new Basic language should have the same ease of use as classic Visual Basic, but it should be designed from the ground up to work more closely with the native WIN32 API. Instead of overuse of Object Oriented syntaxes, instead it should reflect the core WIN32 API better. Of course, one shouldn’t have to write window procedures and message loops with it, but it should allow you to if you want to. It should be just as natural to write pure WIN32 code with it as it is to write more high level code with it. The GUI feature set of the language, rather than be built upon OCX controls should be built upon both a runtime engine (DLL) or a static library counterpart. One of the things I disliked about classic Visual Basic was that the common controls and common dialogs were in separate OCX controls. The size of those libraries were far too big for the functionality they provided too.
Classic Visual Basic was too far away from the WIN32 API. For example, its native controls were actually superclasses of the operating system native controls (which is why their class names started with the word THUNDER if you took a peek at them). Maybe this was done to better impliment the Object Oriented aspects of the language, but they were fixed in stone, rather than being flexible like native Windows control classes. Native window classes allow you to easily build upon them using subclassing and superclassing. A new Visual Basic should make such things natural and part of the language, rather than an after thought. A new Classic Visual Basic should be as powerful as C, but with the ease of BASIC. There is already a BASIC compiler available with this kind of power , PowerBasic, with the raw power of C (and full access to the WIN32 API), but it lacks the ease of use of Visual Basic and also it lacks higher level GUI features which are important for faster development. As a WIN32 programmer myself, PowerBasic is about everything I would want in a compiler, but when it comes to RAD development it can’t even compare to classic Visual Basic. Even as a WIN32 programmer, I don’t want to spend all my time at that low level. At times I just want to be able to build an application as fast as possible.
Unlike classic Visual Basic though, I would prefer to see us go back to simpler modular design techniques via dynamic link libraries and static libraries. They are better suited for building the tiny applications which will be needed for the coming “Internet of Things” devices. If designed correctly, a compiler of this sort could be capable of building applications which perform well even on the lowly Intel Quark SOC (System on a Chip). A programming language with the ease of classic Visual Basic, but the power of a raw C compiler would provide for faster software development and would also appeal to a greater number of hobby programmers interested in just building software easily.
Is this possible ?
Actually, not only would such a programming language be possible, but it could speed up development for future “tiny” Windows devices at a pace similar to when the original classic Visual Basic was introduced. But with a big difference. It should be developed from scratch with totally different goals. I would like to see it patterned after the PowerBasic compiler which allows a programmer to write very fast and tiny applications as well as any C programmer. But PowerBasic is too low level, so the next step would be to build upon it higher level layers (in both static and DLL format) for the Graphic User Interface features as addon libraries rather than simply built into the core language itself. Since being able to use a lot of legacy code is important, different GUI engines could be buiod for different purposes. A GUI engine could be built specifically for backward compatibility with classic Visual Basic source code. This way developers could bring legacy applications back to life. But other GUI engines could be built for different purposes such as a leaner, smaller, engine closer to the WIN32 API capable of running on the most minimal hardware possible. Classic Visual Basics GUI engine was too dependent upon the COM model and is bloated in comparison to coding a GUI library specifically to tap into the WIN32 API at its lowest levels using a more procedural style of coding. Most of the core WIN32 API is a flat API, rather than object oriented. Even GDIplus comes in a flat API, besides its C classes. New GUI libraries could be built which require one tenth the typical hardware horsepower which most software require today. This is not theory or just wishful thinking. If my company is already building such GUI libraries, well suited to the “Internet of Things”, which is only about 1 megabyte in size (can fit on a floppy if you remember what that was), surely other companies can do the same. But such tiny GUI libraries require compilers with the raw power of C (not C++, but C), but programming languages like Powerbasic demonstrate that it can also be done using BASIC, rather than C.
Just imagine something like this, when Microsofts new Shark Cove device becomes available. Imagine if one could start up something similar to classic Visual Basic, right on the Shark Cove itself ? No special iCore powerhouse computer needed, like you need for Visual Studio. Nothing would spur on development for the Shark Cove better than it coming with a classic Visual Basic like programming language already installed on it. Yes, develop software for the device right on the device. That means no dot.net required. That means fast performance which can only come from the low level WIN32 API. PowerBasic programmers already should be capable of this, if the device is running a full blown version of Windows (no dot.net needed), but imagine if one had the ease of use of classic Visual Basic as well. Now that would make the Shark Cove a lot more valuable as a prototyping device than even the Raspberry PI, in my opinion. Actually, if such a compiler was built correctly it might even be capable of running on even less hardware than what the Shark Cove has. Again this is not simply an impossible dream. My current development system only takes about 20 megabytes of disk space, which includes a fast native code compiler, an inhouse drag and drop designer (not up to Visual Basics level though) and code generator and a complete GUI engine running without about 1 megabyte in size. Still don’t believe this is possible ? Why not download this simple application I wrote for testing backward WIN32 compatibility of Windows 8 with previous versions of Windows:
The application executable (EXE) is only 166 KB in size and the GUI framework libraries are only about 1 megabyte total in size. The framework only uses the WIN32 API and no Dot.Net, no MFC, no C libraries. It also uses the standard OpenGL libraries ones video driver installs for its OpenGL 3D support. So basically it only uses core operating system libraries. It uses many WIN32 features such as the GDI, Ownerdraw, CustomDraw, Standard and Common Controls, Common Dialogs, Timers, MCI plus it also uses three unique high level engines for 2D Sprite animation, 3D OpenGL animation and Visual Design drag and drop (what visual designers like Visual Basic require for a drag and drop form designer). All the code (proprietary, so sorry no source code here) was written in BASIC (not C or C++).