The Birth of Visual Basic (2006)
forestmoon.com
forestmoon.com
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.
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);
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.
[1]http://www.amazon.com/Programming-Windows-3-1-Charles-Petzol...
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...
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.
That's our only problem!
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]...
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.
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.
Turn Node Applications into Executables https://news.ycombinator.com/item?id=8221233
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.
https://news.ycombinator.com/item?id=7602816 (6 months ago on Boring Systems Build Badass Businesses)
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.
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.
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.
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.
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."
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.
And since you don't need to indent the block that comes after On Error, it's easy to miss that line...
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.
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'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.
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.
Of which there are a lot. Or were, I hope that's changed a little now.
It scares me just how much of the finance sector is still running on some hacked together VB script tied to an excel spreadsheet...
But for anything new, you might as well use C#.
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?
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.
http://bugsquash.blogspot.com.ar/2013/02/in-defense-of-vbnet...
* Method resolution (I actually prefer C#'s but I can see the advantages of VB)
* XML Literals
* Many more query comprehension operators than C#
* Don't have to put `Select` at the end of a query comprehension expression
* Filtered Exceptions (coming in C# 6)
* Ability to call module functions without fully qualifying the name
* The `WithEvents` and `Handles` keywords
For 'rapid prototyping' of a website, I guess that would be Wordpress.
"I guess" you didn't think to check.
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.