Hacker News Reader

Hacker News

Comment by KaiserPro | Hacker News Reader

Full thread

KaiserPro

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

View on HN

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.

> 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.

"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)

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.

For me boilerplate names is an issue for whatever object orientated language you choose, unless you correct it in the dev cycle.

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].

[0] http://boa-constructor.sourceforge.net/Screenshots/

[1] https://www.lazarus-ide.org/

[2] https://www.youtube.com/watch?v=_3JgeIUo1X0

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.

VB.net was just awful. Only existed for a migration path, but the learning curve from VB6->VB.net is roughly the same as going to C#.

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.

Can you be more specific on the 2nd paragraph for someone ignorant like myself?

You can start here for a complete picture,

https://arstechnica.com/features/2012/10/windows-8-and-winrt...

You're right, WinRT should have been much sooner.

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.

The cross-platform story is still half hearted, as many tools are VS only, and who knows if they ever going to land on VSCode or VS4 Mac.

Also see MAUI versus Swing/Qt, one needs to go for Uno/Avalonia instead.

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.

Yeah IIRC there was a tool that would produce an AST that would generate C#, VB.Net and J#. It was used for writing examples.

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.

Microsoft does not develop VB.NET further.

Isn't the Roslyn compiler open source? It might be possible to maintain a fork and bring the language to parity with upcoming C#/.NET features.

They do, but not adding features to please us language geeks, rather what makes sense to interop with .NET libraries, CLS compliant.

Roslyn for VB.NET still gets more love than F# across .NET workloads.

Now it is true that they could rename CLR into C# Language Runtime, given the extent of effort that C# gets, versus VB.NET, F# and C++/CLI.

They share the same IL so you can go VB.NET <=> Byte Code <=> C#, or any .Net language. C# diverged in terms of features though.

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.

You should check out Rebol. You can do Tetris in like half a page of code.

*Idly checks out where it's at*

Last modified March 2014: https://github.com/rebol/rebol

And that's still just REBOL/Core, not REBOL/View.

It seems there is a very active fork : https://github.com/metaeducation/ren-c

The merge request will be a little challenging if someone dares to try : "This branch is 6513 commits ahead, 14 commits behind rebolsource/r3:master"

http://rebol.com/pre-view.html

This is all I was trying to convey. Yes, it's not getting as much love and care as it deserves.

Back in the 90s fresh out of college I remember writing routines to validate phone numbers and email addresses and stuff like that in VisualBasic.

Yeah, I didn't know about regular expressions at the time.... (facepalm) ...I was really just writing these things in straight up VB.

I'm not knocking what you were doing; I'm sure you had the sense to use regex or something. I did not. lol

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.

"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?

Yes, the authors of those applications failed to read books like Filthy Rich Clients.

https://www.amazon.com/Filthy-Rich-Clients-Developing-Applic...

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.

> Also, modern Free Pascal has OOP classes and methods if you like these.

The predecessors of Free Pascal had those since the 1980s, it isn't particularly a “modern Free Pascal” innovation.

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.

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.

[1] https://upload.wikimedia.org/wikipedia/commons/c/cc/Gui-widg...

I was the same, but then landed on Jupyter Notebook and the various ways to generate a (passable) GUI out of notebooks. Then I was happy again...

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.

For the Web have a look at OutSystems for example, it doesn't come as free beer though.

Debugging in .NET is just as it used to be on VB6, not sure what you would still be missing from those days.

As for breaking the GUI, it wasn't as if frm files were foolproof.

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.

VS has been offering that since at least 2015 version, and improving on it since then.

Indeed, it's come along way and I'm not knocking it.

Point is thought this was there out the box with VB.

Agreed, at least they eventually added it back, even the Me like objects.

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.

Seems to still be kicking around: https://github.com/dolphinsmalltalk/Dolphin

Apparently last modified 8 days ago, with a history of infrequent but steady commits.

Caveat: Unfortunately only talks about Windows.

For web dev, there is https://anvil.works which has a similar dev UX to VB6.

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 was almost too good.

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."

... in my experience.

