Click here to Skip to main content
13,191,570 members (65,791 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


6 bookmarked
Posted 3 Apr 2013

Classic Visual Basic’s end marked a key change in software development

, 3 Apr 2013
Rate this:
Please Sign up or sign in to vote.
The key to future versions of BASIC is to first view them as a professional language.

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++?"

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.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Chris Boss
Software Developer Computer Workshop
United States United States
Chris Boss is the owner (and programmer) of a small software development business in rural Virginia, called the Computer Workshop. For the last ten years or so he has been developing tools for use by Powerbasic programmers (see: ). His main product called EZGUI (Easy GUI) is a high level GUI engine with Visual Designer and code generator. It is in its fifth generation now. He is an experienced Windows API programmer (more low level) and has experience in writing GUI engines (forms/controls), drag and drop Visual Designers, Graphics engines (printing and to the screen) and one of his favorites is a Sprite engine (2D animated movable images). His current project is version 5.0 of his main product EZGUI, adding such features as multi-monitor support, component engine, custom control engine, superclass engine and the latest project a 3D OpenGL based custom control. One of the goals he has is to push the limits of Windows software development, while making it easy, fast execution speed, small footprint (size of executables) and code reusability while providing a more graphic experience in user interfaces, while still being able to write software which can fit on a floppy disk (small footprint), use minimal amount of memory and able to run on multiple versions of Windows from 95 to Win8.

You may also be interested in...


Comments and Discussions

QuestionFund a replacement for vb6! Pin
axisdj26-Apr-15 6:59
memberaxisdj26-Apr-15 6:59 
QuestionVB6 programming still most popular Pin
VB6 Programming13-Aug-14 5:08
memberVB6 Programming13-Aug-14 5:08 
QuestionVB6 is the best ! Pin
Adam one9-Feb-14 16:50
memberAdam one9-Feb-14 16:50 
QuestionVB 6.0 YES. Maybe VB 6.1 Pin
CapricornVB11-Nov-13 5:23
memberCapricornVB11-Nov-13 5:23 
QuestionBring back VB6 Pin
Member 103442235-Nov-13 11:32
memberMember 103442235-Nov-13 11:32 
QuestionBring back classic VB Pin
sten200527-Jul-13 22:21
membersten200527-Jul-13 22:21 
AnswerRe: Bring back classic VB Pin
Member 103442235-Nov-13 11:27
memberMember 103442235-Nov-13 11:27 
GeneralRe: Bring back classic VB Pin
VB6 Programming13-Aug-14 5:01
memberVB6 Programming13-Aug-14 5:01 
GeneralMy vote of 5 Pin
Mihai MOGA10-May-13 18:31
memberMihai MOGA10-May-13 18:31 
QuestionHow to convert... Pin
i009-May-13 20:47
member i009-May-13 20:47 
GeneralMy vote of 5 Pin
i009-May-13 20:39
member i009-May-13 20:39 
GeneralMy development tools Pin
Chris Boss10-May-13 3:19
memberChris Boss10-May-13 3:19 
QuestionHow the VB "C compiler" works Pin
NotRalph8-Apr-13 18:35
memberNotRalph8-Apr-13 18:35 
This might help fill in some of the gaps in how the VBIDE compiles to native code.
[Disclaimer: This is essentially a 5,000 foot summary view. A lot of detail is glossed over. Also many of the terms are 'made-up' by me, and probably do not reflect the exact 'names' used by the VB developers. Most of this is undocumented, so I don't know what they officially called the pieces. <g>]

The VBIDE is made-up of four distinct but tightly integrated parts - an editor, a parser, the VB Runtime, and the Forms Engine.

1) The VBIDE does not use Visual Basic Language/script (that which you see in a text editor or the VBIDE) directly. When the VBIDE loads a text file the parser immediately converts that script to VB pcode. (There is actually 'opcode' and 'excode' states but will be ignored for now.)

2) What you see in the editor is actually an artifact - one can think of it as being almost the same as comments - interspaced with opcode. Something like this ...
Dim a As String
; hidden pcode for the declaration and definition

3) There are tons of "hidden" code behind the script you see. The only to note here is it is the pcode which is run and is active. Outside of the interactive process ('editing') between the editor and parser the script is never 'used' again.

4) VB pcode is stack-based and interpreted so not only do you have lines or statements, VB also creates tables, stacks, caches, etc. It is this that VB "runs". Look up stack-base languages or Forth for a better idea.

5) Each module is its own translation unit. These modules are converted to 'object' code (opcode).

6) When a VB application is compiled to "pcode", it is this opcode ('hidden') which gets converted to 'excode' and packaged into one 'executable' to be run.

7) When the option to compile to 'native code' is selected. The opcode modules are converted to preprocessed C code which is then compiled identically to C code through the Microsoft C2 compiler.

QuestionCompiler clarification Pin
John Browne4-Apr-13 11:14
memberJohn Browne4-Apr-13 11:14 
AnswerRe: Compiler clarification Pin
Chris Boss4-Apr-13 16:16
memberChris Boss4-Apr-13 16:16 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.171017.1 | Last Updated 3 Apr 2013
Article Copyright 2013 by Chris Boss
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid