Why do some programmers, even today, still desire to see classic Visual Basic brought back ?
I can’t answer the question for others, but I can offer a perspective which I feel is often overlooked. The move from Visual Basic to VB.NET was so drastic for some that they just could not, or would not, make the transition. A number who moved to VB.NET quickly switched to C# and left Basic in the dust. So what was really going on here ? Was Visual Basic so poorly designed it just had to be left behind? Was the managed language approach so superior that Visual Basic was just obsolete?
One programmers perspective of Visual Basic.
I liked Visual Basic for a number of reasons, but the key reason was the ability to prototype an application very fast. The interaction of the development environment made building GUI’s extremely fast. The second reason was that it was BASIC. I had been programming in some form of Basic for years, before Visual Basic came along. I had some exposure to languages like Fortran, Lisp, dabbled with C, but none of them had the appeal of Basic. Coding was easy in basic and as one compiler developer commented, that Basic is a natural language. It is not cryptic, like C. So combining a natural language, which had a long history, with an easy to use drag and drop development environment (RAD), it was no surprise that Visual Basic was a big hit. The strange thing about Visual Basic though, was that it was a hit with a unique sector of software developers. Independent programmers, hobby programmers and the like just took to Visual Basic, like a duck in water. People who you never thought of as being programmer material, started picking up Visual Basic in their spare time so they could build their own software for use at home as well as at work. They started creating applications for a specific need which they knew very well. Maybe they needed some software which just didn’t exist, so they created it themselves. Small businesses began to flurish from the flood of Visual Basic developers who literally were coming out of the woodworks, as they say.
The interesting thing about Visual Basic programmers though, was that even though they preferred Basic because it was an easy language to learn, they still had high expectations for themselves. If Visual Basic couldn’t do something, they often searched for ways to push the language beyond was it was designed for. So began the crop of books about how to integrate pure WIN32 API calls into Visual Basic. They were starting to tap into the deeper things of Windows.
So what happened ?
I can’t speak for Microsoft and their reasons for leaving Visual Basic behind. Likely they had good reasons in their own mind, but I believe they failed to appreciate what Visual Basic had become. I have the impression they did not expect Visual Basic to become so popular and didn’t know what to do with it. For example, initially Visual Basic only generated Pcode based applications so they were slow compared to their C++ counterparts. Visual Basic programmers wanted more though. My first version of Visual Basic which had a real compiler backend which generated decent machine code was VB 5.0 Professional. The interesting thing about this though, was that I have the impression that Microsoft didn’t plan this result initially. VB programmers were excited to have the ability to produce applications which were as fast as their C counterparts, but few may realize that to be able to get such a compiler required a little trick, which I one day read about. Now please correct me, if I am wrong about this, but I had read that Visual Basic used a C compiler backend. It was not actually a pure Basic to machine code compiler. Whether this is true or not, the point is that Visual Basic, one way or another had to become a true compiler. VB programmers wanted speed, performance. It wasn’t enough that they had one of the easiest to use GUI based programming languages, but they wanted the same performance as C programmers had and they got it, or at least pretty close.
So Visual Basic versions 5.0 and 6.0 were reaching a truly professional level, so why wasn’t there a Visual Basic 7.0 ? I can’t answer this question, but I did walk away with a very deep impression. This I say from years of hindsight. The problem was not with Visual Basic. The problem was with just BASIC ! You see, C and then later C++ was what was considered the true professional programming languages. Windows as build upon C and C++. BASIC was never intended to become the professional language it became. The shear growth of Basic and then Visual Basic, I do not believe was expected. It was that language to satisfy the hobby programmers and the kids. It was not intended to become a professional language. But with QuickBasic, then PDS 7.1 and then in the Windows world Visual Basic, it took on a new life. All sorts of people were writing commercial grade software and it worked great. RAD tools with Basic at their core, were able to produce software at an amazing rate.
So again, what happened ? Visual Basic was brought to its end (of life cycle as they might say). Now the programming world embraced managed languages like VB.NET and C#. But something more was happenning here. The transition from Visual Basic to VB.NET also was weeding out two sets of programmers with a divergent style of programming. Why did some VB programmers make the transition, while others did not ? Were they simply just bad programmers, not willing to learn something new ? I don’t think so, and while this is my opinion I do feel there is a good reason to consider this other possibility. There is a clue in one of the reasons many managed language programmers say is why Visual Basic was a poor language. I have often read comments by programmers mentioning how Visual Basic was not truly object oriented. Key OOP features were missing in VB, so it needed to be left behind (or they say). I would like to offer a different perspective on this.
OOP versus Procedural based programming.
It was about this time (the shift to managed languages) that OOP (Object Oriented Programming) began to push procedural styles of programming into the background. This can be seen not only with Visual Basic compared to VB.NET, but also in the shift from C to C++ and then later to C#. I never realized how much managed languages effected the software industry until I watched the video of a talk by Herb Sutter (a Microsoft C++ expert) entitled:
"Why C++?"
http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C
He touches on how managed languages took over for awhile and even left C and C+ behind only to find in the long run one of the vital aspects of software was being lost and that was performance. Now I would like to go a step further. The transition to managed languages was much more than this. It was also the transition from procedural coding styles to OOP, trying to leave procedural behind too. This can be seen with Visual Basic. Those who made the transition to VB.NET likely also preferred OOP over procedural style coding. Those who did not, possibly had nothing to do with being poor programmers, but instead maybe they just simply preferred a more procedural style of coding. Visual Basic was quite unique. Where OOP succeeded the most, was in designing the interface (GUI). But the rest of the coding could be done using purely procedural style coding, much like we used in the DOS days. It was beautiful blend of the two.
So the desire of many to see a true Visual Basic programming language brought back is very understandable. But the real question before that could be possible is whether a more procedural style of programming has an advantages over using pure OOP ? Also, can the BASIC language maintain its syntax and still be used as a professional language, yet grow and advanced in a way more natural to Basic ? The answer to both questions is an absolute yes !
One step back and two steps forward.
The last Microsoft programmign language I used in my business was Visual Basic 5.0 Professional. For me, my experience was quite strange in that I had to take one step back first and then take two steps forward. I switched to PowerBasic which in those days had not GUI features at all. I still was a Basic programmer, still wrote code in a purely procedural style, but I had to write applications in the same way as the old time C (not C++) programmers had to using the pure Windows Win32 APIs. Whereas Visual Basic programmers were extending Visual Basic by learning how to tap into the Windows API, I was writing software using the Windows API alone. From everything I read, one of the reasons C programmers began to leave behind using the pure WIN32 APIs was it was suppose to be too difficult to write any application. So along came things like MFC (Microsoft Foundation Classes) and ATL. As a Basic programmer though I had to dig into all that old C code to see how they wrote applications and they translate it into Basic. An interesting thing happenned though. The Basic version was more readable than the C version. Also the C code was purely procedural in nature, so it was a perfect fit for translating into Basic. MFC code often would confuse me more than the pure C code. The point is that by being forced to learn how to code Windows software using what most would have considered old fashion techniques, I realized the advantage of Basic and procedural style coding, plus why Visual Basic programmers often pushed it to the limit by tapping into the Windows API, which is where the real power was.
Now imagine the power of say a Visual Basic 7, with its ease of development, combined with tools to extend it (other Basic language compilers) which simply allowed long time Visual Basic (and any Basic) programmers to be able to once again push the limits of Windows software development ? The huge existing codebase of VB code could be put to work.
Two steps forward.
Because I learned how to write Basic code using the pure Windows API, I realized something. Visual Basic never fully tapped into what is possible with Windows. The power that exists in Windows would boggle your mind if you really knew what is there. The Windows DIB engine is amazingly powerful and it has been there since Windows 95. Threading in Windows would have been easy to impliment in Visual Basic if they only followed a simple rule, which I learned from an excellent book about Windows multitasking and threading. Threads are not needed for foreground GUI tasks. Threads are better suited to background tasks (non-GUI or preparing stuff for the GUI, but not drawing it). I learned how to tap into using threads, even with a purely procedural style of coding. Visual Basic programmers often found themselves being forced to use third party (some even from Microsoft) OCX controls just to add features which should have been built into Visual Basic natively or could have been accomplished with a few lines of API code. Visual Basic should have exposed more of the underlying features of Windows and natively if possible. Things like subclassing and superclassing should have been introduced into the language. Things like ownerdraw and customdraw should have been introduced into the language. Visual Basic if done right, could have become one of the most powerful programming languages around, capable of producing small, fast and transportable (no installation required, just copy and run) applications.
Procedural style coding, as used in Visual Basic, has many advantages. One thing it can produce smaller, faster applications with a tiny footprint. Basic is a more natural language which allows you to use huge stocks of existing code and more easily maintain it (because it is more readable).
The key to future versions of BASIC is to first view them as a professional language. Second don’t force OOP on users. OOP has its place as an addition to the language, but one should be able to write an application with purely procedural style coding it they prefer. Third, maintain the language at its core, don’t try to make it like C or C#, but respect the long history of the language and its core syntax. Just maybe then, bringing back classic Visual Basic, would not be a step backward, but two steps forward.
