"Becoming a good Visual Basic 6 programmer took much less time than becoming a good C++ programmer."
I love this line because it implies that you can actually become a good VB6 programmer. Sure, you may not be able to sort a linked list, but you can still learn about encapsulation and ... actually, just start with encapsulation; that's going to make your code SO much easier to read :-)
You either mean that it implies that you can become a good programmer while writing VB6, or that you can become someone good at writing VB6 programs, or that you can become someone who writes VB6 programs that are good.
Regardless of which of those meanings were intended, I disagree. I find denying any of the three to be dismissive and just plain wrong. I should be clear: I hate VB6. I really do. But I'd stop far short of the arrogant suggestion that it's not possible to do good work in it, or that it's not possible to learn an enormous amount about what it takes to make great software while writing it.
Sorry if my comments were confusing. I intended no sarcasm nor arrogance.
I started off in VBA hacking recorded macros. I would then write hundreds of lines of code into a single function (usually named "DoSomething" or something equally vague) and then I would live and die by the VBA debugger, tweaking the function when it broke. Over time, I learned the value of encapsulation and how much easier it was to debug my code if used smaller, well-named, functions.
When I started a different job and ended up doing a lot of VB6 programming, I ended up reading a lot of others' code. I would stare at functions that were literally 1000+ lines of code an painfully difficult to debug. The purpose of the VB6 code was to print barcoded shipping labels in a specified format, but the ZPL print instructions were heavily mixed with business logic. It was a nasty mess. The single greatest thing that would have helped me would have been encapsulation. Even if the developer hadn't separated the business logic from the ZPL code (which would have been very nice), small, well-named functions would have made the program so much easier to follow.
The reason I mention encapsulation specifically is because of how much you gain as a developer. If you learn nothing more than basic encapsulation as a VBA/VB6 developer, you'll do wonders for the readability and maintainability of your code.
That's probably because a good VB6 programmer would still be a terrible C++ programmer. There are too many ideas VB programmers will never encounter. In order to be a good C++ programmer you'd be a VB god (rolling out your own DLLs and OCXs).
I have done more than my fair share of VB programming from version 2 when it was new up until 98 or so. I even got my MCP certification on VB3... It was the quickest tool to build a Windows application at the time.
In fact, at least here in Brazil, the rise of Windows as a corporate OS coincides with a rapid adoption of VB for in-company development and the fall of Clipper under DOS. I saw it first hand because it happened while I was helping write a huge console-based app in Dataflex. The app is still used by more than a hundred municipalities in Brazil and I learned the master thesis of a colleague was about automatically porting it to something more modern (the project more or less failed).
> the rise of Windows as a corporate OS coincides with a rapid adoption of VB for in-company development
Also true of at least one place in the USA. A few thousand Macs went into the dumpster so they could roll-out shiny new VB client-server applications to replace terminal stuff. (Ironically, they were rolling out Netscape 1.1 at the same time.)
There's plenty of "VB Gods" around then. I suspect many C/C++ programmers one way or another found themselves working in a business that had VB as the shop standard? I know I did. I wrote good solid, readable, maintainable, stable code, including DLLs and OCXs - they're nothing special. Some of the projects I did are _still_ in use 10 years later at one location.
Was VB my tool of choice? Certainly not, but it was what I was required to use, with few exceptions. A good craftsman can succeed with an inferior tool. Just watch - The well crafted VB apps will have a half life similar to COBOL.
Most of the languages that have caught the public's imagination support and don't actively discourage developers writing really horrible code but then provide the facilities for people to use as they get better. Python, Ruby, PHP (especially), VB, JavaScript and C++ all come to mind in this regard.
I'd contrast this with languages that enforce a certain style or paradigm in an effort to improve reliability: Erlang, Haskell, Prolog, F#, Smalltalk (to a point). All fine languages but none have quite caught the imagination of the mass of developers.
I love this line because it implies that you can actually become a good VB6 programmer. Sure, you may not be able to sort a linked list, but you can still learn about encapsulation and ... actually, just start with encapsulation; that's going to make your code SO much easier to read :-)