Why classic Visual Basic needs to be rebuilt from scratch and brought back for a new generation
“We need more coders”, “Everybody needs to learn to code”, “Coding should be a basic requirement in education”, ….
Have you heard or read comments similar to these ?
What does this have to do with classic Visual Basic ?
BASIC and the hobby programmer
Why won’t BASIC just die and go away ? Probably most programmers today think this, but there is a reality about BASIC which is often forgotten. BASIC is the programming language of the hobby programmer. But does that matter ? Yes, it does and classic Visual BASIC demonstrates this very well.
Long before Visual Basic, though , was simply BASIC. While early BASIC’s were interpreted, very quickly BASIC compilers came along as well. When computers were slow in the old days, interpreted BASIC solved the problem of waiting for long compile times of a compiler. You got immediate results when you coded which worked well for hobby programmers. A hobby programmer needed immediate results or there would be a loss of interest. BASIC became the de facto standard for ROM based languages in home computers of the 1980’s. Even on main frame computers, BASIC became a de facto standard for time shared interpreted programming languages. While a computer science student might wait hours before a Fortran program coded on punch cards to come back with results, he (or she) might pass the time coding in BASIC on a time shared terminal and got immediate results. BASIC was easy to learn and got immediate results, the perfect programming language for a programmer in learning. It’s more natural or human syntax made it easier to read and to code.
What many did not realize though, was that some very good programmers (and software created by them) came from this sector of programming. Why ? Some of the best tools created are often done out of necessity. For example, if a programmer with only a programming background decides to build an application for accounting, consider, what does he know about accounting ? Will he be using the resulting software himself once it is done ? Likely not. But consider what happens if a person who is an accountant decides to write an accounting application, which he (or she) will use daily. If the accountant has enough coding skill to accomplish this, then the end result might be significantly better. Why ? Because he understands what is really needed for accounting and isn’t dazzled simply by the technology, but looks for ways to put the technology to practical use.
Classic Visual Basic creates new software companies
In the Windows world, classic Visual Basic created a whole new sector of software developers. Not college trained programmers, but hobby programmers who eventually became commercial developers. Classic Visual Basic, following in the footsteps of DOS BASIC’s, provided an easy to use programming language which the average person could use, but with a result likely not expected by Microsoft. In hindsight, as a long time programmer, I really doubt Microsoft created Visual Basic as a replacement for so called professional programming languages like C. Windows itself was not written in BASIC, but most likely C (and possibly assembler and today also C++). Yet despite its hobby roots, classic Visual Basic became one of the most popular programming languages of its time. Why ?
With an easy to use RAD based front end and BASIC for its core language, classic Visual Basic became the language for the masses, the common person. Now an accountant, a carpenter, an auto mechanic, the average person, could learn to program and write their own software. But they did more. Average, everyday persons, were trying their hand at writing very real and practical software for their own trades, which they knew well, better than programmers did. The better hobby programmers now gravitated to becoming professional programmers, starting their own businesses writing and selling software for the trades they knew. Such software, while possibly viewed as insignificant at first by the so called professional programmers, soon became industry standards in their respective industries or trades. Why ? Because often professional software developers never even considered writing software for those markets at all. Even if they did, some of those hobby programmers knew their own trade so much better than their so called professional programming counterparts, they created unique solutions which resulted in some amazingly useful and practical software. Not because they were better programmers (at first anyway), but because they knew their trades better and had enough programming skills to solve a problem or fill a need.
Hobby programmers can become highly skilled programmers
Again, what companies like Microsoft may not have realized is that hobby programmers can eventually become very skilled programmers and they often will find ways to do more with the tools they have than even the developer of that tool envisioned. Classic Visual Basic is a perfect example of this. Soon many a hobby Visual Basic programmer began to see the limitations of Visual Basic and this created markets for books like Dan Appleman’s “Visual Basic Programmer’s Guide to the Win32 API”. Yes, these hobby programmers were searching for ways to push the limits of classic Visual Basic. The interesting thing though was what they turned too. The WIN32 API ! Yes, hobby programmers were now looking “under the hood” of Visual Basic to see what made it tick and how it really worked. In time they clamored for more raw power and features. Microsoft finally had to add a real compiler to Visual Basic (from what I have read it appears Microsoft had to fudge it a bit by using a C compiler backend to accomplish this). Experience teaches us that coding can really be mastered by the average person when the right programming language is available. Classic Visual Basic demonstrated this.
Something missing in classic Visual Basic
In my opinion, there was something missing in classic Visual Basic’s design, but not what most may think. Let me back up a bit here before I go on. What I discuss next is based on a long time experience as a BASIC only programmer. Unless you have been a longtime BASIC programmer you may not appreciate my sentiments. Let me start first with some information about the history of BASIC. BASIC has a bad reputation today by mainstream programmers and you often hear comments about it being obsolete, “just an interpreter” and “how bad and dangerous it is because of GOTO”. The reality is that BASIC has a rich history as a programming language and when designed correctly it can be just as powerful as C, yes C. Back in the day (1980’s), BASIC quickly took on the core features of a high quality programming language. For example, even in the day of the Commodore 64 home computer, companies were making powerful BASIC compilers, such as the Abacus BASIC compiler. Yes, us old timers who learned how to code in the 1980’s were using real compilers for BASIC, not just a simple interpreter. The famous QBasic (interpreter) eventually became Quick Basic (a compiler). Quick Basic (by Microsoft) eventually became PDS 7.1 (Microsoft Professional Basic or Professional Development System). One could even build modules for PDS 7.1 in assembler to push the language further. Borland International, famous for its professional programming languages, came out with Turbo Basic, yet another high quality BASIC compiler. BASIC was becoming a de facto standard in professional programming. BASIC also took on many of the features of other languages (ie. Pascal) and continued to improve.
BASIC took a big hit when Windows came along. Most Windows programming was done in C using the WIN32 API and BASIC had a difficult transition to Windows. Windows required a RAD (Rapid Application Development) front end for writing software for it to be efficient. A number of companies attempted to create the perfect BASIC for Windows and programming languages like Computer Associates CA Realizer and GFA Basic are examples of this. I purchased both of these languages and I found them to be wanting. For a long time DOS BASIC programmer, they were confusing to me. In hindsight, they found moving to an event based coding style a difficult challenge. Windows was not sequential in nature like DOS programming was. Under the hood the WIN32 was message based and the new generation BASIC’s found it a challenge to follow this model. At least it was confusing to many a long time BASIC programmer. Also some BASIC’s attempted to solve the change by switching to an Object Oriented model which add more complexity to BASIC. It is interesting to note that the WIN32 is a flat procedural API mostly, not OOP based.
This difficult transition to Windows almost killed BASIC. It hurt many a company who had used BASIC to write commercial DOS software, because there were no good languages to move to for Windows. Some companies who depended upon BASIC eventually struggled because their customers were clamouring for a Windows version of their software.
Then along came Visual Basic. For me is was the easiest and best BASIC for making the transition to Windows. While it was true much of the DOS BASIC codebase for User Interfaces could not be ported to Windows directly, much of the backend code could be, since Visual Basic supported a version of Basic at least similar to DOS Basic. Visual Basic’s event model was new, but not too difficult to learn because of the RAD front end. Once again coding in BASIC was possible and Visual Basic likely saved many a company who depended upon Basic for development of their software.
But there was a limitation caused by the design of this new amazing programming language which few likely would appreciate, even myself at first. Only because I stuck with BASIC, even when classic Visual Basic was finished (deprecated by Visual Basic dot.net) would I realize this and I don’t mean just sticking with classic Visual Basic. I moved on beyond classic Visual Basic and switched to PowerBasic, but even that language would provide challenges, but it did reveal one key thing missing in BASIC for Windows. This would help reveal what was missing in classic Visual Basic.
The journey with BASIC continues
For me, the journey with BASIC continued, but I ended up following a road I never expected. In the end it would become obvious where classic Visual Basic was truly limited (in its approach or overall design). Visual Basic had limitations and it was becoming obvious that serious software was more and more being written in C rather than BASIC. C had all the performance and raw power. Visual Basic had the ease of use. But as more Visual Basic programmers clamoured for more raw power, first solving problems with WIN32 API calls, some began to look for alternatives. For me, I switched to PowerBasic. PowerBasic is the great grand child of Borlands famous Turbo Basic. The problem though was that at the time (Powerbasic version 1.0 for 16 bit and 5.0 for 32 bit), the language had no GUI engine, no RAD front end and one had to learn the raw WIN32 API and code like old time C programmers did to build an application. I took on the challenge to learn the WIN32 API and it was revealing. What I had lost in ease of use, I gained in the raw power of Windows. Now PowerBasic likely never became a household name for most programmers because it lacked a GUI front end and a GUI engine in its early years. It could not compare with classic Visual Basic in this area, so the programming language was for years marketed as an addon to Visual Basic for building fast DLL’s (Dynamic Link Libraries). The compiler was first named PBDLL (or PowerBasic DLL compiler). It could be used to create EXE applications, but few were experienced enough to use the WIN32 API to build a complete GUI application from scratch with it. I had to build my own GUI framework for the compiler and even my own GUI RAD front end Form Designer, but I did gain one important lesson from the experience. I learned about the raw power of the WIN32 API and the benefits of working with a real BASIC compiler. Albeit, classic Visual Basic eventually became a compiler, but not until its later versions (5.0 / 6.0). This one aspect tells an important story. Why wasn’t Visual Basic a compiler front day one ?
It was revealed when I learned a little more about the history of classic Visual Basic. I had always assumed Microsoft built it from scratch, but it actually was something built by another company and not originally intended to be a BASIC programming language. While it is applaudable that Microsoft saw the benefits of this tool and they had it transformed into Visual Basic, it is also its biggest limitation. RAD (Rapid Application Development) was the goal and its biggest strength, but because it was not intended to be a full blown BASIC compiler right from the start, its design or approach would also relegate it to a second class status in the programming world. “Real programs are written in C” was probably often heard by many Visual Basic programmers. Even addons for Visual Basic often had to be written in C rather than in BASIC. It would take five generations of the language before it got its own compiler and that is the important story. By not having a compiler in the language from the start, it would likely affect the design decisions of the language for many years. This is not a criticism of classic Visual Basic. It was an amazing piece of software in its time. Now while Visual Basic could be used to write compiled applications, it still could not be used to write industry standard DLL’s for other languages though.
For more about the history of where Visual Basic came from check the following links:
Alan Cooper, the “father of Visual Basic”
The need for a new visual style BASIC for Windows
There is a real need for a new visual style BASIC for Windows. Not a classic Visual Basic clone or redo, but a new visual style Basic built from scratch. I would venture to say, it is too late for a 100% Visual Basic redo, since most of those who use Visual Basic have moved on to Visual Basic dot.net. The market for this new visual style Basic would not be existing programmers still stuck on classic Visual Basic, but for the next generation of hobby programmers who may need to use BASIC to solve everyday problems in their specific trades. Such future programmers may even produce future businesses built on software they create. But the approach for a new visual style BASIC would have to be different. It would have to start from a basic premise, which is:
Lesson: RAD can never replace a true compiler
Having spent over 15 years in WIN32 development, as well a GUI development, one thing I have learned is that RAD can never replace the need for a true compiler. It only works to its full benefit when it is based on top of the compiler, not the first concern. WIN32 development is still viable today, especially with mobile devices and IOT (Internet of Things). But how does one create such a language as a visual style BASIC ? A new BASIC starts with a core compiler. The language needs to be able to be used to build itself. No C backend, but a true BASIC Windows compiler, compiling straight from BASIC to machine language (binary). Windows already has a core reusable module feature which is the DLL. The DLL is a powerful way for reusing code and creating libraries. Static libraries should also be possible. Unlike classic Visual Basic, a new BASIC should be able to generate static and dynamic libraries which could be used in other languages, like C. Rather than totally hide the WIN32, a new BASIC should embrace it. It should be able to write 100% WIN32 code (which some have referred to as the “Assembler of Windows”) or be able to write code without any WIN32 code using a high level GUI framework specifically written for it (written in the same language too). Since the WIN32 is more of a flat API, rather than OOP based, a new BASIC should target a more flat API style of coding, which produces smaller and faster executables. It should still support objects, but OOP at times can get in the way of ease of use rather then improve it, so it should be optional. Both styles of coding should be supported. Having spent so much time with the WIN32, OOP can get in the way because the WIN32 is more procedural in nature and if one mostly codes in OOP, so when WIN32 access is require it may seem very foreign to the programmer. Procedural style coding, with occasional OOP would serve the purpose of a new visual style BASIC better, in my opinion. The raw power of C (albeit in a BASIC syntax) should exist in such a compiler, with things like pointers to data or code, inline assembler, etc. Advanced features in Windows should be made easily accessable such as ownerdraw, customdraw, threads, etc. Especially important would be the need to support the core syntax of BASIC since the early days of Microsoft DOS Basics for logic, data types, etc. The idea is to allow as much as possible the reuse of legacy code, while still supporting newer code styles. There is a lot of non-GUI BASIC code around which can be reused. Microsoft PDS 7.1 set the standard for DOS BASIC’s and classic Visual Basic set the standard for Windows Basic. Both should be used as a basis for a modern syntax supporting as much legacy code as possible, as well as newer coding styles. Compiling should target both 32 bit and 64 bit and if possible even ARM as well as x86 CPU’s.
The point is that RAD should not overshadow the compiler. Start with the compiler first and then add RAD to support it. One should be able to code completely in a code editor alone, as well as from a RAD editor. A new visual style BASIC should have the raw power of C, but the ease of BASIC.