Still to this day, nothing has lived up to the hype that was actually delivered by VB5 and VB6. Insane productivity.
I remember how quickly you can put together apps and forms using VB6 + visual designer. But security/permissions were mostly based on your Windows account user. I remember an ERP software that hardcoded the MySQL connection string with a god-mode user+password in a config file and relied on Windows permissions that only the ERP software itself (written in Delphi) could open it. User permissions were then encoded in that DB. Basically, one disassembly of the machine and extracting the config file from the harddrive would have allowed you full access to the db.
Today, we use service layers (REST & Co.) to ensure permissions and access - something that would be equally complex when using VB/Lazarus today.
People seem to say this a lot but I don't really understand it, because if you use c# with winforms in visual studio it's basically the same thing but better.
Visual Basic had its warts. C# is a better language from an academic perspective. But VB filled a niche that nothing else has come close to: it made desktop application software writing ridiculously quick and easy. While still being maintainable, readable, and fun.
Electron is probably the closest thing we have to that in the desktop world these days but somehow that performs even worse than VB6 did. Python or Go is probably the most analogous, if you think about command line programs.
Not actually true. I just created a new C# Windows Forms application in VS, dragged a button onto a form, double clicked and it took me right to the event handler ready for me to do something. There's no additional boilerplate or ceremony required.
Now sure there may be a whole bunch of code sitting in the "Form1.Designer.cs" partial class, but that's for the designer to manage, not you. And VB had this as well but the VB environment hid this until you went looking for it.
Writing Windows Forms apps in C#/VS2019 is as easy as it was back in the VB5/6 days. I say this as a former VB4/5/6 (and, cough, ahem, MS Access) user knocking out all sorts of stuff back in the 90's.
I’ve written sizeable software in both VB6 and C# (both professionally too) and yes, what I said is true about C# being a more verbose language. This isn’t intended as a criticism of C# either. It’s just a natural side effect of C# giving the developers more control.
Plus there’s also a C vs ALGOL type argument with regards to which is easier for a newbie to read and write. C# might produce highly readable code to those already familiar with C-syntax but VB6 is ostensibly executable pseudocode. That alone counts for a lot when talking about the accessibility of programming languages.
Clearly, but that wasn't my point. C# isn't a more verbose language, if anything it's more concise. My point was to refute your assertion that "your average C# program requires writing a hell of a lot more boilerplate code than your average VB6 program"...which isn't true.
The C vs ALGOL type argument doesn't really stand up for me. I have junior devs on my team who've arrived straight out of bootcamps, college, self-taught etc with a broad spectrum of shallow language skills (PHP, VB, VBA/Script, Java, Javascript), and none of them have trouble dropping into C# world when they've never used it before. C# isn't any more difficult to learn than VB or PHP. Getting up to speed with the .NET framework is a much larger challenge for them than picking up C#.
But FYI, VB6 isn’t .NET. You might be thinking of VB.NET. And if you were, your arguments would be correct. VB.NET is an utterly pointless language. But VB6 is a different beast entirely (and predates .NET by several years)
In the 90's I was neck deep in the land of COM/DCOM and CORBA. Our proof of the pudding, for the stuff we were building to talk to CORBA endpoints, was whether our VB5/6 apps could consume our bridge libraries and start passing sane data backwards and forwards with some janky J2EE horror show. And then we did the same with .NET1 (beta) via COM Interop to those libs etc etc. This is why I know the subject matter well, even if it is 20+ years ago.
Anyhoo, that's my appeal to authority, but I'll agree to disagree.
As to the “use case”, it still seems like a nice interpreted language for tiny computers based on microcontrollers and for embedded platforms in general.