This is the most complete and interesting account I've seen about the beginnings of VB from the Microsoft side. I don't know how I missed it until now, but I'm glad it was posted here.
Source and disclaimer: I'm the "Ruby development 'wizard'" mentioned in the article. Apparently I helped the VB team learn how to code for Windows! I didn't know that until now, but I'm glad I could help.
To amplify on a few points in the article...
The discussion of Custom Controls is right on. There was a myth that the reason Visual Basic was extensible through the VBX interface and custom controls is because Bill Gates insisted it. That's only partly true.
Bill's role wasn't in getting custom control support added to the product. It was to make sure that it wasn't dropped.
The support was always there. After all, when we coded the original set of controls, we needed some kind of interface for them, and it was obvious and planned all along that this interface would be open for others to build controls of their own.
Actually they weren't called "controls" originally. Alan was going to call them "waldos", named after these:
I couldn't make sense out of that name, so I ended up calling them "gizmos" instead. And my little "Gizmo API" was what later became the VBX interface.
Scott also mentions the original "lines and arrows" Ruby interface, where you would drag an arrow to connect an event emitted by one object to an event target exposed by another object. He's right that this ended up not being a usable programming model for VB.
But recently I tried out Unreal Engine 4's Blueprints feature. It was very reminiscent of what we were doing back then! But of course the Unreal team put in all the additional work to actually make this a usable feature - we never took it that far.
>"lines and arrows" Ruby interface, where you would drag an arrow to connect an event emitted by one object to an event target exposed by another object. He's right that this ended up not being a usable programming model for VB.
Fascinating. It's interesting that the modern Qt Creator IDE (for C++) has something similar for its signals & slots mechanism. It has the ability to draw a line from the "signal" (event) of one control to the "slot" (event handler) of another.
I've seen several demos[1] highlight this operation but I don't know anybody that actually follows that procedure. They'd rather just type in the text editor: connect(src,SIGNAL,dst,SLOT);
It's an interesting story but it's told as a "person A did this, Person B did that, and Person C had this idea, etc." Maybe it's a consequence how my brain works but any time I read that type of recap, I forget everyone's name and the other trivia 5 minutes after I'm done reading it.
When revisiting technology history, what tends to stick in my mind is the context and industry forces prevalent at the time and the story doesn't have that.
So my recollection of context in 1990 would include...
1st: The prevailing method of writing Windows programs in 1990 (the Windows v3.0 & v3.1 era) was the raw Win32 API. That meant the 'C' Language WndProc(), giant switch case statements to handle WM_PAINT messages. Basically, all the stuff taught in the thick Charles Petzold book.[1] This was very tedious and complex type of programming. It was not friendly to corporate aka "enterprise apps" aka LOB "line of business" type of programming. (Java would arrive on the scene 5 years later but I didn't see a lot of corporate adoption until v1.3 which was year 2000.)
2nd: You had a large base of old-style DOS text mode developers for line-of-business apps using programming languages such as dBASE III, Clipper, FoxPro, and other 4GL tools, etc. The typical skillset of those programmers did not include the C Language.
In 1990, Windows 3.0 was becoming popular as a platform for corporate desktops and businesses wanted to write apps for it.
Visual Basic v1.0 hit that perfect sweet spot for a bunch of refugees from the DOS text mode 4GL languages to write Windows programs. They didn't have to learn the low-level C language or mess around for months with the Petzold book. Visual Basic had this ingenious abstraction called "forms" that hid the WndProc() monster and its messy switch case statements. It was a huge transformation. It was phenomenal how VB "democratized" the programming of Windows apps. A bunch of ISVs sprung up that built their business around Visual Basic.
The recent parallels to VB as an "inviting tool for newcomers" might be PHP replacing a lot of CGI+PERL and maybe JQuery eliminating a lot of low-level Javascript getelementbyid(). Today, when I look at the iOS and Android landscape, I still haven't seen anything (Titanium? Xamarin?) that grabs mindshare the way VB did back in 1990.
I'm a corporate neckbeard. Probably the opposite of everyone here. And a lurker, so hello!
I work for a company that ignored the industry trends, we picked a winner with "Petzold style" win32 as you put it. We have a 800kloc 20 year old codebase for a LOB product that hasn't had to be rewritten four times due to the abstraction of the hour being changed. No VB, MFC, no ATL, no Winforms, no C#, no WPF, no ASP, barely any COM.
The biggest irony of all of our intentional ignorance of technological progress is that our software works 100% perfectly on Wine on OSX and Linux. It also compiles with GCC under mingw32 and works natively on ReactOS bar a few problems with the OS.
Do all these magical abstractions and platforms do you any good?
I'm less convinced every day.
You're right about mindshare though and as a vendor, that is what pays the bills.
Going to fire up textpad, nmake, windbg and write some code now...
Well I was the last hire in 2004 and we don't have anyone junior in our 3 person team so I can't answer that really other than a ballpark figure.
A good win32 programmer with sector experience could probably jump straight in. Someone with no experience of win32 and the sector would probably be 6 months of work for them and us which isn't a problem.
We interviewed one guy in 2010 who was a "rockstar" win32 and C# programmer (apparently) who wanted a pile of cash and came well recommended. We dumped him on a machine with notepad and the windows SDK and documentation. No visual studio. He didn't even get a message box on the screen. We just paid the guy who was leaving a pile more cash and I suspect that was his ploy anyway.
10mloc product here, about 1 month for a university rookie.
Once you get over, I guess, 500kloc you start having teams with extremely distinct responsibilities (50kloc to 800kloc depending on the complexity of each team's responsibility). This means that you only need to care about your slice of the product. Knowing what's going on with the other systems makes you immensely more productive, but you can actually get places with just knowing your slice.
In terms of mastering the entire codebase? Most likely 6 years: that's about how long it took me.
It's a very strange place to say this, but working on a massive codebase (as opposed to a startup) gives you a very rewarding skillset. I would definitely recommend it if you are considering diving into a massive existing codebase. At the end of the day, the more you know [how to do]...
> Visual Basic v1.0 hit that perfect sweet spot for a bunch of refugees from the DOS text mode 4GL languages to write Windows programs. They didn't have to learn the low-level C language or mess around for months with the Petzold book. Visual Basic had this ingenious abstraction called "forms" that hid the WndProc() monster and its messy switch case statements
VB also hit that sweet spot with me. I had no prior advanced programming experience (beyond silly "What is your name?" QBasic and VicBasic). It was a bridge to the OOP landscape we have today, it catered for zero-OOP (modules) but at the same time did actually have those OOP concepts that you could eventually transition to.
My nephew is much the same as me, he just "gets" computers and logic in general. I struggle to find a recent language that he can pick up and start having a rewarding experience, like I did with VB.
>I struggle to find a recent language that he can pick up and start having a rewarding experience, like I did with VB.
For kids, I recommend Javascript in the web browser. My friend is showing it to his 10-year old son and it's working out great. Javascript benefits include free development tool (notepad or textmate) and cross-platform (Win/Mac/Linux). Javascript will be around for the next 50 years. In my opinion, all the other candidate languages (Python, VB, C#, Java Android, etc) have too much friction in terms of setup (download, then install, etc).
One drawback is that it's hard to deploy Javascript as a self-contained exe unless you include paid tools such as Adobe Flex with ActionScript. (That was another strength of VB -- the ability to compile to an exe with a small msvbvm.dll dependency.)
But then again, a lot of kids have their own smartphones so he could type out a Javascript game on the pc, fire up a web server on the home wifi, and then point his phone's web browser to it. Instant deployment and gratification.
In 1990, the Win32 API thing seemed to be simply prohibitive for me to approach. In Microsoft's defense, my impression of the Apple Mac was even worse, but my Mac had HyperCard.
The introduction of VB is what tipped the scales for me, in favor of Windows, as it was apparent that Apple's interest in HC was waning.
Naturally, it's a horses-for-courses thing, but I agree that VB was huge.
VB was about getting stuff done. Ugly, awkward, convoluted, nowhere near a real programming language. But, the things you could build. Fast. In no time, you had something that worked, installed anywhere, no approvals, no app-stores, no complicated deployments. Microsoft miserably failed to scale it to the web, and with some efforts - to mobile. They just drove developers away, and till today we do not have a similar tool for the semi-developers, the hobbyists, the lawyer who wants to make some app for his office.
> Microsoft miserably failed to scale it to the web
They did, in form of the abomination called ActiveX. Back in the heydays, it was the Java and Flash in terms of exploits and 0wnage.
Obviously the worst thing was that ActiveX applets allowed raw access to the win32 API (or any other external DLL which could be used with the FFI of VB). No one signed their applets and everyone clicked "accept and run"... and on DOS-based OSs like win95/98/98SE/ME or XP (which set up the primary account as admin) this basically meant local r00t on the web.
I'm a high school teacher, and I'd love to hear from some people who know Visual Basic well. I teach an intro programming class each year, and I currently use Python. I occasionally get students who have had a previous class in Visual Basic at another school. These students tend to think they already "know programming", but after two or three weeks in Python they start to tell me they're learning all kinds of concepts they didn't know about, and they say they're enjoying programming in Python more than Visual Basic. There are lots of variables in their experience though, so it's hard to tell exactly what is making programming more interesting to them.
My questions:
- Do you have any thoughts about people being introduced to Visual Basic as their first programming language?
- If one group of students are taught Visual Basic well, and another group is taught Python well, will all students come away with a decent grounding in programming?
I don't ask that as a language flame war, I'm honestly curious about how programming in the VB environment compares to languages I'm more familiar with such as Python, Java, C etc, especially for students who have no previous background in programming.
Don't teach your kids VB. It's a dead end language. I don't think anyone should learn VB anymore and I doubt anyone is taught "well". There are classes in VB and modules. You can write functions and procedures. But something like python will serve you better into the future.
I took every computer course available to me through high school and graduating in the 90's that didn't give me much choice. The teachers were not that knowledgeable so I ended up doing Apple BASIC and QBASIC lessons out of books. Honestly didn't learn much.
I took a introduction to programming course in college which was in C. Most of the time I was fighting syntax errors to perform the most basic operations. I didn't learn much.
I eventually switched my major to computer science and took another 101 course, this time taught with C++. Still I fought segfaults and syntax but I actually learned the basics.
No moral to this story, just I wish I had python as a choice when I was learning.
From my experience VBAs used a lot in the corporate world. Learning VB in high school can be of great use in the future if you're not looking for a tech career. Front-end MS Access, Excel Macros, screen-scraping, vb script to call SQL queries can all give you a leg up in a non programming career path.
I have an older relative who is still cashing in nicely on his VBA skills. There was a "demand vs pay" graph for tech skills going around awhile. VBA is low demand, but among the highest paid of the technologies.
From a cost perspective it's easy to see this. I've made plenty of trivial VB scripts in large/bureaucratic companies to automate tasks that a customer service person(or a whole department) had been doing for an hour a day for the last decade.
Yeah, the weird thing is how large and critical these VBA applications are that he works on. Lots of local banks and small businesses have, essentially, their entire business wrapped up in an old VBA CRUD app. Not that there's anything wrong with continuing to use the old technology, but all we hear about is the latest and coolest.
I learned programming in BASIC, in 1981, then spent some years with Turbo Pascal, HyperCard, and eventually VB. I spent upwards of a decade with VB before switching to Python.
I'd have a couple problems with VB as a teaching language. First, there's the business of building GUI's and navigating the project structure. These are not the basics of programming, and are layers of abstraction that obscure the underlying code.
Second, even if there's a free version, it's an enormous bloated download, and only runs on Windows. Python can run on any reasonably modern computer, including the Raspberry Pi and its ilk.
Third, Python is more "cool" right now, meaning that there is a lot more interesting code and projects being shared and discussed online. I actually consider this to be an advantage for my own use of Python at my day job.
Now I think both groups of students will come away with a decent grounding. Those who get into programming will learn more than one language, and I'll bet that there's little correlation between who's a good programmer and what language they started with.
VB6 is... old, and feels old. It barely allows object oriented programming and doesn't have first-class functions, so you're pretty limited to a procedural sort of paradigm. The IDE is clunky. For example: error handling is done with explicit GOTOs (ugh) and "On Error Resume Next" lets you simply skip past errors(!!!).
VB.NET is basically a friendlier-looking version of C# and is therefore not nearly as bad as VB6, has a real modern IDE, etc.
Python feels like a playground where you can explore; VB6 feels more like you're on a rail and the moment you fall off everything will break.
> VB.NET is basically a friendlier-looking version of C# and is therefore not nearly as bad as VB6, has a real modern IDE, etc.
Yeah, but my feeling has always been that, if you drew a line called "complexity" with VB6 on one end and C# on the other, VB.Net would be much closer to the C# end. Which sort of calls into question what the benefit of learning VB.Net is; for nearly the same amount of effort, you could just learn C# and benefit from all the additional tooling and support options that C# offers.
The big draw of VB through version 6 was precisely that it wasn't a "real" language -- it was much, much simpler than a "real" language, and therefore so easy to learn that practically anybody could do it. VB.Net on the other hand always felt more like they just put C# into a T-shirt that says "I'M WITH STUPID."
"On Error Resume Next" lets you simply skip past errors
Is that very differently from "except: pass" in Python, though? Most languages allow you to skip past errors, the problem with VB was the culture of the users who didn't treat that as a red flag, not the language feature itself.
On Error Resume Next is actually weirder than an empty error handler. If Python errors halfway through a try/except block, it will skip the rest of the block. If you On Error Resume Next, VB will literally just proceed to the next line and keep executing.
And since you don't need to indent the block that comes after On Error, it's easy to miss that line...
In my opinion, the only thing classic VB had going for it -- and even that's a bit of a stretch -- is the relatively interactive feedback loop of UI designing, coding and debugging, which leads to somewhat quick gratification. However, the language is kludgy and antiquated; I feel like it encourages antipatterns and generally bad style. VB.net may be a bit better (I'm not familiar with it), as that still has the interactivity, but most of the language warts have been patched over; but then one could argue, "Why not C#"?... To answer your first question, if you want to teach programming, I would avoid VB like the plague! (Annoyingly, Excel and the like are still all scripted in VBA -- which is very similar to classic VB -- so it does have some commercial merit.)
I think Python is a very good choice as a first programming language; although, if it were me, I would also segue into a bit of C so that the learners can appreciate the difference between static and dynamic typing. What Python (and C) lacks is an idiot-proof GUI designer like VB has. (I know there are obviously things like PyGTK+ with Glade, but it's not nearly as easy as VB's form designer.) Like I said in my previous paragraph, the near-instant gratification of creating a working -- albeit trivial -- program with a visual component really encourages learners to delve deeper. A Python console application will come across as boring, at best.
As for your A/B testing: I believe the VB group will not really understand what it means to program, whereas the Python group -- while harder to encourage -- will have a much more solid foundation on which to build.
I started on VB5/6 and I wouldn't recommend it now, but I believe the language is not that important but the general concepts. Vb6 is a weird language nowadays because is very bad at OOP, is not functional, etc.
Another reason I'd discourage it, is because the language is tied to the IDE/editor and is very difficult to do something without it. Also there is not opensource community around vb6 and there is not much code to look at or to contribute in github. Even if the 'new project' dialog offers you several types of applications the language is very limited to desktop applications and com components.
VB.Net is very good and modern language and it has some interesting features.
I'd rather introduce programming in a nix environment using the unix way, write a shebang here and pick the language you would like to use. Learn file descriptors, stdin stdout stderr, process exit status, pipes, etc. Learn to write small libraries and programs that solve very specifics problems.
Visual BASIC 1.0 for DOS was the first one I learned. I was working for a community college and they had a BBS for Tradewars and other stuff. My supervisor and I tried to write a Tradewars game in Visual BASIC.
Later on we got the Windows version and it was fun writing Windows applications with it.
I got a job later on because I knew Visual BASIC and MS-Access 1.0 had just come out with Access BASIC that was like Visual BASIC and in 15 minutes I made a database in MS-Access to keep track of a record collection to get the job.
Visual BASIC really peaked at 6.0 after that Visual C# killed it, Visual BASIC.Net isn't as good as the Classic Visual BASIC.
I still work on VB 6.0 projects from time to time. I owned all Visual BASIC versions from 1.0 to 6.0 and I have the 2002 and 2003 etc versions on DVD that I barely used.
I find Python and Ruby to be replacements for Visual BASIC.
vb.net is an odd language. Pretty much useless in a way because it's just a less powerful, oddly-syntaxed C#, after using it for a year at one point. Not a bad language but offers very little that C# doesn't, and is missing some. Handles statement was very nice though.
I encounter more and more vb.net because Microsoft uses it as their default "scripting" language for products like SQL Reporting Services. And for that, it actually seems to make sense as a language. In small sniplets it works better than C#.
But honestly Microsoft missed a huge opportunity by not simply making classic VB6 code run under the CLR. In entirely defeats the point of having a common language runtime if every language has to look exactly the same. It wouldn't have been an insurmountable project and would have driven higher the adoption of proper .NET.
How so? I use both (my largest C# project was Nokia Maps, largest VB.Net project is my own database + sync engine, at ~110kloc, spread across Windows Desktop, Windows Phone and WCF sync engine). I've not come across any shortcomings in comparison to C#. Granted I'm using the free editions of Visual Studio, and avoid any third-party components or code. What am I missing?
VB.Net is about as verbose as C#. There can be no perf differences because they both compile to the same bye code. Assuming the dev knows what he/she is doing when optimising for perf in either language.
In what way is it less powerful? I use both in my day job. Sometimes I think C# has more elegant syntax (personal opinion) but I have not been able to not do anything I need to do in VB.
Is there something that replicates the VB experience for the web? Something really easy for a new developer to pick up and build a form based business application without worrying about HTML/CSS/Javascript, etc?
VB was a crappy language because of Basic, but if you could get over that it was a really nice IDE for rapid prototyping I loved the forms paradigm. I wonder what people consider the current leader in this area.
"Ruby on Rails" isn't the Ruby programming language, they are two different things.
But no, Matz had nothing to worry about when he named his programming language Ruby. The Ruby that I worked on had long since become part of Visual Basic.
Source and disclaimer: I'm the "Ruby development 'wizard'" mentioned in the article. Apparently I helped the VB team learn how to code for Windows! I didn't know that until now, but I'm glad I could help.
To amplify on a few points in the article...
The discussion of Custom Controls is right on. There was a myth that the reason Visual Basic was extensible through the VBX interface and custom controls is because Bill Gates insisted it. That's only partly true.
Bill's role wasn't in getting custom control support added to the product. It was to make sure that it wasn't dropped.
The support was always there. After all, when we coded the original set of controls, we needed some kind of interface for them, and it was obvious and planned all along that this interface would be open for others to build controls of their own.
Actually they weren't called "controls" originally. Alan was going to call them "waldos", named after these:
https://en.wikipedia.org/wiki/Remote_manipulator
I couldn't make sense out of that name, so I ended up calling them "gizmos" instead. And my little "Gizmo API" was what later became the VBX interface.
Scott also mentions the original "lines and arrows" Ruby interface, where you would drag an arrow to connect an event emitted by one object to an event target exposed by another object. He's right that this ended up not being a usable programming model for VB.
But recently I tried out Unreal Engine 4's Blueprints feature. It was very reminiscent of what we were doing back then! But of course the Unreal team put in all the additional work to actually make this a usable feature - we never took it that far.