For me VB6 was the pinnacle of GUI design/rapid prototyping.
I know that many people are going to say I'm wrong and that VB6 was a cancer, but hear me out:
o Drag and drop GUI designer
o action oriented language
o surprisingly advanced integrated IDE
o It was easy, simple and reasonably fun to learn
I know why QT/GTK and various other GUI systems use a HTML-y grid layout, but for me personally, I always struggle to make nice looking, well laid out, functional GUIs with them.
just give me drag and drop, and ideally a python backend
I've still got VB6 apps running in the factory, that have required virtually zero maintenance in 14 years. I originally wrote them for testing during product development with the promise that "the dev team will write proper apps before we go into production." Famous last words. ;-)
Then along came VB.NET, and I switched to Python. The big epiphany for me is that I no longer lay out GUI's. I let Tkinter lay them out for me. My realization is that anything I do deliberately other than just a simple vertical arrangement of widgets is likely to make things worse. What VB6 was letting me do, was to create GUIs that are no better than most industrial Crapware.
I've also learned for the simplest things, not to make a GUI at all. People can modify some entries at the top of a text script and run it in the interpreter. At first glance, you'd think a GUI would make it easier, but people struggle with most custom GUI's anyway -- evidenced by noticing a sheet of paper at the work bench with handwritten instructions for using the software, whether it's something I wrote, or a professionally written app.
Your "industrial crapware" survived for 14 years with basically no maintenance. Most software today can't even go a week without bugs.
I think VB6 let you create some incredibly powerful, stable, useful programs, and everything you've done since has taken you further away from this ideal state.
People can modify some entries at the top of a text script and run it in the interpreter.
That is significantly harder for most people than just clicking on buttons.
>>> I think VB6 let you create some incredibly powerful, stable, useful programs, and everything you've done since has taken you further away from this ideal state.
That's certainly possible. My job has changed since then, so I'm no longer in a position to write that kind of stuff any more. My present "clientele" tolerates the Python ecosystem well enough.
> I've also learned for the simplest things, not to make a GUI at all[...] you'd think a GUI would make it easier, but people struggle with most custom GUI's anyway -- evidenced by noticing a sheet of paper at the work bench with handwritten instructions for using the software
This is an advantage that the Web browser has that is sadly under-appreciated and under-utilized (even from Web developers).
Many traditional desktop GUIs and modern Web applications would be better suited for their audience if they were instead executable SOPs. Think: a manual for how to use a given system, except at the point in the instructions where it's describing a certain feature, or where it calls for a certain step to be performed, there is some on-screen affordance that allows the reader to take care of it right there—right at the spot they're already looking at.
Some programming notebooks try to do something like this, but they usually get it wrong.
Raskin seemed to have the same epiphany (albeit pre-WWW) and wrote about GUIs being a "dead end".
My team has been experimenting with this -- using Jupyter notebooks to document processes while also providing the scripts to implement those processes. Jury's still out. We haven't been doing it for long enough to know all of the possible pitfalls and ways of making it work better.
Problem with VB6 was that for small projects it was fine but for medium to large projects it gets out of hand very quickly.
For example when you drag and drop toolbar items onto your form it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget so after a while just looking at the code you started to get Label1.Text = "blah". I seen that in just about every project and one I remember done by a Chinese dev with poor English he left all the controls with the boilerplate names and so it was impossible to reason about what was happening.
Componentisation was also a problem in that you tended to have all your code connected directly to the form. So if you had a large form that done complex stuff it wasn't unusual to have a multi thousand line long form file.
Separation of concerns was a problem in that again the code was attached to a form so you found UI code mixed in with proper business logic. This becomes very messy over time and tends to create very large event handlers the more a project grows.
It was basically impossible to unit test which makes refactoring very risky. On large projects what generally happens then is that no one is willing to refactor anything as they don't really know all the scenarios. Over time this leads to code rot.
It only ran on windows, while I'm sure there are ways to make it run under linux the main support was for windows and most orgs stuck to that. This ties in with the fact that you had to install the thing on your P.C. businesses hated this and still do. Things like people uninstalling it or problems locally with permissions and suchlike were rampant. Similarly updating was a pain on large projects you have to have something central install and do the update.
Scalability was problematic on large projects especially since the forms app would often directly connect to the database. That meant the more user = more connections which on large project meant problems. The "solution" was some service or api which the app talked to but at that point it's no longer vb6 doing the heavy lifting and it's just become a UI.
Small little tools or prototype apps was were vb6 shined brightly.
Most of that stuff is really up to the programmer and not due to the tool. While i agree that VB6 wasn't a good tool to write big projects on, it wasn't because of the issues you mentioned (since those would apply to something like Delphi and Lazarus too and they are certainly fine for making large projects on), it was because at its core it was a rather simple and limited scripting language bolted on a WYSIWYG form designer with some database stuff latched on via an extension system.
If anything some aren't even issues but features - e.g. being able to have code attached directly to events speeds up development a lot and if you need to put it somewhere else (IME the case where this isn't necessary is more common than the case where it is) you can simply have your handler call some method in another file so you can keep those separate.
"So if you had a large form that done complex stuff it wasn't unusual to have a multi thousand line long form file."
Just a small quibble - you would typically move shared-code into seperate module files.
The other biggest challenge we had was when trying to build a larger solution that worked with COM dependencies amongst multiple projects, you would occasionally have to do a clean-build which break binary compatibility (don't forget to do a registry cleanup!), and that mean "compiling" your tree manually, from the base level components upwards. That got much easier if you could get your hands on a Microsoft MCS tool called, VBBuilder. (I can't remember if it ever was available for open/free download)
> but for medium to large projects it gets out of hand very quickly.
Yup, it was really built without sufficient attention to the "programming in the large" featureset, much like those BASICs of old. Of course this became less of an issue in VB.NET that was pretty much a C# equivalent.
> it automatically gives them a boilerplate name. You can rename these but you tend to find devs would forget
The "Object Inspector" interface to form-element properties (including its identifier in code!) was very unintuitive, so this was a predictable outcome.
> Componentisation was also a problem in that you tended to have all your code connected directly to the form.
Yes, because it was difficult to have a full global view of the code that might drive a refactoring. Each form element and event would bring up its own tiny window of code.
VB6 had several positives but i'd put the "mostly live" (e.g. modifying the code while it is running/debugged) features it had - more a dynamic scripting language and less a static compiled programming language - rather than those you mentioned since Delphi and C++ Builder did those better (i learned Delphi just by playing around with it when i was a teenager in the 90s - i barely even understood English at the time, so i'd say Delphi was also easy enough).
> just give me drag and drop, and ideally a python backend
There is Boa Constructor[0] which is a very Delphi/C++ Builder inspired IDE that uses Python and wxPython for the GUI. Sadly it seems to be abandoned with the last release being in 2005.
For a modern (or at least still under active development) approach i'd suggest Lazarus[1], which is essentially a cross platform (works on Windows, Linux, Mac and a bunch of other OSes with Win32, Gtk1/2/3, Carbon, Cocoa and even Amiga GUI backends) open source Delphi written in Free Pascal. To see it in action, here is a video i made with it 7 years ago, making a 2D tilemap editor (the IDE is mostly the same, there have been a couple of minor changes but not anything big)[2].
Thanks for sharing these links! I also learned Delphi in the late '90s as a teenager, and still find Lazarus to be very useful to rapidly develop simple applications that have a GUI!
My first paid programming job while in college was writing VB5 (then VB6) Windows CRUD apps. Given the built in controls and controls packs one could purchase, I made some amazing looking GUIs that were pixel perfect. I think even now, it's hard to find something better for that narrow use case.
VB.Net IMO was a step back.
VB wasn't some great language, but the entire system was very productive and worked well with other MS technology of the time like MSSQL and Access.
They improved it later with some VB6 compatibility packs, but yes, that should have been there from the beginning.
Or as I mention on another thread, .NET should have been what was later WinRT, by improving COM tooling and that was it, but now we are 20 years too late to fix that.
However, there wouldn't have been much hope for a cross-platform .NET if it were COM based... and cross-platform is one of the things keeping .NET relevant - Personally, I was (reluctantly) about to ditch .net until that.
Well, VB.NET was little more than a variety of C# without curly brackets and with more keywords. AIUI, it was quite possible to transpile from one to the other at will. Though I think that some convenience features went the VB.NET to C# direction, so it wasn't totally without consequence.
Both vb.net and C# compile to the same bytecode. So fundamentally, if you code for a hobby or are a lone coder, it's down to what you prefer (I prefer vb.net over C#), however organisations made it clear early on that C# was much preferred so that's what prevailed.
If I'm quickly knocking up a small GUI utility then the drag-drop building nature of a vb.net forms app is a real time saver - but in contrast you have more flexibility if you build controls via code like C# does.... horses for courses really.
Bizarrely, I've recently started exploring using C# as a CGI back-end via .NET core on Linux... for the simple reason that I can. Apparently it can be quite performant.
Nothing I've used since has the same level of rapid prototyping and development VB6 made possible with its GUI. Debugging as well was a breeze. VB's inherited commands of string manipulation made possible a lot of niche parsing/conversion utilities I wrote for companies.
I think Netbeans/Java/Swing comes very close. It's still very much alive and actively developed. Bring in the IntelliJ IDE themes and it's full steam ahead no-bullshit development of cross-platform beauty.
I am not a Pascal developer, but Lazarus + Free Pascal >>>>>>>>> Netbeans and Java. Seriously. Java looks like a turd everywhere and it's laggy and slow even on a mid range machine.
On older ones like my Celeron the lag on menues it's noticeable.
Also, modern Free Pascal has OOP classes and methods if you like these.
If you run software made in Free Pascal like Cartes Du Ciel and them some Java one like Sweet Home 3D, the first one will run circles on snappiness and speed over the second one.
IDK how Java can be appreciated, most of its desktop software runs far worse than AMSN over TCL/TK in early/mid 00's under an Athlon.
Well, many people do not seem to know that and associate Pascal with whatever they were taught in the university (assuming they were taught about it at all and their knowledge doesn't stop at "Pascal = Old = like COBOL Old = Bad" :-P). I remember a friend of mine whom i hadn't seen for years laughing when i mentioned i used Free Pascal and asking if it even has objects (in that order). He was just joking, but people can have a lot of assumptions about languages like Pascal that tend to have been around for a long time and have a lot of dialects :-).
FWIW AFAIK Free Pascal got its OOP stuff from Delphi (almost, but that is historical details) which in turn is an extension to Turbo Pascal's OOP stuff introduced in TP5.5 which in turn was based on Apple's Object Pascal extensions that (AFAIK) were designed with Niklaus Wirth's help during the late 80s. The OOP functionality Free Pascal has and mainly uses started with Delphi 1 though (which already had things like properties and reflection - this is how the form designer worked) in 1995.
Of course i wouldn't call those modern any more than i'd call structured programming elements like 'procedure' and 'while' modern in 1995 :-P.
"Beauty" it not a word I've ever heard associated with Java GUIs before. From browsing screenshots Swing looks to me like non-native 1990s clunkiness. Am I missing something?
How do you "bring in the IntelliJ IDE themes" in a Swing application? The default theme [1] is distinctly lacking in beauty – not because it's not modern, or because it doesn't have animations, or because it's not native, but because of things like (for example):
1. the inconsistent padding around the focus rectangle (which even touches the outer border on one side!) on that toolbar button to the left in the screenshot,
2. that whoever redesigned the Metal theme some years ago decided to make the selected tab visually connect to the content by using the same background color (good idea, by itself) but apparently didn't notice that every application wraps the content in a widget that draws its own background, resulting in what you see on the screenshot: the tab color continuing for a few pixels into the content and then awkwardly bumping up against the content's background without a border.
Also, IntelliJ IDEA has to implement its own menu bar because Swing's built-in one can't do submenus properly.
I don' fully agree, only because I was rather on the other side of the fence with Delphi/C++ Builder. :)
I always considered .NET a step backwards, versus doing something similar to what Borland was doing with Delphi/C++ Builder, meaning C# and VC++ should have provided better tooling based on COM, and then follow up with VB7.
Ironically, when they tried to actually do that, with WinRT, they messed up the whole execution.
VB6 was the last "real" VB program before .NET obsoleted it.
I used it for decades when I was young, and I have never again used anything that was as good, as simple, as precise and as feature-complete. Debugging in VB6 was incredible. An incredible feat that I'm not sure has been repeated since? Perhaps the debugging capabilities of MSVC has caught up these days, in which case, kudos to them.
Maybe something exists today in the form of webdev? I wouldn't know as I'm stuck in the deep-end (backend).
I have used .NET the last few years. I made a full desktop application for someone, and I also wrote a map/level editor for a game in it. I have to say that I like C# a lot, but I don't like the editor, I don't like the graphical construction source file, because it's so easy to break your GUI. And I also hated the fact that drawing was slow on .NET no matter how hard I tried to make it fast.
Dolphin Smalltalk was fantastic for this and produced comprehensible, maintainable code with beautiful GUIs. It is a shame that great products have to die because the mediocre ones catch on.
If I recall correctly, you could write new code during debugging sessions, move the pointer to it and run it. Very dynamic. We can now do some of these things in VS or other tools with .Net, however VB was much more powerful in this regard. I can only recall there being one statement that required a rebuild - was it CreateObject or similar?
You can do the same thing in many languages derived from LISP, but supporting all that runtime monkey patching requires having dynamic indirections everywhere which add a ton of overhead.
Delphi 8 could have eaten then whole native Windows pie if they hadn't tried to chase Microsoft into the .Net world. It wasn't always pretty but it was so easy to throw together business apps that got the job done.
It encouraged a load of professionals who, though talented in their own field, should never have been near an IDE, to "knock up" a quick GUI, hand it over to the dev team, and say "Here you go. Support this."
It was useful for more than that. We built most of our COM components in C++. As we started prototyping COM components in VB... and discovered they were only about 5% slower and very easy to crank out. It was a heretical discovery kept very quiet.
COM in C++ ... shudder. That interface was very nicely hidden in VB6. It could be done in C++ but getting the typing and interface correct was awful. That switching to vb6 to make com components was easier was my exp as well. That VARIANT struct they created was a nightmare to do correctly. Which you would use a lot if you thunked between VB6 and C++.
Similarly I reached for VB6 any time I needed to consume a COM component. Stunningly easy compared to the absolute nightmare of consuming COM in C++. There really was no better way to do it than VB6.
Python with pywin32 [1] was also, and still is, a pretty good way to work with COM APIs. There is a book on it [2] from twenty years ago that is still surprisingly applicable.
The alternative being that software was never written and the domain knowledge remained locked away. It needed to be treated like needs analysis. It never was.
> "knock up" a quick GUI, hand it over to the dev team, and say "Here you go. Support this."
Isn't a GUI mockup one of the best ways to come up with a consistent set of requirements for software? At least by making the mockup in VB rather than drawing it on paper, it can serve as a start for the actual GUI part of the program.
You're speaking as a pro software dev (presumably), and yes, VB was great for prototyping.
The people I'm referring to didn't realise that such esoteric things as "requirements" or "prototype GUIs" were a thing, and just handed over a ball of spaghetti for us to support.
Thing is it was never a prototype, always the end product. Had a lot of Access systems that were created by people in their roles that got widespread use then grandfathered into general dev support too. These were always horrible but too big to change.
There have a few times that I presented a VB6 prototype along with a price and had my prototype purchased on the spot. Sometimes when a client says "We need this software now", they really mean it.
My brother was studying Veterinary Science back in the day. As part of some lab work they had to do, they needed to look through a microscope and count some types of organisms they say in the microscope.
So he had this good idea of creating a simple application that would allow him to enter his data in the computer without having to move his eyes out of the microscope. He did this with a keyboard numpad and a quick VB6 prototype (which I finished the coding part for).
Those are the kind of great small programs that VB5/6 allowed people to do. And there were a lot of those small utilities all over the internet. No paywall, no ads, no subscriptions. I miss those days of creativity and sharing for the sake of it. Now the internet is all just SEO, ads and greed. What happened to kids/young Millenials and Zs?
VB was basically the MS response to Borland's Delphi, which had all this but better, plus Pascal was way more powerful and mature language than Basic.
That said, both Delphi and VB (and VC++ to some extent) were IMHO far superior tools for RAD building of GUI apps than any web-oriented tool that I've later seen. In web development we're still in Turbo Pascal and Quick Basic days, we've got good IDEs and helpers but you still have to write everything by hand.
>VB was basically the MS response to Borland's Delphi,
No, that wasn't the timeline. Visual Basic came out in 1991. Borland Delphi was +4 years later in 1995. (Borland Turbo Pascal for Windows was 1991 but Microsoft VB's internal product development codename "Thunder" was already started in 1990.)
And earlier than this, there was Apple's HyperCard in 1987 which I'm sure both the creators of VB and Delphi were familiar with. HyperCard had buttons and fields that you dragged onto a window to make an interface, and then by clicking on these widgets you had access to their properties and could write code to have them do something.
I couldn't make sense of that name, so I suggested "gizmo", which seemed fun and more descriptive. That name stuck - for a while. Microsoft later renamed them to "controls". How boring!
I also developed the "gizmo interface", which Microsoft renamed to VBX. (They were really not into fun names at the time.)
It has sometimes been said that Bill Gates was the one who insisted that VB have an extension interface like this. The truth is more subtle. We had the gizmo interface all along. It was obvious that we would need it for our own gizmos, and that we should allow other developers to build their own gizmos.
Apparently, the Microsoft team that turned Ruby+Basic into VB was going to keep the gizmo interface private and only let Microsoft developers use it, at least at first to save time on the schedule. Bill quite rightly saw the power of exposing the interface to outside developers and decided to make it part of the product - just as we had planned all along.
And I built the "event arrows" that Alan mentioned. He originally called an event a "flimsy" (a British term for "lightweight paper used especially for multiple copies"). I couldn't make sense of that name either, so we kicked it around and settled on "event".
This left a problem of what to name the act of sending an event from one gizmo to another. I was familiar with the term "trigger" from SQL, but that didn't seem quite right, and we were into fun names. But I couldn't think of one!
At the time, when I got frustrated with a coding or naming problem, I had a habit of firing rubber bands at my IBM Monochrome Display to shake up my thinking. (Don't try this with a modern flat panel.)
That didn't give me any ideas.
So I decided to fire up a doobie and see if that would help.
As I flicked my lighter and looked at the fire, it all came together:
Fire a rubber band. Fire up a doobie. Fire an event!
I was just a teenager around this time, in middle school or perhaps high school, and still in the early stages of programming (after moving on from the Commodore 64 and 6502 assembly), but -- even three decades later -- it's nice to finally have an answer to that one particular question that was asked so often and by so many all throughout those years:
> Just WTF were those Microsoft guys smoking when they designed this shit?
> I know why QT/GTK and various other GUI systems use a HTML-y grid layout, but for me personally, I always struggle to make nice looking, well laid out, functional GUIs with them.
There's a very intuitive drag-drop GUI designer for GTK+, namely Glade. Sadly, it was abandoned as GTK+ transitioned to 3.x and 4.x. So the only supported workflow now is laying out your GUI in code.
The intuitive "action-oriented" language should not be underestimated either. Though I assume it could be made idiomatic even in modern languages, by leveraging their support for the async programming model.
More like Gnome and RedHat. In the BSD-y world and people akin on GNU (Alpine, Hyperbola, Parabola...) people loves the CLI and some stuff like TCL/TK or even Perl/Tk / Perl/GTK2. And the tools work well and fast enough.
Glade had a lot of problems, and core Gnomes devs really recommended against it[1]. I think that dev for Cambalache didn't want to try to figure that out.
If I had to guess I would say: more fun to develop a new system without any legacy code maintenance (GTK4 is a significant change in API). The idea with the new tool is to decouple the toolkit too so it will be fundamentally more resilient to churn.
A tool that uses Electron like technology (Merengue) to display what are supposed to be native widgets, and without guarantee that its development is actually going to be supported, long term.
I agree, it was super useful.i also loved the way you could call any DLL function on the system, making it very useful as 'glue'
However it severely missed multi threading. You could make things semi -multithreaded by making sure everything was event-based but there were still so many calls that would lock the UI.
You could run stuff asynchronously using a hidden window. Basically you could use the full win32 API and use VB procedures as callbacks (e.g. as window procedures for your own window subclass). The book “Hardcore Visual Basic” explained how to do it: https://classicvb.net/hardweb/hardbook.htm
Since win32 requires customizing the main event loop to handle e.g. non-modal dialogs, doesn't running nested event loops all over the place (which diverts the messages away from the custom main loop) break things like that?
It is very sad that the idea of easy WYSIWYG GUI application development has pretty much disappeared since the 90s. It enabled so many things to happen that wouldn't have otherwise. Hypercard, VB, Delphi...
VB6 was the thing that got me so interested in development. I honestly miss it a ton. Everything now requires so much more to just make a simple app for something, and I'm on a Mac so it's even more of a pain.
BASIC was my first language and VB6 was shortly after my first intro to GUI programming. I tend to agree with all your points, but I've never been able to fully convince myself that VB6 was just objectively "good" or if it was a first skill/nostalgia effect.
I still think there is a really successful app ecosystem waiting to be built that is semantically similar to VB6 + Access but built with a more modern stack like SQLite + Electron + TypeScript.
> objectively "good" or if it was a first skill/nostalgia effect.
When you consider the mainstream alternatives back then, by the time you've got the message-loop boilerplate working... in VB6 you've already created a functioning form with a database connection.
But yeh, Delphi was much better than VB (like how turbo pascal was better than QBasic), however it was more of a niche environment used mostly by independent vendors making consumer apps.
You were almost writing full-fledged VB apps if you started with MS Access, made some forms and had a switchboard menu. A little VB Script and you were there.
Is there an API for Electron yet that doesn't require you to pass messages to the nodejs backend? I did not find Electron+Typescript (Ionic+Angular/React) to be very productive at all. On initially approaching it I expected to just be able to treat my local server (nodejs) like a remote one and keep my code the same for my desktop app and web app. No dice. Very disappointing.
I think Angular has a way to intercept http calls but you would need to build a translation layer. None of this is obvious to someone picking this up for the first time.
The whole paradigm is a hack that requires a very experienced dev to navigate.
You're not wrong - Electron has 2 processes per "app" (1 chromium 1 nodejs) that need to communicate w/ each other and they do that via the traditional network stack/local sockets.
That part won't change AFAICT, but you can imagine a reasonable abstraction over it as part of a "batteries included" ecosystem in which events from the UI (button press, keyboard capture, scroll event, etc) are mapped seemlessly via configuration to user-defined functions that happen to run within the nodejs process with an SDK that allows developers to interact back w/ the UI in a similar manner. Resulting in a developer experience very similar to what you got with VB6.
Mirrors how I felt about iOS development through the 2010s for the same reasons, with the exception that the language, Objective-C, was likely holding it back in a way Visual Basic did not.
I’ll always have an affinity for Objective-C but obviously a C-based language with pointers everywhere came with a learning curve. Swift could have solved this but the APIs were not stable at the time (I used it around 2.1) and the compiler sometimes would choke with somewhat hard to diagnose errors. It seems Interface Builder and Storyboards are getting replaced by SwiftUI these days (inspired by Elm/React).
I think I have the same experience; it was definitely a step up from what I've done most of my career (webapps), mainly because it was all integrated and unified. I didn't mind objective-C, we did run into tons of crashes due to e.g. http requests coming in for screens that were gone already, but that was a matter of sticking to some stricter coding standards.
But as another commenter mentioned, it declines with scale; this is why Facebook spent so much resources into trying to make webapps on mobile work, because their application size and compile times just got out of hand. It's possibly also a reason why they split off Messenger from the main app at some point.
I'm the opposite. Anything I create in a GUI builder is going to look like ass, with potentially misaligned widgets unless there's automatic widget alignment. And of course, things built in VB did not handle window resizing or different resolutions/DPI very well...
Now, Tcl/Tk... which lets me just code up a GUI declaratively, feed it to a REPL, and get results that look... less like ass... that's a JATO bottle for UI productivity that's unmatched by anything.
We had a class in college where we used VB.NET, and Visual Studio designer for GUI. It was a breeze, and most people had working applications up and running within days of class start.
End project was to build a control/monitoring application for an electric motor.
Sure, there were some hard limitations compared to "modern" GUI design tools, but for the domain (industrial machines), these things worked just fine.
> End project was to build a control/monitoring application for an electric motor
This is actually a funny use-case for .NET as anything low-level and hardware oriented tended to be harder to do without the libraries, which (if they existed) weren't .NET
Not sure what the hard limitations were that you refer to; VB.NET / C# where always the easiest way to get a windows GUI (WinForms) app running. For industrial computing solutions tended to use Windows CE and Windows XP with COM apps.
This is ages ago - but IIRC, we did it something like this
Motor - VFD - PLC - OPC server - OPC client
The .NET Application worked purely as a GUI read/write data from/to the PLC.
But of course there were other things involved, like database programming, API service, webdev. We made a very, very simple API in ASP.NET I think, and some website in PHP which would just plot the various motor values.
The client/server paradigm is the corpus calloscotomy (split brain surgery) of our industry.
Begetting ORMs, LINQ, ActiveRecord, chaotic mutant query language templating system of the week, and other well-intentioned but ultimately detrimental efforts. All being unwitting attempts to regain what was lost.
FWIW, I did a bunch of R:Base, dBase/FoxPro, Access, and FileMaker (ahem) projects, back in the day. Sadly never had an excuse to use Paradox in anger, which I understand was the pinnacle for "workgroup" apps (LAN-based, meaning shared access thru file locking).
Agreed. And now we also have edit and continue for .Net while debugging. Another thing, GUI libraries for Winforms like Devexpress are super rich and offer a lot out of the box.
I agree. I knew I wanted to start programming in 3rd grade and it was such an intuitive way for me to learn. It let me spin up cool shit without a ton of overhead. Now I have 2 kids and I'm wondering what will be the equivalent for them when they're a little older. It seems like there's a lot out there designed for kids but it all seems so rigid like program your character instead of make your own program.
Scratch is great for understanding a lot of the concepts like properties, branching and loops but IMO goes too far towards the visual side. I liked the paradigm of "perform the action on the object" then "write the code in the container" that gets created or linked. We didn't really have formal "user stories" back then but programming essentially walked you through the "when I ... then ..." process.
UnrealEd 1 was coded in Visual Basic. I was very surprised when heard about this. The core rendering part was probably done in another language though.
I owe significant portion of my Win32 dev skills to VB6. It allowed for working with the Win32 SDK by importing API calls from user32, kernel32, gdi32, etc.
When I was still in high school, I used to hack GUI projects and games in the evenings. The culmination of that was a full blown space shooter game using DirectX7 [0] (still runs on Linux) and a TCP/IP chat + canvas draw application that I had installed in the computer room at my school. Fun times.
Fun story about "field programming" VB6 as a young startup: Customer wanted pandora over the restaurant speakers, "No problemo, I got an aux to RCA in the car". Customer likes free music, now wants front entry intercom mic to talk to customers over stereo system. No problemo, Google VB6 volume mixer. One line of my LPT port sniffing code added, Boom! insert paper clip into a few pins on the LPT port and solder to 50ft. cable, then soldered to pads on freshly wall mounted mouse (IBM TWO BUTTON WHITE THING), so it can short the pins on LPT, mute WaveOut and unmute wall mounted microphone (ALSO WHITE THING WITH THAT CRT PIVOT MOUNT) on 50' aux extender. I think I only charged $40.00/hr for that kinda stuff back then...
I see a lot of people expressing love and nostalgia for like VB6 and stuff but to be honest... maybe it's me being younger and not having experienced VB during its prime, but when I got to work with VB6 and VB.NET it was a _nightmare_.
I can see that the tooling might've been great and all, but the language is seriously just horrible. And as for VB.NET, my experience was that the bearable parts were the ones it inherited from the .NET and C#. It might've been fine for prototypes, but at least IME prototypes never stay that, they get swamped with features and a few years down the line you have a Frankenstein's monster of badly thought out features struggling to interact with each other... except with VB, all of that is mixed in a soup of On Error Resume Next. I don't really see how anyone would put up with that in 2022
> I can see that the tooling might've been great and all, but the language is seriously just horrible.
The language wasn't that bad. Classes without inheritance -- that's the new hotness these days!
Since you lumped in VB.NET in there you're definitely past the prime era and oddly I agree that VB.NET is horrible while I still think VB, for the time, was perfectly reasonable. It certainly has less gotchas than JavaScript.
Admittedly most of my experience was in VB.NET, with a small caveat. The codebase I worked on (for around 3 years) was initially ported verbatim from an old VB6 + Access app, and it had the bare minimum amount of changes needed to make it work, so I feel like (and wrote the comment with the assumption that) at least the business logic part of said software was more VB6 than it was VB.NET. Barely no classes and 0 inheritance (the one good side), but also really dodgy imperative code with laughably brittle error handling (when it was there at all), wonky syntax (subjective), and an extremely loose approach with typing.
Considering that I spent (and still do spend) most of my afternoons with Haskell and F#, it was a bit of a shock and an experience that I don't remember fondly at all heh
Classic VB comes from an entirely different era. It's hard to express how bad programming languages/environments were in general at that time. From that perspective VB is pretty decent. But we're sorta blessed these days that there really aren't any terrible programming languages anymore. Although we're also cursed that an environment like VB for building applications isn't really possible anymore.
One thing I would correct is that VB does not have extremely loose typing. VB is strongly typed with one exception: the variant type that could hold any other type (kinda like "object" in Java/C# but implemented like a union).
And don't forget the lost battle that is to try to keep a clean git history in VB6 with words changing the leading letter from uppercase to lowercase and viceversa or all the form properties jumping around whenever you touch the preview of the GUI (ie. Switching to a different tab).
Adding all the words to the top of each file[0] and saving every file resolved it for me. Just need to pay attention to not change the casing when modifing/adding code.
One of VB's selling points was that you could call COM components written in C/C++, even if they weren't designed for VB. However, the opposite is also true. VB could create COM servers that could be used by any COM aware code. It was kind of gross integrating a VB component into a C/C++ application, but also kind of amazing that it worked.
I sold COM components written in VB6 as a relatively new grad, and still remember my first support issue for someone who was consuming in C++. It was stressful and the solution ugly but we got it working!
How is RAD Basic guaranteeing 100% VB6 compatibility _including_ COM components? You'd probably want a 32-bit Windows OS to execute that native code correctly. Are they doing some sort of emulation here or is it just completely not covered?
32bit COM should work fine in 64bit Windows since it can run 32bit software - even classic VB. Obviously that would require a 32bit runtime. For a 64bit runtime they'd need either a 64bit version or only able to load 32bit out of process COM servers. AFAIK most COM stuff for VB was in-process (e.g. ActiveX controls) so those might be a problem but perhaps some sort of "32bit-to-64bit" bridge (via a separate 32bit process that communicates with the 64bit runtime) would work for the most part.
I think a harder part would be libraries/COM/extensions/whatever that access/modify the VB6 runtime internals.
I loved how quickly VB6 applications started. Waiting for .NET applications to start felt like a huge step backward. In my first job out of college, I can pinpoint the exact moment when I won my boss' respect when I fixed a long-standing bug in a VB6 application. VB6 will always have a special place in my heart.
I still won't use it for the project, though. Anything that involves trying to get my personal info is an automatic "no". There's just no point me wasting my time. There's no end of programming languages out there, I'm not going to mess around with this one.
disclaimer: I'm not a shill for Fastmail, just a happy (family plan) user after Gmail did me the favor of changing pricing and having me look around for alternatives.
$10/month is surprisingly high for temp-mail.org's service. Fastmail is $3-5/month paying monthly, and that includes full regular email service plus (at the $5/month level) your own domains, and on top of that they offer the disposable email address service. It seems like temp-mail's only extra feature is accepting cryptocurrency.
That RB icon prominently featured in this page feels like the precise opposite of what something called “Rad Basic” should have. “Rad Basic” demands some X-TREME graphic choices IMHO.
I think I blame living through the nineties for this feeling.
I just keep imagining a neon green crocodile wearing a backwards baseball cap while surfing on a keyboard, with a big RB! on their shirt in a paint-splattery font.
Maybe a little hard to fit all that on a toolbar-scaled icon. Just RB! in paint-splat neon green would go a long way to increasing the RAD FACTOR though. :)
Apparently "RAD" is some old acronym that means "Rapid Application Development". I'd never seen it until a few years ago when I ran into Embarcadero RAD Builder.
I'd argue VB was worse because of it (and it's std lib) not being opensource at the time than because it was soooooo bad of a language... People cheer on HN for JS and PHP saying they are totally acceptable langs; then VB was (is) also totally acceptable.
But VB required a payment upfront and whenever you needed to upgrade tools. This is not how the world liked it: pretty much all mainstream langs have opensource tools/stdlib/ecosystems nowadays.
This project replaces proprietary with proprietary (as far as i can see); so to me it adds no value.
It was so much easier being a teenager back in the day and learning to code a desktop app from scratch in a few weekends. Then you open FrontPage and make a simple website for it.
Now it's black magic only approachable to $100/hr engineers.
I feel like the problem now is the overwhelming number of choices we have. If a new programmer wanted to write a desktop app for windows he would be directed to VB, web app Perl, or games Turbo Pascal. Sure there were plenty of other languages but the zeitgeist of the time made these decisions pretty easy. Even in small town libraries, there were books available on these environments and the book stores had tons of books.
Do you not think your own time is worth that much, if not more, given the mind-blowing amount of business value added by even the most horrible and unmaintainable pieces of software?
Or are you saying that only midwits charge $100/hr, and that real engineers can and should charge much more, so anyone charging $100/hr is probably a hack?
In the case of the former, here's an anecdote: when I was a baby junior, I was working on an in-house enterprise Windows Forms CRM application.
We had a pricing manager that had taught himself enough C# to be dangerous. The code that the guy wrote was such a disaster that it conjured unspeakable horrors from the void. But because he understood the business domain at a level far deeper than anyone on the dev team, he could crank out forms and custom reports that turned misaligned curly-braces into cold, hard cash faster than any of us could say "DAMMIT MARK, YOU BROKE THE BUILD AGAIN".
The lesson I took from that: turning ideas into code that creates business value isn't the hard part. The hard part is doing it in such a way that you don't create an unmaintainable mess that makes it impossible for the business to adapt to change so that it can continue to make money.
In the case of the latter: I think I need to charge more.
There are different use cases that demand different tools. For personal projects the simpler tools from before were totally fine but now they are longer accessible. I think that's a loss.
Management is aligned because this makes money. Programmers do deserve $100/hr for what they do, the problem is whether it's what's needed. It's the same situation with tax software. You never needed one before but the parasitic co-evolution of tax software and tax complexity pushing each other means now you need to pay and Intuit can be a blood sucker year after year.
Error handling was terrible in VB, evidenced by the number of production VB apps that panic when clicking the wrong button or typing the wrong letters. Going from knowing enough to prototype to professional quality development was very hard.
You could always tell a VB app. Controls don't line up, windows either prevent resizing or do so badly, lots of redraw flicker, varying visual styles, and crashes on seemingly benign user input.
Database operations are often performed with no expectation of failure, the network is assumed to never have a problem, security policy is inconsistent, etc.
Perhaps some blame can be laid at the learning materials that emphasize the happy path and treat errors as a separate subject.
> You could always tell a VB app. Controls don't line up, windows either prevent resizing or do so badly, lots of redraw flicker, varying visual styles, and crashes on seemingly benign user input.
You are describing 1998 VB as much as 2022 html+javascript
With the obvious joke (or sad fact) that VB6 apps used to run on, like, 64 MB RAM systems (or less, if you were targetting Windows CE and had that extended tooling in Visual Studio for it) - and today for your average Electron or whatever browser based "app" you need 4GB+ of RAM.
64 MB RAM, not unusual for a high end desktop/dev machine in the late 1990's, but...
VB6 (the last one) was 1998, same year as win98, which listed a 486+16M of ram as its system requirements. Which was a big step up from a W95 386 with 4M of ram. So one probably didn't want to run VB itself on those smaller machines, but the resulting apps definitely did, and those low end desktops were exactly what a lot of vb apps were running on.
Not sure how much you are joking, but all the "apps were better in the 90s" blog posts overlook the absurd flexibility web apps have gained over the years.
VB and its ilk were used to write apps that were used in a very specific way. Many times companies wrote apps not just their business use cases, but literally with the expectation of the hardware their users had in the office, the network they were on and who would be maintaining the machines. Ultra rigid user experiences, but still somehow were bug prone.
Today its like, oh yeah, a user had an issue, they were searching our million record database on their smart toaster, one of the table columns weren't aligned correctly and it was slow to load.
Can't tell if you're joking or not, but this is hilarious regardless.
I believe a more serious answer would be: You could easily trap the error number and make it pop up in a MsgBox, then decide what to do with each type of error. Complex objects or functions would often each need their own custom error handling code, but it wasn't hard to do.
Not hard to do, just hard to do well. You have On Error GoTo and On Error Resume Next. There is no indication that any particular statement will have an error. Even if it is obviously something that could error, you don't necessarily know what kind of error.
The evidence shows that most writers of VB apps neither predicted errors nor found these error situations in testing.
The MsgBox is there purely for debugging purposes, you take that line out before the software is put in front of users. A single object or function can generate multiple error numbers at different points & in different situations-- ideally you trap and handle them all (in varying ways depending on the type of error) during the debugging phase.
I once saw a function in VB that had "ON ERROR RESUME NEXT" as the first statement and the code didn't look quite right. After removing on-error-resume-next, every line of the function threw an error. Someone had cut and pasted some code from a book on Access 97.
You do end up with some interesting approaches to error handling with that, e.g. from a sprite editor[0] i wrote a few years ago in VB5 (later ported to VB6) for fun:
Private Sub cmdOk_Click()
On Error Resume Next
WInt = 0
HInt = 0
WInt = CInt(txtWidth.Text)
HInt = CInt(txtHeight.Text)
If CStr(WInt) <> txtWidth.Text Or CStr(HInt) <> txtHeight.Text Then
MsgBox "Invalid numeric values for the dimensions"
txtWidth.SetFocus
Exit Sub
End If
Tag = vbOK
Hide
End Sub
This basically asks for a width and height but the entry boxes are text so anything could be entered there. CInt tries to convert text to integer and if that fails it errors out. With 'On Error Resume Next' it moves on to the next if that fails instead of producing an error and WInt or HInt would remain whatever it was. Since they're initialized to 0 there are always some valid integers in there. CStr would convert the integer to string (0 if the string-to-integer failed) so that the assumption is that if the strings converted to integers and then converted back to strings weren't the same as the original strings there were some invalid characters in there.
(in hindsight i should have also checked for negatives values but eh whatever)
It compiles to native Win32. Does that mean it can also compile to a dll that you can call from other languages like you could with VB6 (and still can with VB.net).
I based yazz.com , a low code tool on Visual Basic 6. I never aimed for compatibility though, and made it a web app which was docker compatible instead
Yeah, the VB6 IDE stutters and crashes horribly on just about any Windows after XP and Microsoft support documents suggests to not run it on anything more recent. So that means VMs at this point and XP being out of support too that means VMs that are network isolated as best as possible.
Sure, the compiled apps still run fine, so at this point developer experience suffers a lot more compared to user experience and some users don't understand how much harder every day it is to work on VB6 codebases. (It's a bit of a horror hidden from users.)
The VB6 IDE predates a lot of modern code navigation tools.
The VB6 IDE predates common deployment of the mouse scroll wheel and scroll wheel support is provided by a cranky extension to the IDE that stutters awfully.
I repeat: Scroll wheel support is broken by default in VB6 and there's an extension you can find on the web to install (if you can malware scan it and get it across your network isolation boundary to your XP VM) and it's still awful. Imagine trying to read thousands of lines ancient code without scroll wheel support. Might as well be on papyrus scrolls.
The last version of git that supported XP is now pretty ancient and showing its age.
Good luck setting up an XP build agent for VB6 IDE CI. Which it never supported anyway (the IDE never had a good CLI build tool).
Developer experience of maintaining VB6 IDE apps in 2022 is pretty horrible and morale destroying.
How does the IDE run under Wine? It might have better support for 9x/XP quirks than even the strictest "compatibility modes" in later versions of Windows,
At this point it's maybe not worth the effort to find out. A related problem is that the IDE and most VB6 controls and apps are awful about littering all of their settings in the Registry (where it doesn't belong) or equally hard to find spots. Most of the VMs I've seen you can't even rebuild at this point: they were lifted and shifted from some distant past developer's machine and nobody anymore has the raw license codes or files to unlock the various third party components (and some of those component companies no longer exist, so good luck).
I imagine that's a problem many projects would face trying to use the RAD Basic IDE, too and I don't think it's possible for it to be "no migration", because there will be components that won't work, won't relicense, etc.
They seem to want to "evolve" the language (there's a mention of wanting to add things like try... catch while maintaining compatibility).
Unfortunately the biggest challenge will be third party components. I work with clients who want to migrate VB6 on a daily basis and I don't remember the last time I saw an application without multiple third party libraries.
Many of these can no longer be installed in new versions of Windows and so clients are stuck on Windows XP/7 (Even though you can have VB6 installed on W11).
Each one carrying the risk of onboarding your PC into some miscreant's Command & Control system, or just plain encrypting your disks and making your life a misery. Good luck.
I wouldn't hold my breath. The original VB6 was chock-full of COM+ and lots of Windows specific stuff. I would rather attempt to migrate VB6 projects to Gambas (http://gambas.sourceforge.net/en/main.html) which is a modern FOSS take on (Visual) Basic. It's well maintained and runs pretty much everywhere.
Last time i checked Gambas it was completely different from what VB6 was with the only similar things being having a vaguely BASIC-ish language and a form designer. If someone had a VB6 project that wanted to move it away from VB6 and didn't mind making a ton of changes to it, they'd most likely already be on VB.NET many years ago.
I’ve been a happy user of Xojo (formally RealBasic) for about 20 years. It’s really powerful and free to use when getting started. I really like the all-in-one IDE and the ability to cross compile for macOS, Windows and Linux. Their desktop support is pretty good. Their iOS and web support not such much however.
I think it’s a shame they are not more well known
VBX controls were the thing that most closely fulfilled the promise of object-oriented programming: "off-the-shelf components that can be used to bolt an application together."
Then there was WordBasic, a Word-specific implementation of Visual Basic that really kicked ass. You could build full applications in the word processor, to do tons of things we take for granted today.
I know that many people are going to say I'm wrong and that VB6 was a cancer, but hear me out:
o Drag and drop GUI designer
o action oriented language
o surprisingly advanced integrated IDE
o It was easy, simple and reasonably fun to learn
I know why QT/GTK and various other GUI systems use a HTML-y grid layout, but for me personally, I always struggle to make nice looking, well laid out, functional GUIs with them.
just give me drag and drop, and ideally a python backend