Ryan and David and team, I am so happy to see this posted!
I'm quoted a few places in it. Yes, the story about the origin of the phrase "fire an event" is true and correct. I could even tell you exactly where I was sitting and which way I was facing when that event fired.
Some things stick in your mind, doobies or not.
Also mentioned is the VBX. In some ways, this may have been the worst API I ever designed. It was so bad that Microsoft eventually replaced it with COM! But it was the most successful.
Thanks, Michael! Finding your comments on HN about the design details of the original "Ruby" version of VB and VBX was part of my inspiration for writing this article in the first place. Your recollection of "firing an event" is my favorite kind of classic Silicon Valley story.
Ryan, thank you for writing the article. I remember you described it to me as a "labor of love". Indeed it is that. It also reminds me of how much work goes into journalism like this.
Ruby/VB was a labor of love for us. One of my favorite episodes of Silicon Valley was the TechCrunch Disrupt where every founder said "we want to make the world a better place." It's funny, but true! That is exactly what we wanted to do.
Anyone who likes the "fire an event" story may also enjoy What the Dormouse Said by John Markoff:
Hey, I got started programming in VB3! Thank you for your involvement in forming my expectations of programming.
I feel like my path was so much better because I started from laying out a UI and then learning code as a way to make it do stuff instead of the "lets learn complicated goop with no clear purpose first".
To this day I'm amazed by how ok devs are with not being able to get instant satisfaction from achieving things that should be simple.
Today's equivalent would be an IDE that you hit "new project" and type a few lines and draw a few boxes and you've got something up and running in the cloud. There's nothing like it as far as I know; there's an entire generation or more who have never seen programming work like that, and don't even envision it, it seems. Bold ambitions these days usually amount to a clone of a popular thing, with some kind of tweak that's interesting but not nearly interesting enough to get people to move.
I always loved VB. Super useful for banging together a quick "enter a value in a text box and click a button to do something in the database" utility.
And VBX was a pain, but had some advantages over the COM-based controls. My first job at MSFT in 1994 was to build demonstration apps for interactive TV. When I started there was already a base application in VB3. I needed to add transparently layered images and text with rotation and animated transitions, and a windowless VBX made it easy to build that transparency. IIRC, you could not make windowless OCX controls. I'm not even sure how you'd do independently positioned transparent controls in VB4+.
I hadn't seen that story before, thanks for pointing to it. Lots of great stories on folklore.org! I recommend it to anyone interested in the early days of Macintosh.
I don't think there is a Visual Basic side to the story. Our work was many years after those sorry events.
In fact I never saw the source code for any of the Apple or Microsoft Basics, not even the "Basic" side of Visual Basic. Our team built the "Visual" side of it, code named Ruby. (No relation to the programming language.)
Originally Ruby wasn't going to be combined with Basic at all. It was going to be a user-customizable shell for Windows 3.0. Instead of Program Manager and File Manager, you could create your own desktop with things you wanted on it.
Ruby had a very primitive scripting language, but the language API was designed to allow other interpreters to be plugged into it.
Microsoft later decided to scrap the "shell" idea and create Visual Basic instead.
it's thanks to you and and the whole team that i have a career! i started learning vb late (early 2004), but soon enough i had a small job writing custom software for small business with a couple of friends -- that lead me into actually finding my passion.
honestly, i kind if miss vb6's simplicity: you could create a "proof of concept" in the matter of hours, without having to bother with compiling tools, libraries or anything like that. everything just worked.
VB was my swiss army knife for many years, making utilities for solving organization's pain points, some of which were used unchanged for over a decade. I even made some games in it back in the day!
It was surprising to us (here at Retool) that visual programming has never taken off, despite countless attempts over the past few decades. (That's why we started Retool, after all.) But Visual Basic is probably the product that came closest, and that's why we wrote this homage to it. It, along with Filemaker, Hypercard, are products that we loved. And we always wished that they had flourished, since then we wouldn't have had to start Retool, hah! As Linus says (in the article):
> “For example, I personally believe that Visual Basic did more for programming than Object-Oriented Languages did,” Torvalds wrote, “yet people laugh at VB and say it's a bad language, and they've been talking about OO languages for decades. And no, Visual Basic wasn't a great language, but I think the easy DB interfaces in VB were fundamentally more important than object orientation is, for example.”
> visual programming has never taken off, despite countless attempts over the past few decades.
It has, in some niches like Unreal Blueprints.
I think one of the reasons it doesn't become more popular is because most visual programming is just a more cumbersome and slow way of programming. It's stringing the same concepts together in the same way, but slowly and tediously with a mouse.
Non-tech users wouldn't know what to do with it. Power users would rather program directly.
Originally Ruby had a Blueprints-like UI to connect an event fired by one gizmo to a property of another gizmo. You would right-click a gizmo, select an event, drag a line over to the target gizmo and select a property.
In fact when Ryan first contacted me about the article, he was looking for a screenshot of this UI. Alas, I didn't have anything.
When Microsoft turned Ruby into VB, they abandoned this UI and just kept the form designer with Basic as a scripting language.
> It has, in some niches like Unreal Blueprints. [...] I think one of the reasons it doesn't become more popular is because most visual programming is just a more cumbersome and slow way of programming. It's stringing the same concepts together in the same way, but slowly and tediously with a mouse.
The latter bit basically perfectly describes Unreal Blueprints :-P.
It was hyped when it first came out and for some time (years) it was well received - until people had to deal with the spaghetti mess others made in blueprints.
Visual languages are fine as long as they are limited to high level concepts, but UB not only is not that (there is even a type cast node!) but instead of being there in addition to Unreal Script, it actually replaced it, forcing many people who didn't want to bother with C++ (especially Unreal's flavor of C++) to use blueprints.
Epic supposedly learned from this and UE5 at some point will have a new scripting language, but AFAIK so far it has been vaporware. Meanwhile i (i am into gamedev and have worked with UE) increasingly see people get disillusioned by Blueprints.
I'm the last to defend visual programming, it's mostly spaghetti nonsense and you'd be better of with an actual programming language for most complexity levels -- but I think there's a viable niche for stuff that satisfies both of the following:
(a) it's simple and it strings together off-the-shelf components;
(b) it has an intuitive, well-defined computational model
examples: defining compositions of matrix transformations for camera angles, defining data pipelines (read from this source, do these operations, write to that sink), very simple automation Apple Shortcuts-style (whenever I receive a message from this number, make a note on this file, etc.)
As soon as you venture into general-purpose territory, visual programming is just a disaster. Which is a problem because you have no way to convert your mini-idea into something usable, and you always find yourself wishing you had started with a normal script.
I tend to stay very far away, but it does have its moments admittedly.
The thing is, using modules it should be possible to create even higher-level concepts, so things should become more expressive --- that's how I work in BlockSCAD.
The problem always becomes such expressions become just a list of names of modules and their inputs, so one is back to the wall-of-text problem which a visual tool is supposed to solve --- the fundamental issue is, "What does an algorithm look like"?
and the solution we need is, "What is the most expressive way to create algorithms"?
I wouldn't say it didn't take off, it just has 'landed' again somewhere over the last 10-20 years. VB, Xcode Interface Builder, Hypercard, Filemaker & Lotus Notes all had pretty good runs, we just never got something similarly successful for the web & even smartphones, probably due to compatibility issues with varying screen sizes.
Once the screen can be wildly resized, it just becomes too murky. Maybe have the programmer do it manually for 2-3 sizes and then let some AI model interpolate the sizes in between?
People still use VB and Filemaker to make applications along with very complex Excel spreadsheets. It’s way more common than the general sentiment here implies.
In fact, I get handed stuff made with tools like these somewhat regularly in order to develop a web app. At some point they become unwieldy and limiting.
I think it’s wonderful that anyone with some technical curiosity can make useful applications with these.
Of course they have a lot of limitations. But that’s fine. They can call a software developer when they actually need one.
There is overlap! I've spent the last 8 years working on Grist, which tries very hard to improve on Excel while keep its best aspects, and is open source.
The problem isn't responsive design, GUI builders were able to do that just fine. The problem with making it work on the web was that the dominant design paradigm for web apps was (and to some extent still is) templating, in which there's no clean split between UI layout code and UI controller code and no proper notion of encapsulated components. PHP, JSP, ASP and the <script> tag all mix UI layout with code that works with the database or controls the UI itself. Yet all VB-like platforms require this to be split, because the GUI designer has to be able to edit the GUI code without breaking your app logic too badly, and they really need a strong component model.
How they do this does vary, I don't remember how VB did it but Delphi had a binary file format for describing forms, Java Swing used IDEs with code generation inside magic comments that you weren't supposed to touch, JavaFX and WPF have the cleanest approach with an XML dialect for describing the UI and then the event handlers and controller logic are implemented as classes that are bound to the UI using reflection, Android has something similar, macOS uses NIB files and so on. And they all have a notion of a component being something you can install and treat as if it were one of the built-in widgets. On the web there's no equivalent to this. React sort-of brings components but they don't provide sufficient metadata to be used in a visual designer, and it still mixes code and data together in such a way that visual editors would struggle to not corrupt the user's code.
Ultimately the web came to dominate not because it's a good way to do GUIs. It mostly tossed out what was learned about making GUIs easy to use and develop, because it was never designed to do that in the first place. It came to dominate because it made distribution easy at a time when desktop OS vendors were totally dropping the ball on everything internet related. That's why classical VB-style development app development paradigms dominate on mobile: mobile OS vendors put way more thought into distribution, and that took away the web's primary competitive advantage.
On the desktop distribution can still be quite hard, which is why I put a lot of work into making a tool that makes it drop-dead easy and which gives you the option of web-style forced "immediate mode" updates (we call it "aggressive mode" but that's kind of a dumb name). See my profile for a link. It brings desktop way closer to the web in both UX and DX, which opens up the possibility of VB style development again. Not only for professional devs but also for people who benefit from a lower barrier to entry.
Visual programming is useful in some niches, but for general purpose you either have to have less power than a text based programming language (and users will beg you to add that power) or it will become exactly as complicated as a text based programming language, but more cumbersome because whatever you're doing is slower than typing.
I feel like the whole idea of visual programming comes from some fundamental idea that the hard part of programming is learning the syntax, which I just don't agree with at all.
These are the original low-code tools. Easy to pick up and your average citizen developer could figure it out with some trial and error. So much lost productivity due to whatever happened in the next several decades.
The biggest problem is that it's just impossible to use modern coding tools with them. If we could fix that, so much would work better. Even the best efforts at it haven't really worked out, since there are some truly sprawling VBA codebases out there (tried Rubberduck with a big MS Access app for a business - reliably crashed it).
In science and engineering I would say LabVIEW has taken off. I doubt there’s a university in the world that doesn’t have it running in some capacity. Without learning LV I doubt I would have learnt to code.
Growing up all I knew was Windows, so being able to create fairly reasonable looking GUI apps at the time seemed like magic. I remember building a "web browser" in VB, I put that in quotes because it was really just an IE webview/control wrapped in my own custom UI with features like not recording browser history.
I remember making a "virus" and sending it to a mate, and when he opened it, you could send messages to him and open the CD drive on his computer.
I remember making a lottery number generator program and sending it to my Dad.
I even remember doing work experience in a computer repairs shop, the guy that ran it used to sell PCs with not so legit software on it and he got me a copy of Visual Basic 6.0, which was amazing at the time.
Definitely attribute my interest in programming, computers and everything to VB, no matter how much its look down upon!
> I remember building a "web browser" in VB, I put that in quotes because it was really just an IE webview/control wrapped in my own custom UI with features like not recording browser history.
Haha, I built one as well. Couldn't have the parents accidentally discover what sites their horny teenager visited when they were at work, even if all I could rely on with 21600bps was written smut.
> I remember building a "web browser" in VB, I put that in quotes because it was really just an IE webview/control wrapped in my own custom UI with features like not recording browser history.
Don’t sell yourself short, that’s how everyone seems to build browsers nowadays.
whoa, I made a fake virus too! Mine would freeze the user's screen, and display a progress bar that their hard disk was being deleted. I shared it on download.com and got a few thousand downloads. VB6 was so much fun as a teenager. If you all know anything that is close to it please let me know!
i recall around the time windows released transparent windows API calls. I promptly wired them up into a VB6 app and could make any window I wanted transparent.
I did those things as well as a teenager. I wrote a tcpi/ip chat program and we used it in school to chat with each other. It all seemed like magic to me. I did the thing with opening the CD drive continuously in a loop, and sending this to friends. It was hilarious.
Altough I'd never use it today, it still acted as a catalyser for my interest in programming and computers.
VB was the one thing that most closely approached the promise of object orientation: "bolt-together," "off-the-shelf" components that you could build software with.
In VB you could slap together a CRUD app in days, with VBXs (later renamed OCXs). I worked for a company where a bunch of programmers turned up their nose at VB and insisted on using C++, and then they got canned when the VB prototype functioned perfectly sufficiently for a production app.
> VB was the one thing that most closely approached the promise of object orientation: "bolt-together," "off-the-shelf" components that you could build software with.
I think Delphi perfected it with the data aware components. If you had a DB you could throw together a CRUD application with several screens with tablegrids and edit fields without any code at all. Even Master:Detail relations are taken care of. (Of course it's not pretty and it's going to miss validation, etc...)
Delphi's data aware components were power tools. It didn't take much longer than building something in Access, but dead easy to plug it into a RDBMS; extremely fast to work with; stable, simple to deploy.
As I remember, making validation errors pretty was a bit of a chore, but on most of our backend stuff we just showed the SQL error and it usually made sense.
When I first played with VB in the early nineties, it was also about the time Microsoft Foundation Classes was released. I compared the two approaches for building UIs and it pretty much soured my opinion of C++ for life.
Oh man, while we got a lot done with MFC, I scorned the macro mess that VC++ generated. To this day I detest C/C++ macros and never use them in my own code.
But years later, when I had to switch to the Mac and Project Builder, I couldn't believe how half-assed its integration with Interface Builder was. You couldn't even drag from a control in your UI layout to your view's source code to generate a code stub. You had to manually type stuff like IBOUTLET. And there was no bi-directional updating either, of course. It has gotten a lot better since. Meanwhile, whereas I used to love the Visual Studio IDE itself, I find the same ridiculous bugs in it that I reported 20 years ago...
VB6 is often underrated as a programming language, but it did have some neat things that are still not present in existing programming languages. (They were dropped in VB.NET.) In a sense VB6 is still ahead of its time.
One is the transparent intergration with COM objects, allowing you to access objects in another process (possibly from a different executable) in exactly the same way as in-process object. All the marshalling is done under the hood. The only problem with this is that the execution of a single statement could be intermixed with another statement in another thread. I once had to deal with a nasty bug that was obscured by this fact, which was actually caused by using a programming mistake where someone had used a global variable for something that should have been a method argument.
The other is the very nice event mechanism where there is no need to (un)register event handlers. They are automatically registered and unregistered. Very powerful mechanism that I started to use more and more the longer I worked with VB6.
I think this is one of the things detractors of VB kinda miss. You could build quite sophisticated software to leverage COM/DCOM without needing to go full C/C++ and IDL.
The place I worked at built software that ran inside Microsoft Transaction Server (latterly COM+) to exploit distributed transactions.
And then there's the really "advanced" stuff you could do in VB as written about by Matthew Curland in his excellent book "Advanced Visual Basic 6: Power Techniques for Everyday Programs"[0]. Armed with a copy of Curland's book and Don Box's "Essential COM" you could be really dangerous :)
It is incredible how on one hand WinDev has doubled down on COM after the way Longhorn was botched and rebooted into Vista,coming up with WinRT afterwards.
While on the other hand they keep failing to deliver a VB like experience to deal with all that COM.
All C++ improvements were killed in the name of the mighty IDL, and even .NET has always been hit and miss with RCW/CCW, and CsWinRT requires manual boilerplate coding.
I think Java and .Net are pretty close. It is utterly shameful that languages like Python and JavaScript consider themselves to be developer friendly when their debuggers still require full reloads whenever the local state gets modified in place. Common Lisp had Edit and Continue (equivalent functionality in their debugger) before the dotcom crisis.
Vercel and Microsoft product managers, if you are reading this, please implement this feature in Next.js, VS Code, and Typescript.
I've had good luck using Python with COM. It has some rough edges, but it works well enough, and can even tab complete methods and accessors in the REPL.
Was a huge fan of the product. Joined the VB team as a PM in 1996 and worked for a few years while my health declined. The whole division was beautifully run. The people were, to a person, amazing human beings. I honestly think I stumbled into the best team Microsoft had before or since. The Microsoft campus was verdant and tranquil. Everything you sort of imagine Apple would be to work at was true on that team, and has never actually been the case at Apple. At the same time our first child was born. For me, it was a time of pure magic. All that and I got to work on VB.
I don't know who approved the inclusion of VB in Word, but that person is a hero.
WordBasic was a career-maker for me. I worked at a Big-6 consulting firm and used Word to parse and rewrite thousands of SQL modules (that resided on a VAX, no less) with a Word macro when the DB structure changed. It ran for 11 hours and saved man-weeks.
That was after I had used WordBasic to add tons of features to Word for our doc team, which we take for granted today: cross-file searches, cross-file page numbering, style enforcement... just incredible.
It's sad to see the mess that Word has become, however. And Windows too.
I joined the VB/Ruby dev team in 1992, first as an intern and then full-time a couple years later and stayed in the team thru 1999 / VB6. I implemented the Data control and some of the data binding logic for VB 3.0. It was such a special team and code base - even 30 years later I still fondly remember my HDesks, HDeskrefs, and Gizmos. We tried hard to get the Ruby forms engine running on the (what became the) .NET/CLR runtime - but alas it was not to be.
Hey Stephen, I wrote the original article. Had no idea that MS actually tried to port the Ruby forms engine to the CLR—what a fun twist. Did it end up being too difficult technically, or were there other factors that killed it?
We kept the Ruby forms engine as unmanaged code written in C/Win32/COM and tried to integrate it with Basic code compiled and running on the CLR, but it didn't work very well. There were a lot of problems back then (this was 25 years ago now, a couple years before .NET 1.0 shipped) with CLR/COM interop. One particular problem I recall was that the interop layer did not support calling event handlers via IDispatch which the Ruby forms engine required.
> Everything you sort of imagine Apple would be to work at was true on that team, and has never actually been the case at Apple.
I'm glad to hear your Microsoft experience was amazing. But as someone who worked at Apple during that time, this assertion is untrue and seems unnecessarily mean-spirited.
Agreed, and I apologize. I should have said I never met anyone who loved their experience at Apple. Thanks for catching that, and for doing it so civilly.
Ideally we should have a modern programming language and environment that
a) is very easy to use for new comers and people that aren't professionals to build small functionalities and link different functionalities together
b) has visual components (so this disqualifies Python)
c) it is flexible and can be used by seasoned professionals to build complex things
The complexity of the programming should be gradual, i.e. if you are a beginner, if you are learning, if you don't plan to be a full time programmer but you need to build something very simple, it should be possible.
When I studied programming in highschool, the tool of choice was at first Turbo Pascal. Using Turbo Vision it was easy for US to construct simple text-based UIs and using BGI allowed us to dabble with graphics and draw simple things in a simple and straight forward way.
Now, if I have to explain to a potential beginner that in order to build a simple to do app he should learn: HTML, CSS, Typescript, React, install VS Code, install VS Code extensions, linters, NPM, sass, less and tens of packages, just to be able to start, he might feel a bit discouraged and want to become a cab driver instead.
But if I, in a totally unmodern, uncool, unwelcomed by community way I tell him to open Notepad and show him a few bits such as <button onclick="myFunction()">Ok</button> and alert("Ok") he might discover a taste for programming, and start to learn his way up to building something.
And there were things in this general direction... Smalltalk and Logo spring to mind.
But there is a lot of culture in computing, and a big problem that isn't recognised let along acknowledged is that today, there are basically only 2 surviving branches on one tree, when 30-40 years ago there was a whole forest.
The branches are Windows (which now means NT) and Unix (which now means Linux and macOS). They both grow out of the same stump: DEC's minicomputers, specifically DEC's 16-bit line.
DEC also had 12-bit, 18-bit, 20-bit, 24-bit and 36-bit lines, all profoundly deeply unlike anything that ever ran C.
And of course there were lots of other minicomputer and mainframe brands that were far far more different than that: Burroughs, UNIVAC, NCR, Control Data Corporation (CDC), RCA, General Electric, and Honeywell. Once known as "IBM and the seven dwarves".
All we have left descends from one branch: DEC 16-bit machines.
The rest is mostly gone. Some are still around, emulated and in maintenance mode, because they run the world's banking systems and air-traffic control and things. Kinda important.
There are whole families of languages and OSes that never used a single line of C or involved any Unix code at all at any point. Whole types of OS and GUI and editor and filesystem and so on more different from Unix than Unix is different from Windows NT.
Whereas today, the traditional Mac is totally gone, replaced by Unix. And Windows is getting more Unix-like all the time and now includes a choice of Unix and two different Linux runtimes.
Suggest that, hey, let's run Smalltalk on the bare metal and teach kids on that, so that they don't even have to ever know what "a file" is or means, and people will say "that's crazy talk!"
Remember the Blues Brothers? "We got both kinds of music! Country AND Western!"
Well, we got both kinds of software today! Unix AND Windows!
They are the same damned thing, and gods help you if you are some heretic that says hey, you know, there are other things out there...
>But there is a lot of culture in computing, and a big problem that isn't recognised let along acknowledged is that today, there are basically only 2 surviving branches on one tree, when 30-40 years ago there was a whole forest.
I guess 30-40 years ago computing was much newer, there was a lot more enthusiasm and people were willing to try many new things and do things in many different way. At a conceptual level, Go isn't very different from Java which isn't very different from Python. LISP is quite different from Smalltalk and Smalltalk is quite different from ML and ML is quite different from Prolog.
As for small, home operating systems, BeOS was quite different from both Mac and Windows. :)
> Suggest that, hey, let's run Smalltalk on the bare metal and teach kids on that, so that they don't even have to ever know what "a file" is or means, and people will say "that's crazy talk!"
A file is just an abstraction, and so are Unix pipes. I don't see while there can't be other valid concepts to hold data than files.
One of the leading contenders for being a modern equivalent IMO would be the Godot game engine.
The Godot editor is less than 100MB to download for many platforms--the recent Godot 4 release also supports running the editor on the web[0] and on Android.
Its packaging/distribution story for GUI-based applications is easier & stronger than any other modern programming environment of which I'm aware--in a large part due to the (IMO inspired) architecture of using per-platform pre-built application templates/shells paired with per-project "data" files that contain assets & script byte code.
Godot's modularity, ease of development & distribution has led to it being adopted for non-game applications too: "Apps & Tools - 2022 Showreel" <https://www.youtube.com/watch?v=9kKp0oguzr8>
I do think the initial "complexity of the programming" for an absolute beginner is probably still at least a little bit higher than drag-and-drop GUI environments like classic VB, REALbasic, VBA or Hypercard. (Primarily from a UI/UX point of view because Godot doesn't directly have the "drag button from toolbar" workflow which I think was key in earlier systems. But it is extremely modular by way of configuration & extension--one intended use case being e.g. specialized feature-subsetted tools for artists.)
In my experience it also works really well for iterative development where you can just hack around (from visual & code perspectives) to get something working & then refine it (and using Godot's "Scenes" paradigm for encapsulation).
Anyway, you might like to consider suggesting Godot next time you're riding in a cab & discover that the driver is a beginner who would like to learn. :)
I mean, the notepad method still works, and there's nothing stopping you from going down that route. Hell, you can probably make it easier: open up a browser on any page, open up the inspector console, and you've got a REPL and semi-visual environment right there at your fingertips. A combination of that and using notepad to "save" your progress would probably be a pretty potent learning tool.
I don't really know what your point here is. Professionals use different tools to beginners to program? Yes, obviously this is the case. I started making videos with Windows MovieMaker, but that is unlikely to be the favoured tool when editing together a Marvel blockbuster. But you can learn a lot just by using more simple tools and then graduating to the more complicated ones when you find you need them.
The WYSIWYG GUI builder that VB provided, I have never encountered afterwards again in quite that manner.
Now, in VBs heyday the field of UX design we now have as a profession adjacent to software development was in its infancy and was usually an implicit part of the developers job. What was lost with the demise of the RAD tools was a potentially shared medium of expression. Today designers build Potemkin villages in Figma and the likes, throw them over the fence and as a developer I then need to reverse-engineer them. How much more productive would it be if they didn't throw something over the fence but would actually build the UI in the same tool that the developer uses to write the logic behind it?
And another thing: I don't know if I had gotten into the field without BASIC. I started with QBasic, because it was the only thing readily available and switched over to VB when I got my hands on a students' edition. The thing that distinguished these two from educational environments like Scratch or Logo is that I could build actually useful stuff for myself with it.
The WYSIWYG GUI builder that VB provided, I have never encountered afterwards again in quite that manner.
At the time I think delphi did that concept in a better way, and I definitely switched from VB to Delphi as soon as I learned about it. Delphi still exists to this day.
There are also many low code platforms which have a VB-like UI builder, like mendix, or outsystems or microsoft’s power platform, but they tend to be a bit too enterprisey where VB was really the people’s champion.
I think canvas apps in power platform give much of the “feel” of dragging and dropping visual basic forms and let you build actually useful stuff, while targeting web and mobile. The downside of power platform is that as soon as you try to do anything serious with it you need the premium stuff and end up paying a lot. That makes it less suited to take up the niche that VB and Access had, because that niche mostly can’t afford power platform. Contrast that with scratch which is free to use and has a large community of “regular people” sharing cool stuff. Intuitively it seems that Microsoft should make power platform entirely free and use it as a lure for azure paid services, but then it is easy for me to spend their money.
By the way, I still don’t understand how power apps on iOS are according to apple’s guidelines, because you can use it to ship mobile apps to iOS users while entirely bypassing apple.
I remember in Access(for like $100 one time) and how you could use a wizard to build like a contact manager with all the tables and forms. I always thought that was really cool. Now I guess you can spend like $30/user per month or something like that.
I think the WYSIWYG WPF and Silverlight tools were pretty close to VB6 level of usability. The tools are great for building a quick UI, but I think they fall short for more complex applications.
This is why designers have their own preferences when it comes to designing the UX, to give them the flexibility to create the UI as they see fit. When different teams are working on a shared goal, there can always an element of "throw it over the fence".
As a developer, I always saw part of my job as getting plugged in with the other teams as much as possible. Providing continuous advisement and feedback on UX patterns as projects progress really helps things move smoothly.
I would argue that "more complex applications", when it comes to UI, are an anti-pattern. Use standard widgets, and don't be creative.
Of course "standard widgets" don't really exist anymore because of where UI design has gone, but they did provide a consistency that users could rely on. That is gone now. Buttons don't even look like buttons anymore.
The GUI builder of VB6 fell apart the moment you wanted to do a resizable window. Here "more complex applications" = "window that you can resize or maximize".
VB.NET/WinForms (and competitors like Qt Designer) had a pretty good solution for widget placement on resize, all within the GUI builder. So i don't think this was fatal, if Classic VB had survived a bit longer it likely would have been added too.
(Although to date they don't have a great solution for responsive layouts.)
1. Microsoft did a good thing at that time with Visual Basic. Building visual interfaces with RAD tools is the most efficient way, as defining visual elements with code is harder. VB was great at its time, Borland Delphi and C++ Builder were good, QT Builder was good, Windows Forms was good. Of course, why use good models when you can inflict pain and let people define UIs by using plain code?
WPF used XAML and the new MAUI uses XAML, and while it is a better experience to define the visuals with XAML, a RAD tool like VB or C++ builder is much better. We should have RAD tools for desktop apps and mobile apps.
In my software career I've not only built apps and websites and web applications and backends, but I worked as a game programmer, too. And people preferred game engines like Unreal and Unity because they were rapid tools with which is was much easier to build game levels and UIs than doing that by code.
2. I didn't use VB, because by the time I've encountered VB, I already knew C and C++ and felt they were more powerful and fast. I enjoyed using Borland C++ builder very much, and I wondered why MS didn't provide such a tool and enforced Win32 over programmers. I thought Microsoft hated programmers. And being that failed to provide one API for desktop programming, switching from Win32 to MFC to Windows Forms, to WPF, to MAUI - I still sometime think MS doesn't do the best job with providing tools for programmers. Now that MAUI is the thing, I hope it will stay and won't be replaced in two years by another thing.
3. If people think using Haskell or Rust is hard, they should buy Petzold's Book and try to program Windows with the info provided in that book. To do very simple things like apps with menus and child Windows, you really had to spend hours, correct compile errors, have the program crash, debug it, make it not crash, observe that things don't work as they should, change the code, solve errors, observe that the program crashes, solve those bugs, make it not crash, observe that things don't work as they should. And all that without having learn.microsoft.com, stackoverflow, YouTube to learn from.
WPF’s and Android’s approach are the best of both worlds. You get both a visual designer that can get you far, and human-editable XML, which is useful for more complicated layouts or for copy-pasting similar widgets around.
Yes, note that JavaFX has the same approach but also has a visual designer (Scene Builder). It can be used from any JVM language which is a lot these days. Like, you could write a JavaFX app in JavaScript or Python if you wanted to.
There was more to VB than just guis though - one could use it to build COM components far more easily than with C++ - the fact that a string was just String rather than the miasma of competing flavours that abounded in Visual C++ was worth the price of admittance alone.
Delphi was arguably best in breed here, but always suffered from lacking the Microsoft badge.
There's a generation of programmers that fell into software development through Visual Basic. Maybe you could say the same about the Apple II/Commodore/ Sinclair/ BBC Micro generation of computers that booted up to a BASIC prompt.
When I was younger, I HATED VB6. Even today, I still loathe some of the weird apps that I had to support running in Excel with VBA. I truly never thought about the power of VB until I read this article - those apps I loathed so much probably wouldn't have existed if it weren't for VB. I ran into so many tools that provided immediate value and go things done, even if it was dodgy or weird.
Even though I'm a Platform Engineer these days, I hate the tooling that we have to do deal with today. Instead of having people build solutions, we all need to understand hundreds (if not thousands) of cloud/vendor-specific APIs. The actual solution itself is almost a by-product of the job of getting in run in the cloud.
Maybe don't bring back VB, but a world where we can deliver solutions quickly and effectively without spending hours debugging dependency issues between releases.
Checking in. I learned OSCAR and YMSG before HTTP. I recently tried to find a modern vb6 type setup that wasn't DOM (electron style) based and works cross platform. Best I found was javafx and scene builder.
You might try Lazarus Ide. Very much like VB6 though language is free pascal. Actively developed, good documentation, and lots of libraries. https://www.lazarus-ide.org/
That's such an easy thing to do as a product. All the comments you see are all clamouring for some set of features that will just complicate everything. Yet a majority of the users have absolutely no issues continuing on with what they already have. You need to be able to figure out how many quiet happy customers you have if you want to make any big breaking changes...
When I was college my first programming job was writing CRUD UIs in VB (I think it was 4 or 5) for a local contract dev shop. I was only a sophomore at the time, and the money I made helped me pay for college.
I know people ripped on VB the language, but I still haven’t used anything to date that was as good and easy at creating Windows CRUD UIs.
Visual Basic 4 is when I fell in love with programming. I remember staying up late (school nights no less) just playing around and designing GUIs.
I had done some programming before with Pascal, C and even QBasic, but nothing was quite as fascinating as dragging and dropping fully functional controls and having them light up with functionality in minutes.
Up until a few years ago, I was still reaching out to WinForms / C# to build quick prototypes - maybe it was part nostalgia, but I didn't find anything comparable when it comes to quickly standing up a GUI prototype (for a LOB type of application, or a small utility / tool kind of thing).
“Up until a few years ago, I was still reaching out to WinForms / C# to build quick prototypes”
What replaced them for you? I still use Windows forms a lot for prototypes and utilities and was curious if there is something else I should be looking at.
Hilarious quote (notwithstanding the fact that bus drivers usually have to work shifts, also on weekends):
> Almost all Visual Basic 6 programmers were content with what Visual Basic 6 did. They were happy to be bus drivers: to leave the office at 5 p.m. (or 4:30 p.m. on a really nice day) instead of working until midnight; to play with their families on weekends instead of trudging back to the office. They didn't lament the lack of operator overloading or polymorphism in Visual Basic 6, so they didn't say much.
The voices that Microsoft heard, however, came from the 3 percent of Visual Basic 6 bus drivers who actively wished to become fighter pilots. These guys took the time to attend conferences, to post questions on CompuServe forums, to respond to articles. Not content to merely fantasize about shooting a Sidewinder missile up the tailpipe of the car that had just cut them off in traffic, they demanded that Microsoft install afterburners on their buses, along with missiles, countermeasures and a head-up display. And Microsoft did.
...and it applies not only to Visual Basic, but also to many open source programming languages today. There are the users who are happy with the way things are, who are content to do their job and don't say much. And there are those clamoring for that one more feature that they just have to have, and those are the ones that eventually get heard, adding more complexity and cruft for everyone else.
VB.NET wasn't that different as a language, it was more of a Python 2/3 situation. Lots of overall improvements, but not backwards compatible. Terrible, but not catastrophic. What MS did was break the whole ecosystem.
VB6 had thousands of third-party libraries distributed as VBX/OCX controls. VB.NET had effectively zero, because it could only use the new WinForms controls. You could upgrade your codebase to VB.NET using a wizard (that would often fail), but if your software relied on OCX, there was no way forward.
This could be implied with your python comparison, but meanings of things changed as well. For example dim foo as integer(5) in vb6 would give you 6 elements (0-5) of a 16 bit numeric type. In .net it would give you 5 elements (0-4) of a 32 bit numeric type.
> For example dim foo as integer(5) in vb6 would give you 6 elements (0-5)
Then add into the mix the "Option Base" statement, which if it was declared as "Option Base 1" your aforementioned array would only have elements 1-5. Trying to access element 0 would incur a "Subscript out of range" error.
VB to VB.NET was more to do with .NET arriving with the .NET Framework, and one of the reasons for the .NET Framework was all about keeping up with the (at the time) amazing framework/core library that Java had. It was also about web front ends which of course VB6 could not do.
In the old days people used to custom-build massive CRUD desktop database applications for their company to use internally and I built some of those in VB6. Loads of UserControls nested inside each other, solutions with multiple DLLs, you could do it but it was really clunky. Error handling was rubbish. I had also built things in Java and could see what VB6 was missing. .NET fixed that.
So I guess the 3 percent of Visual Basic 6 bus drivers who actively wished to become fighter pilots were probably people who had used Java. Java was free, if you didnt want an IDE. Whereas VB6 was actually quite expensive (can anyone remember the cost of a VB6 Pro license?)
The people who moved to Go a while back, when it was unpopular, because they loved it, aren't that vocal (apart from the continuous cries of "just use the standard library!").
The people coming to the language from other languages, not because they like Go but because they need to use it for work (because it's now a popular language), are very vocal about how they don't like it because it's not what they're used to (though usually this is phrased differently - usually complaints about Go's "inexpressiveness").
I was one of the people who loved VB6 and struggled with VB.Net, wandering through JS and PHP, until I found Go and fell in love with it immediately. I would hate for history to repeat itself and the Go team to make the same mistake that MS did with VB.
Well - basically, if you wanted to become a fighter pilot and had VB1-6 experience and wanted the "RAD" forms tools, but also wanted true OOP, there was always... Delphi
You could do pretty much anything with Delphi that you could do with C/C++ on Windows.
Correct - but Delphi was available in the VB3-4 timeframe, years ahead of .NET.
When .NET was in beta, I managed to participate through a Microsoft friend - and, saw that the writing-was-on-the-wall... I dropped my tentative exploration of Java (I had even become a Sun partner) and focussed all my efforts on C#, I could see that was the way forward (especially considering it was up for ECMA/ISO certification as well) and basically never touched VB.NET or VB again. (Outside of some VBA within Excel/Word/etc)
I thing the point being made is that those things were available prior to .net - Delphi existed in a stable state with those facilities long before .net did.
Fair but I wanted to be a fighter pilot because the money was better than driving a bus. So I learned c#. The company I worked for, a software dev house, said that they were VB only be they wouldn’t bring in c#. They died within 6 months of me and everyone else leaving.
C# and .Net was a gold rush. VB was only valuable where the primary business function was not software delivery.
I'm not down with the "bus driver" metaphor, but the bit about a vocal and active minority steering the direction of the technology for the rest of us certainly rings true. I think a read an article on HN about exactly this, but in the terms of React and Wordpress.
Nothing is wrong with bus drivers! :-) I'm not sure comparing software developers to bus drivers is a metaphor that gets us very far... In fact, why some bus drivers might want to really be flying fighter jets also had me scratching my head.
Kind of like the loads of everyday bus drivers safely carrying many more users around, compared to the uncommon fighter pilot doing risky things very few users will need to do.
The problem wasn’t they added more advanced features to the language, the problem was they changed the whole development environment in a backwards-incompatible way.
Or: Microsoft heard the voices of the entitled souls who looked at working applications and thought they were bad because they weren't DRY enough or something.
That's how we ended up with CRUD apps that are practically indistinguishable from their Visual Basic 6 predecessors, except they're deployed on k8s clusters instead of a 133 MHz Pentium in the corner.
"Why can't we have nice things like SOLID, DRY, domain driven design, abstract factories, builders, decorators, bridges, facades, visitors, mediators, observers, strategies, chains of responsibilities, SAGA, CQRS, log aggregation, distributed tracing, exception tracking to consume 90% of our productive time? 10% for actual functionality should be enough."
For what it's worth, I am a bus driver these days; a real one, no metaphor involved. And I sufficently disliked and mistrusted Visual Basic that already in the mid nineties I instigated a complete ban on any vb**run.dll on all computers under my jurisdiction. Mainly a heuristic: VB applications tended overwhelmingly to not being worth the inevitable trouble.
I have proudly carried this curmudgery into the present century, these days applied to Java runtimes and Mono libs.
Public transportation? I'm curious probably because I do consider switching careers. Bus driving - in my fantasy - provides some of the features I sort of desire (clear schedule, clear expectations) while lacking those I annoy (further educating outside of work, tendency to take problems home with you). What's your situation?
It wasn't the best language, no. But it was so damn easy to slap something together just to get things done. Draw me a window this size, put one of these there, one of these here, hook this method up to this button/slider/whatever... go!
Was it great for large-scale, complex stuff? Not so much, IMHO. But was it great for slapping together a quick, useful util or demo? Absolutely.
Oh this brings back the memories of good old VB6. Never encountered such a simple and easy to use UI builder after that, probably because I left MS ecosystem for more open technologies. Just drag and drop. Double click on the component and start coding. How simple was that.
Wow, brings back lots of memories. In high school I got started writing VB3 for my father's small software development company. I'd end up working full-time there for a handful of years after college, really pushing the boundaries of what one could do with Visual Basic. I don't think there's a single tool or language that I've loved more than it in my entire career.
Twenty-seven years later, still one of my proudest accomplishments is to have had a multi-year project that I worked on featured in "Visual Basic Programmer's Journal".
Beta testing "Thunder" (code name for VB 1.0) was one of the most exciting things in my career. As a long time QuickBASIC user, looking longingly at those C++ developers writing Windows apps, I was floored when I got my hands on VB. I was finally able to create a graphical Windows app without having to learn C++ (which I later did, because I wanted to write VBX controls).
I did what I often do with new languages: write a stock charting and technical analysis application. Microsoft loved it and asked me if they could use it for demonstrations. They showed it off during the VB road show because they could show Microsoft's stock (up) vs. IBM's (down).
The early VB community was fun to be a part of and VB3 was the pinnacle for me. VB4 was a mess and it took until VB6 to finally get things right again, but at that point I had given up on C++ and was writing Java applets.
I don't think Microsoft failed to see that most VB programmers wanted to keep VB as it was.
Microsoft killed VB with a clear purpose: controlling more tightly as much as Windows development as possible, copying the Java model with .NET.
If that seems like too conspiranoic theory, let's say that their new Devs head, Anders Hejlsberg, wanted a more uniform development experience around .NET and its star, C#.
It wasn't deliberately killed. The problem was that VB6 had weird semantics and behavior by the standards of other languages, but .NET was designed primarily around Java's semantics. Rather than pollute their nice next-gen platform (that they wanted to standardize through ECMA even!) with lots of VB6 compatibility goop, Microsoft chose to change VB with a new version that was closer to a normal .NET language. For example, in VB6 parameters are always passed by reference, but in C#, Java and VB.net they're passed by value.
They also didn't seem to care much about being fully compatible, for example VB6 had some fairly basic features that WinForms didn't have.
They also didn't seem to care much about being fully compatible...
That sounds deliberate.
Edit, to clarify: I doubt they didn't anticipate the frustration and the hit on the mindshare. From Ballmer's show, shouting "developers", to spit in the face...
I didn't use VB6, but I do remember the complaints.
I dont see how .net was more tightly controlled than VB? VB was a closed source proprietary language tightly integrated with the IDE. They had absolute control.
They had no control over other vendors' programming tools. Borland Delphi used a more difficult language, but generated compiled, autocontained faster binaries, had a better out of the box library, similar third party components market (same language for programs and libraries, unlike VB that often used C++ controls) and was starting to develop a version for Linux.
Microsoft had been poaching most of Borland's talent:
Later something interesting happened. Microsoft settled just another suit, this time for office applications. I don't remember if it was a spreadsheet or a desktop database and I've been unable to find it in the news, but I clearly remember that Borland received $30M in cash and priviledged access to Microsoft's dev documentation.
Then Borland abandoned Kylix, its Delphi version for Linux and released Delphi 8, that wasn't a native tool, but only worked on .NET. Next versions of Delphi included both .NET and native compilers and .NET creeped into Delphi IDE making it much slower. FUD was spreaded that Microsoft will eventually close all native developement and you will only will be able to use .NET to program for Windows.
Delphi versions for .NET were never as good as VS, always lagging in features, and finally they were abandoned. But the distraction lasted long enough to kill the company.
It's not the same to target a binary API and a virtual machine. The first must be stable, backwards compatible and follow specifications.
So .net was a deliberate ruse to trick Borland into delivering a sub-par product?
It’s weird because a very common complaint towards .net was that it didn’t allow you to build self-contained stand-alone applications the way VB6 and Delphi allowed. So possibly Borland could have attracted a lot of disgruntled VB6 developer who migt have found Delphi more familiar than VB.net.
> FUD was spreaded that Microsoft will eventually close all native developement and you will only will be able to use .NET to program for Windows.
Given the the dominace of Windows was because of the available software (and Microsofts dedication to backwards combatibility was legendary) I dont see why anybody would belive that.
Sorry for the delay, very busy lately. In case you're still there and interested in the answers:
So .net was a deliberate ruse to trick Borland into delivering a sub-par product?
Not exactly, they wanted to create a walled garden, more similar to an app store. Drivers and some specialized programs that require high performance would still need to be native. But most everything else they wanted inside .NET ecosystem. That would eliminate any competitive advantage that Delphi had.
Given the the dominace of Windows was because of the available software (and Microsofts dedication to backwards combatibility was legendary) I dont see why anybody would belive that.
And yet in the Borland forums at the time there was a very vocal faction, including many of the official evangelists, that bought it.
Borland was caught in a trap that Joel Spolsky described perfectly:
Microsoft offered access to docs. The bait. Also the price structure of Borland had gone horribly bad. The insisted in selling to the enterprise market because, they said, there's no money in reasonably priced dev tools. But that was just not true. JetBrains filled that gap. I believe Delphi still exists but it costs ten grands or something like that.
Edit: another couple of factors why the wanted everything in .net were security (native is uncontrolable) and possibility of instantly disassembly the applications of any potential competitor. Yes, I know it sounds paranoid, but...
> they wanted to create a walled garden, more similar to an app store
Clearly this didnt happen - you can still run native executables on Windows, here 25 years later. Indeed this is why Windows was and remains popular - the amount of software you can run on it, including decades old native binaries.
.net was a reaction against Java which was considered an existential threat to Microsoft because it promised platform-indepentent software. (Turned out it was the web and javascript MS should have been worried about, but they realized that to late.)
Delphi was never a threat to Microsoft. Microsoft was just happy when people developed windows native software. Selling windows was strategically much more important than selling dev tools, so they probably wanted delphi to be succesful.
No, there's a Windows app store that nobody wants to use, obviously.
Delphi was never a threat to Microsoft.
Microsoft clearly saw Delphi as a threat: they proceeded to hire as much talent from Borland as they could and only relented because the suit.
Java and the web is what killed Borland.
That's difficult to believe. There are other companies that succeeded selling dev tools that didn't come close to Delphi. They just shot themselves in their foot.
You know why Visual Basic was the best programming language ever made? Because it wasn't a programming language.
Nerds just can't wrap their heads around this idea: no normal person wants to be a programmer. But they do want to make little custom things to help them get stuff done in life. Just like nobody wants to be a plumber, but they do want to be able to fix their faucet.
> Nerds just can't wrap their heads around this idea: no normal person wants to be a programmer.
I'm coming to the exact opposite conclusion: A lot of people benefit from programmin a little.
Which, at the time when VB came out, was a very popular opinion. Still enough computers around with BASIC as their interface. User-focused databases like dBase. Spreadsheets.
VB was a bit in the uncanny valley between "professional" and user-focused programming, which is the main source for most negative opinions about it.
I still think that more end-user programming is the right choice, but now that our software runs on someone else's computer or is completely walled off due to manufacturer choice or language cruft & learning curves, we've got our own little priesthood. I don't believe that "AI" will change this, but we would certainly deserve it.
>> Nerds just can't wrap their heads around this idea: no normal person wants to be a programmer.
>I'm coming to the exact opposite conclusion: A lot of people benefit from programmin a little.
These are actually the same thing. There's a difference between having a little power to shave off the rough edges of your computing day as say an inventory specialist for a warehouse and being a kernel developer
People benefit from a little bit of programming ability, but they don't want to be programmers
Just like people benefit from being able to change their own oil but don't want to be mechanics
Agreed. I’m working on something to try to get back to that. But I’ve been bumbling through so many diff ideas that who knows if it’ll ever see a launch, let alone adoption.
I think it’s fair to ask power users to come up a little to become a programmer, but then they get a much better system to their liking.
I feel like there’s so much unnecessary complexity these days in different JS frameworks, CSS approaches, build and dependency systems, etc.
The problem arises when a clueless manager sees your tiny custom 50-line program and makes it responsible for anything more complex than a water dispenser, with the author and his boss praising the "simplicity" and "ease of development" of what is going to become the bane of the organization for the following decades.
I do understand that most people don't want to be programmers, and that's fine. At the same time, professional software development needs professional software developers.
Sure, most of us like to be able to fix a faucet, but would you trust a hobbyist plumber to design and maintain the toilets of the Yankee Stadium?
Does this really happen often? I’m not saying it doesn’t, I’ve just heard the claim repeated often while never having seen it myself. Maybe because every project I’ve been on was far over-complicated rather under.
A small, crappy prototype would also go far in sussing out requirements. But I’ve generally not seen that included enough in the development process for most big corporate internet projects.
I think you're conflating programming with coding. Us nerdy types like coding because it's so flexible and powerful. But setting an alarm is programming, as much as building a spreadsheet etc. Using a computer device for anything more then consuming media involves some degree of programming it. Everyone is a programmer now.
But there is a big difference between being able to build and deliver software starting from nothing but a directory full of code and configuring point and click interfaces. Most people don't need to be coders. They just need to be able to program their computers a little bit.
Excel is another amazing piece of software, that is almost universally looked down upon by programmers. Why make complex calculations in a GUI if you can just write a Python script with numpy and pandas!?
And yet, so much of the world runs on excel spreadsheets being sent back and forth. Why? Because 1) it has a low skill floor and very high ceiling, 2) everyone uses the same tool (or at least it's backward and forward-compatible), and (critically) 3) it has a "programming model" that actually makes sense to the vast majority of people.
Same with Arduino, by the way. I think Arduino is a masterpiece. It allows people that don't even consider themselves programmers to write code for embedded systems with ease (traditionally a very hard thing to do). They go to the Arduino website, download a program, open an example, click a button and it works.
Also, the libraries are designed to be used by non-experts. That's so rare in the software world (and I don't know why*).
* I have some guesses but they are not nice to the programmers that make and use trendy software libraries.
To give a little anecdote, my 600 person company probably has 200+ engineers (mostly electrical with some mechanical). I'd say that 1/5 has some programming skill in Python or C# and 1/10 probably is pretty decent and spends 5+ hours a week writing code. I'm fairly confident that all 200/200 are competent Excel users with most all spending 10+ hours a week doing spreadsheets mapping data together and analyzing it. Pandas is great, but if you don't need all the stats and the dataset fits in the spreadsheet, Excel beats it hands down in most uses.
I would not be surprised. I have said before that Excel is the most widely used programming environment in history and will continue to be so for the foreseeable future, and it is all precisely because it provides users an on-ramp to programming in a domain where it is sorely needed.
Whenever I hear someone hyping up some lowcode/nocode thing or asking about it, I point them to Excel and Access and say "that concept is older then Python, and it's not going anywhere".
As someone with an MBA (I know… forgive me father for I have sinned) I actually had been thinking that simple Python and maybe something like Jupiter might actually be a great alternative for spreadsheets while teaching business.
I not knocking spreadsheets- they’ve obviously stood the test of time. I feel their weakness is that the formulae are hidden and you’d need to click on individual cells to make sure their isn’t a logic error.
Don't get me wrong, I think Jupyter Notebooks are great if you are a programmer or want to learn programming.
But there's a massive usability gap between downloading an application and "open the command line, run pip install jupyter, oh pip is not installed, google the error message, copy and paste this command from a random website, try again, etc". It's better now with JupyterLab Desktop, but that's only been around for a few months.
You can program Excel using Visual Basic for Applications. At one of my former workplaces, a backend colleague of mine built a functional prototype of a new feature in Excel using VBA in far less time it took whole UI + frontend teams to build the same.
Access could easily become a victim of its own success if the dataset got too large. I made some money off of a couple projects where that happened. I had to convert them to sqlserver to both handle the data load and for true multiuser.
When I worked with Access it was normal to separate the database into separate front end and back end. Then when the quantity of data or latency got too large you could easily convert that to SQL Server.
Funny: back in the late 90s I ran a quite large (for the time) discussion board and everything was stored in an Access MDB file, similar to how people try to do today with SQLite. I didn't know better, that's how I though things worked.
It worked quite well for several years, until of course I reached a limit (which was much smaller than 4GB), and I had to delete old posts.
But the big that MS & MS fans don't like to mention is that MS Exchange Server uses a version of the same storage engine.
It's not mentioned even once in these Wikipedia articles, for instance, but if you look, you will find telltale giveaways such as Exchange store size limitations:
These days, it's also used in trivial unimportant Windows subsystems such as -- er -- Active Directory, Windows Update, and the Windows Search indices.
Yes, the fragile, essentially single-user, easily-corrupted Access DB engine is an integral part of Windows Server.
Which is a bit odd considering MS also owns SQL Server (bought in from Sybase), and could in principle use that instead, which does not have these built-in limitations and is rather more robust.
Access was in part built in response to Lotus Approach, which brought Claris Filemaker-like simplicity to Windows end-user databases. MS could not tolerate that, so built its own Approach-killer, which was vastly more complex. It acquired FoxPro, a dBase III/IV clone, for its very fast indexing functionality, which was bolted onto MS Cirrus to make Access, and the rest of FoxPro went largely unmaintained until it could be discontinued.
Exchange Server of course replaced MS Mail, which was also bought in and was previously called Network Courier from Consumers Software. Other MS purchases include Powerpoint, Frontpage, Visual BASIC, and Visio.
There is a general pattern evidence in 1990s MS software which isn't universal but widespread. If it's lean, mean, simple, fast, or elegant, it was bought in. If it's overcomplex, fragile, has bizarre limitations for non-obvious reasons, and needs careful maintenance, it was built in-house, probably in response to a successful competing product.
Sigh - don't get me started on Jet engine DB corruption... You wink at it, over a network with more than a single user - and you have a chance of corruption...
IIRC there is an easter egg in Microsoft Access 1.0 where the About box changes to an animation of a pond with two ducks in it that are then hit by lightning from a cloud above.
I.e. a cirrus and a 'pair of ducks'...
Yes, true. I was never a database guy but my impression at the time was that this was more of a capable tool for pros who wanted to do machine-local standalone stuff, whereas Approach won reviews and tests for ease of use.
OTOH saying that I've seen amateurs do amazing stuff with Access by trial and error....
> IIRC there is an easter egg in Microsoft Access [...]
> a cirrus and a 'pair of ducks'...
If you have a spreadsheet on a share that you'd like multiple people to have concurrent access to, Excel is not the way to go (until now; nowadays you can just put it on OneDrive and add access). Access was perfect for that kind of configuration for a small office that you could customize a small database without being a DBA.
I use it for a few hobby things and it's fun. Drag and drop a few things in a form, add a couple fields and you're good to go! Sure beats having to write SQL by hand and a few hundred lines of Python to interface with it; and that's before you write the UI for it.
I wish MS would spend a little bit of that R&D budget to improve on it some more, and expand its capability. But that'd cannibalize their other products, likely. It's too niche nowadays.
If you're ok with your data being duplicated in multiple files, you're ok with Excel.
If you want your data centralized, with the application being a portal to that data, you use a database with a frontend built in your choice of language.
Why won't you accept this isn't a workable solution for the vast majority of people? Comments like this give me a brief moment of wanting every engineer in tech (me included) to be laid off and replaced with excel people
If your situation has reached the point where Excel is no longer a workable solution, you need a full application. I've never seen an Access application that didn't grow to a point where it wasn't a glitchy mess requiring a rewrite as a full stand-alone application. So you might as well skip that step and go straight to the stand-alone application.
"Why don't everyone drive the same car as me? Dress the same as me? Read the same books, watch the same series, talk to the same people? It's clearly working great for me! Buncha rubes!"
Well, except that VB didn't become popular simply by being shipped by default on millions of Windows desktops. It earned it's popularity by scratching a huge itch (at the time).
VB was great though. Maybe the syntax was a bit clunky, but the overall developer experience was far ahead of other languages. Integrated debugger, edit-and-continue, code completion etc.
I’m fairly certain that the only way to originally purchase VB 1.0 was an 800 number posted in Dvorak’s weekly PC Info magazine column. It was $99 and I borrowed it from my manager. I still have the original manuals and 3.5” disks.
It was almost like Microsoft was sheepishly waving it and saying, “maybe you’ll think this is cool,” while not directly challenging their C++ audience.
I just want to add that as popular/cool as Visual Basic became, the first few years it was derided by most “real” developers as a crappy shortcut. PowerBuilder was king for awhile and even Delphi was ahead until VB 6.0 crushed all the competition.
As a system programmer who used VB6 as a glue or ochestrator (early 2000s) of low level components I say the only important flaw I found was on its single threading model.
In the 2000s VB was rusty but amazed me when I remembered that pedantically (shame on me) criticized the VB developers of the 90s against the C/C++ hardcores. It was on high school though. Nerd issues.
I also remember my dismissive high school analysis of VB and wouldn't mind an opportunity to slap my younger self for blind dogmatism. However, I also remember that the fight was a two way street. My high school had classes in both VB and C++ and there were multiple calls from the local business community to cancel the C++ class. There was no reason to teach a dead language when knowledge of VB was enough for a lifetime career. Especially with the emerging web, where companies would need a ready supply of VB script developers and ActiveX control creators for their sites (JavaScript would be deprecated once the last five people using Netscape came to their senses).
> As a system programmer who used VB6 as a glue or ochestrator (early 2000s) of low level components I say the only important flaw I found was on its single threading model.
As a developer cutting my professional teeth in the late 90's / early 2000's, VB was amazing for building utilities and other bits of software run by individuals on their machines. When we tried to reuse components built for those applications in our web applications, issues with the threading (single threaded apartment) model soon became apparent, so we rewrote those in C++ in order to support the level of concurrency we needed.
I can remember doing stuff in VB when I must have been 14 or so. Coming to it from QBASIC it felt incredibly powerful and incredibly complicated.
I think I managed to cobble together a simple form that informed the user the computer had a "virus", made it up as an .exe, and stuck it on a timer on the family computer for shits and giggles.
I started programming with VB4, and built a lot of cool stuff in VB6. Went on to learn C++, C, Python, and a bunch of other cool languages to build a bunch of cool things.
Nothing really quite feels as approachable for a beginner as VB did, those days.
I started with visual basic. It was my first programming language, It will always hold a place in my heart. For beginners, having a UI is very important i think. Visual basic was unique in being able to click to together your UI.
When I started to learn programming in the mid-90s, it was still common to not have home Internet (or, if you did, it was too expensive to spend the whole day online). I learned a lot of programming from the VB helpfiles, a random book on VB from Barnes and Nobles, and recording VB macros in Excel and frankenstein-ing them back together to do different things. In particular, learning from recording macros and seeing the command was a very intuitive way to learn - I didn't have to guess at what the first version of a program would do.
The visual basic 6 debugging experience, where I could drag the program counter around willy-nilly and edit code mid-debug, remains the pinnacle of developer experience I have ever seen.
As a young contractor I was told about an on premies lawn mower kept getting stolen. I asked if there was a telephone line down in that part of the buiding. Wrote them a vb6 app that monitored a
magnetic door contact sensor on the LPT Printer port with a vb6 timer that looked for a state change and would send AT commands to the modem to call the on site manager if the door with the equipment was opened during a non standard time. Took a few minutes to do this in vb6 and clients were super happy.
In the early 90s I was working in downtown Seattle. The manager of the project I was on was married to a product manager at Microsoft. One morning he showed up with a beta copy of VB 3.0.
There was a young, brilliant, programmer, James Shields, who was my partner working on a project. We took one look at VB3 and both immediately saw the potential of vbxes.
At lunch we came up with a couple of initial ideas for custom controls, wrote them, and began selling them on Compuserve for $5 each.
Soon I wrote some controls for working with the just-released Sound Blaster card, which gained some interest on Compuserve's music-related forums, I actually traded messages with Jerry Garcia one night.
But our first big hit was Message Hook which I wrote to overcome some of the limitations of using the Windows API when using VB. That lead to Mitch Waite (publisher of many popular computer books in those days) contacting me to revise the Visual Basic How To. The result was the Visual Basic 3.0 How-To, which was almost all entirely new material.
My approach to writing that book was to think about the things that one would want to program in Windows apps but could not easily accomplish with Visual Basic ... and to solve those problems. Message Hook featured heavily, a copy was included with the book's diskette.
Soon enough the internet came online and I wrote a number of internet controls which allowed thousands of Visual Basic programmers to add, primarily, email and ftp to their programs, however there were controls for more obscure protocols as well.
Visual Basic 3.0 was magic! It was an entirely new idea and several companies, including Mabry Software which was founded by me and my programmer buddy, had a good business until .net blew up the entire ecosystem.
I think it's probably fair to say that VB 3.0, and our internet controls, made a significant contribution to the evolution of the internet.
I picked-up a copy of VB1 (student priced, so... $140 CAD, IIRC) - and built a few simple apps (Character creator/manager for original Cyberpunk RPG, dice roller, bowling league management) while I was in school.
Once I left school, I built a couple 'bespoke' commercial applications; 'WinReal' (AFAIK, the first Windows-based real-estate appraisal software - in Canada at least), 'WireStrand Estimator' (would calculate multi-strand wire/cable material requirements accounting for "twist-over-time" and number of individual strands with or without a core strand) - and a retail POS/accounting system used by a small local chain of 'CD' stores.
But - my real transition from 'glue together controls with some simple logic' was when I was working on that retail/POS software and suffered a project corruption and lost all the code...
... to prevent this from ever happening to me again, I reverse-engineered the .MAK format, and then wrote a simple version control application that would use that to make copies of all the contained files... (I guess I could have just pulled from a directory folder, but - yeah, hindsight is 20/20 - I learned alot and became a better code)...
Around the time of VB3, transitioning to VB4 - my corporate job was having a devil of a time doing that, because they purchased EVERY single VBX control on the market - but had no design standards/governance around which could be used - so, we had an application with about 90 different forms, and there were at least 20-30 different 'textboxes/buttons' from different VBX vendors spread throughout that (based on developer preference for pretty icon in the control panel) - transitioning to VB4/OCX was a nightmare, because not every vendor was also upgrading in a timely fashion.
Myself, I had started outgrowing the constraints with VB3 for personal/hobby/side-hustle projects - and ended-up using Delphi. I could create and sell a standalone, single-file multi-media screensaver - with not VB runtime dependencies. It was faster, more powerful - but never caught-on for my commercial/corporate clients. (In 20 years, I have only found 2 organizations that used Delphi internally)
Ah... memories... Now no one lets me code anymore (well - in compiled fashion - I do alot of DevOps/automation scripting)
The Visual Basic language always seemed weird to me, with two ways to call a method, setting the return value using the equals sign, the = and <> inequality operators, and other confusing syntax bits.
> They didn't lament the lack of operator overloading or polymorphism in Visual Basic 6, so they didn't say much.
Java still lacks operator overloading to this day. Also, VB6 had properties, something that Java lacks to this day (and no, Lombok doesn’t count).
Microsoft killed Visual Basic on purpose. They wanted to force everyone to move to c# because they were afraid of Java and wanted to compete against their market.
MS tried to embrace, extend and extinguish Java. It got blocked in court.
So, instead, it pushed .NET instead. "If it ain't dot-net, it ain't worth sh*t."
So everything that wasn't dot-net was killed.
Real VB loved by millions? Dead.
QBasic, QuickBasic, Quick C? Dead.
FoxPro, a good dBase clone, the database of choice for millions of businesses worldwide in the '70s, '80s and '90s? Dead.
FrontPage, democratising the web for millions? Dead. HTML is dead, use ASP.net.
I have some experience here and can share my frustrations... I wrote the original version of a product named React Studio (https://reactstudio.com). It's sort of a "VB for the modern mobile-first web". Unlike VB though, it's runtimeless and exports regular React code (there's no closed blob or mandatory custom packages in the output).
An enormous thing that has changed since the 1990s and those halcyon days of Visual Basic is the central role of design. Back then, overall consistency was a pillar of desktop UI. If your app's buttons looked like Windows buttons and you could use Tab to move through input fields, that was usually good enough. VB provided that kind of usability out of the box. The PC platform was fairly homogenous: you could assume that your user has at least a 800*600 screen, so you'd just make your application window that size and the MVP can ship.
Today's UI designs must deal with an enormous variety of physical form factors and display resolutions. But even if your no-code tool is able to deal with this and provides a consistent UI that scales from phone to desktop, it's not nearly enough. Commercial visual branding has replaced consistency as the central pillar of UIs. Now your buttons must never look like default buttons, and your UI must use a custom font even though the OS standard font would be more readable. This is simply what customers believe they want.
Unfortunately the web is a very poor platform for expressing UI designs in a consistent way, so literally everyone has their own haphazard UI framework. Basic components like pop-up menu buttons are commonly written from scratch. Nobody can agree on how to style a button. Et cetera ad absurdum. Your no-code tool should somehow integrate into this customer-specific private universe. On top of this mess, your primary input is visual designers who draw static pictures of applications in Figma and expect those to be translated into code. Often these designs are entirely lacking in structural thinking. (These designers typically come from a graphic design background, so they are very interested in fonts and padding widths but have never read the Apple Human Interface Guidelines or any other UI fundamentals. Hence they're mostly concerned with making sure any prototype application looks exactly like their Figma document.)
In my experience, the only reasonable way out of this trap is to focus on applications that are not of interest to the designers, i.e. internal business tools. Retool seems to be very successful here. I also use Retool in my day job and appreciate its no-nonsense design.
You can also plot a middle path. JavaFX Scene Builder for example supports CSS, style sheets and custom themes, but also supports visual design and layout. However people with a graphics design background would still need to learn a bit of UI design like how to make responsive layouts, and they wouldn't be able to use Figma anymore. Animation also isn't that well supported. Still it can be done, it's mostly a case of investment.
The Jetpack Compose guys are trying to do it the other way around - generate layout code from Figma files.
The web is a mess compared to text/binary data we had to deal with in the 90s and early 00s.
Personal Computers used to be a productivity oriented tool. VB6 was designed to handle business data. Today mobile phones are like sentiment manipulation devices or consumerism sinkhole. Could iPhone owners created apps on their iPhones? No. It's a ready-only OS.
Well "Visual Basic for the web" can mean many things. If you mean just an app builder online, then there are hundreds of options, the most popular probably being Retool or Bubble. Or do you mean run locally like Visual Basic and then output to an intranet web browser? Also, do you need basic language, or will Javascript be enough? For me, what is important is the spirit of Visual Basic, easy to use local applications that can be distributed as standalone apps, and an amazing component ecosystem
Beyond the other issues like styling, components were a big part of the VB experience and they had several features that the web hasn't been able to match:
1. They exposed metadata that let them be installed into visual designers and have their properties/events be controlled visually.
2. They could be compiled native code, which allowed people to integrate licensing and make a commercial marketplace for them.
3. They could be written in other languages like C++, allowing VB devs to rely on harder-core programmers to solve some gnarly library or algorithmic problem that was then exposed to them semi-visually.
The web has settled on React components for this but they don't satisfy any of those above features.
There's also a deployment issue. VB apps were "deployed" by just sending someone the EXE, or sticking it on a shared network drive, or maybe building an installer for them. There was absolutely no auto-update story whatsoever if you weren't using a Windows SMB mount which is why the web eventually displaced it, but it was really damn easy to get that first version to people, much easier than for a website (until PHP with shared web hosting got popular).
These days EXEs are much harder to make and send around due to safety features. There's code signing to contend with but also the expectation that you don't impose a choice of OS on users, maybe that you support mobile, that the app will update itself in case of bugs and so on. It's slowly coming back though. With Flutter you can make a mobile app using the app stores to do update, and then bring it to the desktop using Hydraulic Conveyor (my product) to do updates and packaging on the desktop with Codemagic or GitHub Actions to produce the binaries for each platform.
My recollection is that VB6 deployment got messy when you started stringing together lots of third-party components, since they had to be installed and registered system-wide. Windows XP introduced registration-free COM through SxS manifests, but a lot of us couldn't use that for years after XP came out, because we had to keep supporting 9x and maybe 2000.
Yeah, once data files, OCX controls and more got involved you had to build an installer and Microsoft didn't provide any solutions for that until MSI came along. And InstallShield was expensive. So that hurt VB just as people were moving towards the web where you didn't have any dependency issues like that (assuming all the servers were online).
Lots of companies offer "low code" or "no code" tooling nowadays. Only no company has market monopoly power anymore to be a focus point like Microsoft was in the 90s.
Author of Yazz here (and a big Retool fan), I was a former C++ developer and seeing visual basic for the first time in the mid 90s was a breath of fresh air for me. Now that I have time I"m writing an open source passion project of what I wish Visual basic could be in the modern age. So web based, uses Javascript as the scripting language, and editable components. Thanks for a great article Retool! :)
I went from VB6 to C#, and lived through the drama surrounding the end of VB6. Everyone one had something to say, but here are some words from Bruce McKinney https://classicvb.net/hardweb/mckinney.htm
I'm a big fan of twinBASIC, more successor than clone.
It's working on full backwards compatibility with VB6 (and very, very close to it, even many complex UserControls work), with a lengthy list of new features (x64-- through compat. with VBA7 x64 syntax, multithreading (via API for now, native syntax soon), generics, overloading, Unicode-everything, defining interfaces/coclasses in language instead of TLBs, easily makes standard DLLs, Implements-Via syntax to extend classes, parameterized class constructors, can specify UDT packing, bitshift operators, inline initialization of vars, forms support modern image formats/transparency/alpha blending, AddressOf works on class members... well, the list goes on for quite some time: https://www.vbforums.com/showthread.php?890181-TwinBasic&p=5...
One thing I'm sure lots of people here will find blasphemous, it lets you make kernel mode drivers, provided you stick to WDM (you could do this as a hack in VB6, but you had to strip the runtime dependency out-- which dramatically limited usefulness, not to mention no WOW64 for kernel mode. tB has no runtime dependency so all you have to do is avoid strings/variants/most but not all arrays, as those call user mode APIs behind the scenes). Proof of concept: https://github.com/fafalone/HelloWorldDriver
Main downsides are that it's also like VB6 in being closed source/commercial (only restriction on the free version is a splash screen on x64 exes though, and won't have access to compiler optimizations or cross-platform compilation when they're implemented; no restriction on commercial use or royalties), but the creator seems amenable to changing that if it's viable, and since we've had 20 years of no community stepping up for something like this, it's just a practical matter that for one person to do it they'd need income as it's a major undertaking, not something you can do as a hobby with full time employment doing something else, at least if it's going to get done in years instead of decades (*cough* Radbasic, which has made near zero progress after being announced around the same time, and is barely a step above Hello World support).
think people are missing, VBA is all over the place right now. its not going away. because that's the only language that comes pre-installed on a Windows machine in the average Office.
Any other programming language, from powershell to python, is almost certainly locked off and blocked off by corporate security policy and 10 layers of bureaucracy and organizational organizational-ness.
This is how the world actually works. Because the half-broken obsolete proprietary vendor systems that run the world's major corporations need to be glued together to have any semblance of efficiency, and that glue a lot of times is VBA.
It's basically the continuation of the PC revolution, the PC within the PC if you will. Pushing out and decentralizing the access to computing to the desktop of every employee.
They didn't:
"Visual Basic's initial release in 1991 was followed by five major versions (not including an ill-fated version for DOS). By the time Visual Basic 6.0 was released in 1998, its dominance was absolute"
TBH, VB for DOS was indeed not very successful, and while fun as a concept (I've recently coded a Wordle-clone with it it), all things considered it's not very practical nor sensible.
I got started with Visual Basic 2.0
I wrote a shareware game in VB3 in the early 1990's called "Nisus Missile Master", a Missile Command clone.
If I remember correctly, I sold just over 400 copies.
My game made it into "Shareware Magazine" (print). I was also interviewed by the author of "Programming Games For Beginners" by Chris Howard, a chapter about Missile Master, and shareware sales.
You can find and play it here, but the emulator is very slow.
I'm quoted a few places in it. Yes, the story about the origin of the phrase "fire an event" is true and correct. I could even tell you exactly where I was sitting and which way I was facing when that event fired.
Some things stick in your mind, doobies or not.
Also mentioned is the VBX. In some ways, this may have been the worst API I ever designed. It was so bad that Microsoft eventually replaced it with COM! But it was the most successful.
If anyone has any questions, fire a comment!