> "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.

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++.

In case you miss doing it, the new C++/WinRT is hardly any better.

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.

[1] https://github.com/mhammond/pywin32/

[2] https://www.amazon.com/Python-Programming-Win32-Windows-Prog...

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.

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.)

Visual Basic (especially the GUI forms IDE paradigm and VBX components) was built on earlier ideas in 1988 by Alan Cooper : https://en.wikipedia.org/wiki/Alan_Cooper#Visual_Basic

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.

This brings back fond memories. The wiki page does have a few inaccuracies. Here is a more detailed article from Alan himself:

https://onezero.medium.com/my-one-phrase-resum%C3%A9-98776ef...

(Try an incognito window if Medium blocks you.)

That article has a few inaccuracies too, but as the events were over 30 years ago, this can be forgiven.

Read Alan's article and then come back for this followup.

Alan mentioned the "gizmos". He actually originally called them "waldos", named after these:

https://en.wikipedia.org/wiki/Remote_manipulator

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!

AMA, and I will see if I can remember...

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?

<g>

> 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.

There is some work going into a new RAD tool that will support 3 and 4. https://gitlab.gnome.org/jpu/cambalache

The Linux desktop's CADT syndrome strikes again. Why not just pick up maintenance of Glade itself? Why do we get this constant churn?

>Linux

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.

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.

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.

1. https://blogs.gnome.org/christopherdavis/2020/11/19/glade-no...

Writing XML by hand to provide it to GtkBuilder is so much better. /s

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’d just pepper Doevents() everywhere and it almost seemed multithreaded.

I have forgotten that trick. Good ol' times. :)

I did, but many operations would still lock. Database operations in particular.

But yeah DoEvents ftw.

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?

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

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...

At least there's still Lazarus.

Delphi still exists and they recently added Linux support.

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.

    When you consider the mainstream alternatives back then

What were the mainstream alternatives?

Folks always seemed to rave about Delphi. That seemed like the "grown up", "better" version of VB, though I never used it.

MFC, or plain C/C++ win32.

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.

Niche where? It was everywhere in Europe.

There is a reason why we still have Delphi conferences over here.

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.

Maybe I'm missing something.

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.

> just give me drag and drop

`designer` does this. Instead of assuming Qt doesn't come with a RAD drag & drop, you could have spend two minutes to verify.

> python backend

https://doc.qt.io/qt-6/designer-using-a-ui-file-python.html

The first sentence of your message is helpful and appropriate. The second sentence is unnecessary and rude.

Relevant: https://xkcd.com/1053/

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.

And the UI elements were all proper Win32 UI controls. I learned to program on VB6, and almost peed my pants when I got ownerdraw menus to work.

> pinnacle of GUI design/rapid prototyping

Ditto database work.

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.

Famously described by Ted Neward's "Vietnam of Computer Science" rant. http://blogs.tedneward.com/post/the-vietnam-of-computer-scie... Though Neward somehow avoids identifying the root cause (client/server).

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).

Visual J++

All the good VB6 parts, plus a better language for any code needed.

Minus AOT compilation, though.

I think Windows Forms (C#/VB.NET) is still as easy.

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.

MFC is still around as well. I've been using it for 25 years now. Its drag-n-drop GUI builder is similar to the one in VB6.

And as surprisingly as it may seem, its tooling in Visual Studio is still way better than C++/WinRT after 5 years being pushed as the "future".

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 rather VBish in that you can endow "characters" with their own behavior and have them "react" to asynchronous events.

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.

Typing text is a nuisance at a young age. Visual interaction makes sense as a starting point.

It was great for rapid prototyping. the problem was when people then shipped those prototypes to billions of users. :P

Why are there no visual development tools (drag n drop) for web? Or are there?

Yes I built one at yazz.com

Elementor https://elementor.com/

https://github.com/elementor/elementor

OutSytems, one of the best out there.

https://www.outsystems.com/p/modern-development/

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.

VB4->VB6 was the golden age of GUI development.

This, but on Linux, would change the world.

Reply on news.ycombinator.com