Journal Franciscan's Journal: Real Programmers don't Use Visual Basic.
I think I'll write a book with the title "Real Programmers don't Use Visual Basic". Whenever I see a resume where the applicant says "I'm an MCSE and I have ten years experience writing Enterprise Class applications with Visual Basic" on his or her resume, or whenever I see a job advertisment where they say "X years of experience writing mission critical enterprise apps using Visual Basic", I know that the person, or company in question, has no credibility, questionable technical skills, and generally exhibits lemming-like behaviour that is common in the IT sector.
What do I mean by that? I mean only that Visual Basic is a path of least resistance, for both management and trainees. It gets in the door by claiming ease of use, or rapid development cycles (compared to Visual C++, this is true, but I'll save my Anti-Visual-C++/MFC/ATL/.NET-rant for another day), gets away with claiming to be Object Oriented, or even claims to be compiled, something which has never been strictly true of VB, and which is still not entirely true of VB.Net.
In essence, VB is the ongoing development of one of Microsoft's first products. Their basic interpreters were first delivered as ROM code for popular 8 bit home computers of the 1980s, like the Atari 400/800, the Commodore Pet, the VIC-20 and, my own first computer, the Commodore 64.
These languages contained in a mere 8 or 16K of ROM, a Basic with mandatory line numbers, simple Integer (16 bit) and single-precision Floating Point arithmetic, simple string handling, were built in. For/Next loops were the only loops. Goto and gosub were the *only* looping constructs. Instead of calling a utility function, you would GOSUB to a line number. Procedures? What are those? Functions? Yes, you could write functions, but only if they would fit into one line, and were only composed of simple mathematical operators. This was the Old Days, before Structured Programming was common on microcomputers. There were no Editor programs, and source code didn't come from a file, it was all resident in memory at once. You typed a line of code, with a line number, and you hit enter, and that line was added (or replaced) in-situ, in RAM. This was optimal if you had only a tape drive (no floppy disk), and workable if you had only a floppy-drive. Almost nobody ever had a hard drive on one of these machines. You could type LIST to see what was in memory, SAVE to save the program to disk, or LOAD to reload a previous program. RUN made the whole thing run, and if you wanted to debug, you would hit the BREAK key, or put a line of code into your program with the STOP keyword, so you could stop the program, print out some variables, and type CONT to continue it. Programs in multiple source code files (includes, libraries, etc) were not possible. Subroutines were not yet heard of in BASIC.
Fast forward to the late 1980s and the rise of the PC and MS-DOS. Included with MS-DOS was GW-Basic, Microsoft's improved version of BASIC for the IBM PC. This basic version became ubiquitous because it shipped with DOS. Like the 8-bit micro versions, this 16 bit DOS application had nothing like an "IDE". It added primitive capabilities to define functions (subroutines), and even had some DOS graphics primitives. Compared to the ROM basic that came with my Commodore 64, this was a very deluxe Basic language. It was still a primitive piece of crap by modern standards. You still only had two significant letters to name your variables (THIS and THAT would be the same effective variable name, TH). Most programs written in GWBASIC were strictly of the homebrew/hobby variety.
Microsoft made another incremental improvement to GWBASIC, called QuickBasic (QBASIC.EXE). QuickBasic was a stripped down version of their Basic Compiler, originally a standalone package, which never achieved widespread use, until the stripped down QUickBasic was shipped along with DOS. Once it was shipped with DOS, QuickBasic quickly relegated GWBASIC to the scrap heap. It had a simple text editor, the beginnings of an IDE, the ability to set breakpoints visually and to visually step through code. Quite a few DOS games and other kinds of DOS programs were written in Quick Basic. The language had added another set of quirky constructs, some semi-obsolete, like the LET keyword, which still existed for example, but was essentially useless. LET X=Y and X=Y did exactly the same thing.
Your other choice at the time was Microsoft's C Compiler Version 6. This was also the only way to write a Windows apps when Windows 3.0 shipped. And while straight C programming for DOS wasn't that difficult, if you got the classic K&R book and worked your way through it, the change from BASIC to C required a lot of trial and error, and the absorbing of several books worth of information in order to proceed. As someone who sidestepped QuickBasic in favour of TurboPascal, and later learned C syntax as an exercise in comparison to Pascal, I remember feeling very sorry for people who limited themselves to the choice between Microsoft C, and Microsoft QuickBasic as their programming tools. Working in TurboPascal was as fast as working in QuickBasic, and the language was far more full-featured and powerful than Microsoft's C tools were at the time, and were also capable of all the same low level hacks as C programmers were used to, such as the ability to hook interrupts, write DOS pop-ups, known as TSRs, and to handle complex data structures, using a rich, expressive, structured programming language. In short, Borland kicked Microsoft's @$$ all around the block, but still some people insisted on using the two lame tools that came from Redmond. I began to suspect in 1989, that many people chose their tools because of the the name on the box, not what actually came inside the box. Borland had object oriented programming, very nice Modula-2 style interface/implementation separation, and other things that were lightyears ahead of C, and did I mention, it compiled 20 times faster than C did and produced smaller executables?
Now when it came to learning Windows programming there was no avoiding the pain. Programming on Windows was an order of magnitude more complex than DOS programming. A 'Hello World' program went from one line to about 100 lines. It was event-oriented, with message handlers, and a bizarre API, especially for a former DOS programmer, that could only have been invented by Microsoft, and could only be understood if your name was Petzold, or if you had bought a book by someone with that name, and spent many months tearing your hair out trying to learn all the options for WinCreateWindow. The complexity of writing imperative code to control an event driven architecture was what prompted the creation of Visual Basic 1.0, which was nothing more than a GUI forms builder with the ability to draw a form, with a button control, click the button, and an editor window would open, and you would only have to writen a a few lines of code that would be executed when that button was clicked. Then you would click Run, and you had a windows application. The nice touch was the VBX control, a way of plugging in controls, like spreadsheets (grids) and charts, that were more exotic and more visually varied than the simple ones that were built into windows (buttons, checkboxes, etcetera). VBX controls could be written by a moderately clever C programmer, and then reused in an almost no-brainer fashion by the growing horde of people who fell in love with VB, so to speak, because of the ease of use. As they grew more experienced, they began to hit one limitation after another in VB's architecture. Microsoft gradually expanded the walls outward with each version, usually by adding some new ugly item to the syntax. The worst example is the SET/LET duality.
Fast forward to today, and you have Visual Basic 6.0 being used in enterprises around the world, mostly because someone in 1989 didn't want to shelve their knowledge of GOSUB and LET statements, they didn't want to learn to use braces or begin/end statements, or where to put semicolons. Because of what started as an effort to stay with the weak, and broken, albeit simple syntax of Basic, we have n-Tier enterprise applications being written with Visual basic. Was it done because it was the best thing possible at the time? No, it was done because it was the path of least resistance.
What can we learn from this? We can learn that basically, most of the time, people do what comes easiest, what we felt we had time to do, and we paid the price for it. If a wiser developer emerges at the end, one who realizes that a bad choice of language can doom a project, or at least curtail it's useful life, then perhaps we can say we have learned a lesson.
next time, a brief rant about .NET.
What do I mean by that? I mean only that Visual Basic is a path of least resistance, for both management and trainees. It gets in the door by claiming ease of use, or rapid development cycles (compared to Visual C++, this is true, but I'll save my Anti-Visual-C++/MFC/ATL/.NET-rant for another day), gets away with claiming to be Object Oriented, or even claims to be compiled, something which has never been strictly true of VB, and which is still not entirely true of VB.Net.
In essence, VB is the ongoing development of one of Microsoft's first products. Their basic interpreters were first delivered as ROM code for popular 8 bit home computers of the 1980s, like the Atari 400/800, the Commodore Pet, the VIC-20 and, my own first computer, the Commodore 64.
These languages contained in a mere 8 or 16K of ROM, a Basic with mandatory line numbers, simple Integer (16 bit) and single-precision Floating Point arithmetic, simple string handling, were built in. For/Next loops were the only loops. Goto and gosub were the *only* looping constructs. Instead of calling a utility function, you would GOSUB to a line number. Procedures? What are those? Functions? Yes, you could write functions, but only if they would fit into one line, and were only composed of simple mathematical operators. This was the Old Days, before Structured Programming was common on microcomputers. There were no Editor programs, and source code didn't come from a file, it was all resident in memory at once. You typed a line of code, with a line number, and you hit enter, and that line was added (or replaced) in-situ, in RAM. This was optimal if you had only a tape drive (no floppy disk), and workable if you had only a floppy-drive. Almost nobody ever had a hard drive on one of these machines. You could type LIST to see what was in memory, SAVE to save the program to disk, or LOAD to reload a previous program. RUN made the whole thing run, and if you wanted to debug, you would hit the BREAK key, or put a line of code into your program with the STOP keyword, so you could stop the program, print out some variables, and type CONT to continue it. Programs in multiple source code files (includes, libraries, etc) were not possible. Subroutines were not yet heard of in BASIC.
Fast forward to the late 1980s and the rise of the PC and MS-DOS. Included with MS-DOS was GW-Basic, Microsoft's improved version of BASIC for the IBM PC. This basic version became ubiquitous because it shipped with DOS. Like the 8-bit micro versions, this 16 bit DOS application had nothing like an "IDE". It added primitive capabilities to define functions (subroutines), and even had some DOS graphics primitives. Compared to the ROM basic that came with my Commodore 64, this was a very deluxe Basic language. It was still a primitive piece of crap by modern standards. You still only had two significant letters to name your variables (THIS and THAT would be the same effective variable name, TH). Most programs written in GWBASIC were strictly of the homebrew/hobby variety.
Microsoft made another incremental improvement to GWBASIC, called QuickBasic (QBASIC.EXE). QuickBasic was a stripped down version of their Basic Compiler, originally a standalone package, which never achieved widespread use, until the stripped down QUickBasic was shipped along with DOS. Once it was shipped with DOS, QuickBasic quickly relegated GWBASIC to the scrap heap. It had a simple text editor, the beginnings of an IDE, the ability to set breakpoints visually and to visually step through code. Quite a few DOS games and other kinds of DOS programs were written in Quick Basic. The language had added another set of quirky constructs, some semi-obsolete, like the LET keyword, which still existed for example, but was essentially useless. LET X=Y and X=Y did exactly the same thing.
Your other choice at the time was Microsoft's C Compiler Version 6. This was also the only way to write a Windows apps when Windows 3.0 shipped. And while straight C programming for DOS wasn't that difficult, if you got the classic K&R book and worked your way through it, the change from BASIC to C required a lot of trial and error, and the absorbing of several books worth of information in order to proceed. As someone who sidestepped QuickBasic in favour of TurboPascal, and later learned C syntax as an exercise in comparison to Pascal, I remember feeling very sorry for people who limited themselves to the choice between Microsoft C, and Microsoft QuickBasic as their programming tools. Working in TurboPascal was as fast as working in QuickBasic, and the language was far more full-featured and powerful than Microsoft's C tools were at the time, and were also capable of all the same low level hacks as C programmers were used to, such as the ability to hook interrupts, write DOS pop-ups, known as TSRs, and to handle complex data structures, using a rich, expressive, structured programming language. In short, Borland kicked Microsoft's @$$ all around the block, but still some people insisted on using the two lame tools that came from Redmond. I began to suspect in 1989, that many people chose their tools because of the the name on the box, not what actually came inside the box. Borland had object oriented programming, very nice Modula-2 style interface/implementation separation, and other things that were lightyears ahead of C, and did I mention, it compiled 20 times faster than C did and produced smaller executables?
Now when it came to learning Windows programming there was no avoiding the pain. Programming on Windows was an order of magnitude more complex than DOS programming. A 'Hello World' program went from one line to about 100 lines. It was event-oriented, with message handlers, and a bizarre API, especially for a former DOS programmer, that could only have been invented by Microsoft, and could only be understood if your name was Petzold, or if you had bought a book by someone with that name, and spent many months tearing your hair out trying to learn all the options for WinCreateWindow. The complexity of writing imperative code to control an event driven architecture was what prompted the creation of Visual Basic 1.0, which was nothing more than a GUI forms builder with the ability to draw a form, with a button control, click the button, and an editor window would open, and you would only have to writen a a few lines of code that would be executed when that button was clicked. Then you would click Run, and you had a windows application. The nice touch was the VBX control, a way of plugging in controls, like spreadsheets (grids) and charts, that were more exotic and more visually varied than the simple ones that were built into windows (buttons, checkboxes, etcetera). VBX controls could be written by a moderately clever C programmer, and then reused in an almost no-brainer fashion by the growing horde of people who fell in love with VB, so to speak, because of the ease of use. As they grew more experienced, they began to hit one limitation after another in VB's architecture. Microsoft gradually expanded the walls outward with each version, usually by adding some new ugly item to the syntax. The worst example is the SET/LET duality.
Fast forward to today, and you have Visual Basic 6.0 being used in enterprises around the world, mostly because someone in 1989 didn't want to shelve their knowledge of GOSUB and LET statements, they didn't want to learn to use braces or begin/end statements, or where to put semicolons. Because of what started as an effort to stay with the weak, and broken, albeit simple syntax of Basic, we have n-Tier enterprise applications being written with Visual basic. Was it done because it was the best thing possible at the time? No, it was done because it was the path of least resistance.
What can we learn from this? We can learn that basically, most of the time, people do what comes easiest, what we felt we had time to do, and we paid the price for it. If a wiser developer emerges at the end, one who realizes that a bad choice of language can doom a project, or at least curtail it's useful life, then perhaps we can say we have learned a lesson.
next time, a brief rant about
