I loved VB6. Of all the languages and IDE's I've ever used, I've never been more efficient in any other one.
As long as MS doesn't break my workarounds to run that old IDE or its EXE's, I'm happy. VB.NET was a great stepping stone, but after switching to C# I never looked back. The only thing I miss is global functions that don't need a class qualifier in front of them. And I still find the Edit-and-Continue debugging experience in C# hit-or-miss.
I used to think this too, but everything you can do in VB6 you can do in powershell, and do it better. Try/Catch, windows forms.. literally anything you can think of.
You can even mix powershell and C# together in the same script.
Once I realized I had a better version of everything I wanted, it became my new favorite.
Quickly and easily design and make a GUI program with n real training?
VB6 got me into programming as a kid.
I mostly use python for stats stuff. I sorta understand how to run up a GUI using tkinter, but it seems like a huge pain in the ass.
I'm sure Visual Studio offers the ability to do whatever VB6 could with a GUI, but it isn't obvious how to get there.
VB6 was one nice thing - build 'a program' as you understand them in Windows. Why the fuck is it so hard nowadays? VS isn't intuitive - it's a firehouse of information and I feel like you need training to use it. That is a bummer.
I just want to Lego-assemble a cute GUI-based program that I can make into a binary and email my wife to use. But I need to dedicate 70GB and two weeks of study to get there, I guess.
>but everything you can do in VB6 you can do in powershell
Excel modules? OK not quite exactly the same but close.
I wrote a finite capacity planner system for a factory a fair few years ago in Excel to replace a huge number of Lotus 1-2-3 thingies with a vast amount of copy n paste from text screens and random sheets and what not.
I started with an automated forecast. We used an (memory may be fading) exponential fit which worked best using previous four weeks. eg last four Mondays would generate next Monday's demand.
The forecast could be tweaked by Planning at any time (aaaaiiiieee - Christmas!) The forecast was then fed into prep, make, bake, wrap and then dispatch. Between each process there is a stock holding. This is food so there are quite a few constraints on time, that's why we are making to forecast and not order. The customer will generally order your forecast if you are good enough and that is the whole point in the supply chain to the multiples: you know better than they do what will sell of your product.
The forecast cranks through the processes and stock points and generates a basic plan. It shows what efficiency is needed from each machine and the amount of manning etc. Oh dear you've got a Rademacher running at 170% which is a bit unlikely (110% is fine because 100% does not mean what you think it does in this industry - its a rate that is easy to achieve and not the absolute max). Oh and that machine is due 10 hours maintenance. Crap. OK, Mel off of Planning: do your thing ... a few parameters are tweaked, some production is offloaded to another member of the group and a packet of Hobnob biscuits is dispatched to a factory 200 miles away. The amended plan is run back through the model to ensure it satisfies the inputs and then when that is OK it is fixed for now.
I have not given too many details here as to specifics. I used a huge number of vlookups and I had a lot of code that ran through tables looking for the word "End" to indicate the last row (but one).
I basically found that VB gave me enough logic and whatever to get the job done in a reasonably safe way but without getting in the way of the business logic. I could concentrate on getting the job done.
Nowadays I'm a Linux (Windows and NetWare (lol)) sysadmin who masquerades as a PHB or MD but I still have a fondness for VBA. I recall getting someone's neural network spreadsheet VBA monster working after the most unlikely helpdesk call ever.
Powershell is a command interpreter like bash at the end of the day, I say use the best tool for the task. I'd hate to do gui with powershell,vb6 let me build simple UI front ends, probably the simplest ever.
When it comes to classic VB (aka VB6) it isn't so much what you can do but how you do it. After all everything that was possible with VB6 was also possible with Visual C++.
The strength of VB6 was a simple and straightforward syntax and a great integrated GUI builder and IDE.
Powershell has none of that. The Powershell syntax is baroque due to the (necessary) compromise between command line syntax and scripting language and there is no IDE/GUI-builder.
Sure, Powershell is much more powerful in many ways, but that was not the draw to VB6 in the first place.
Mixing c# and power shell in the same script is amazing. You can load methods from DLLs on the command line as well. I had to do this when I didn’t have permission to run unregistered exes on a server I was debugging. Luckily the admins didn’t restrict powershell and I ran my main method from a script.
Back in the very old days I wrote Excel Apps in VBA. You could pull an entire range in as a 2d array and dump it back out the same way.
The debugging environment was better than any I have used since. You could drag the execution point anywhere, edit code in between steps, view everything. It was amazing.
> I loved VB6. Of all the languages and IDE's I've ever used, I've never been more efficient in any other one.
Other than the amount of work it would take, what's to keep someone from taking all of the specs and docs, and implementing a language compatible with VB6 and VB.NET?
But, ignoring that, almost any app of any complexity in VB6 land will rely on bugs, quirks, and implementation details. (Also, I was never clear if the binary format for editing forms was actually documented somewhere). Someone could implement their own VB6 parser, but it seems like a ton of work for a vanishing market.
All of that said, while typing this, a quick search revealed https://www.radbasic.dev/ , so maybe someone's trying. Well, it's a Kickstarter, so maybe someone just has an idea. Dunno.
Nothing, it is just that nobody bothered. There have been a bunch of classic-VB-like languages (even IBM made one with their 'Visual Age for Basic' - though they really missed the mark on the IDE side, but the language and features were very VB6-like), but pretty much all of them either get abandoned or miss the entire point of classic VB by focusing on one thing (usually the language) while ignoring another (usually the IDE or sometimes the fact that classic VB is almost a 'live' system and instead they put a clear C-like separation between editing and compilation)... or miss completely by doing all these things wrong. Assuming they do not die off before managing to make anything usable, of course.
For one thing, there was no VB6 language spec, and the docs were rather informal when it comes to syntax definition (which is very non-trivial - all the "special" functions etc).
Exactly! Behind all the churn of new newer newest rehashes of what a programming ecosystem could be hide real hard problems, and they mostly never get addressed.
Are you aware of "using static" in C#? Allows you to use any methods on a static class without qualification. Gives you the appearance of global functions, despite the class scoping.
The end of Visual Basic.NET, that is. "Classic" Visual Basic has been ended for a long time now.
(And VB.NET is much less of a loss -- it was never as popular as classic VB. Even when it first came out, it was clear that if you were a VB developer, Microsoft really wanted you to move to C#; VB.NET always felt like an afterthought, a fig leaf they could use to say they really weren't abandoning VB when they obviously were.)
For me, the switch to dot-net meant that continuing to upgrade past VB5/6 no longer held any particular advantage over switching to some other language altogether, not to mention possibly some other operating system as well. I ended up in the Python camp, where I reside today.
Edit: I should also mention that VB5/6 got me away from HyperCard. I loved the idea of being able to draw my GUI, and not having to screw around with writing my own event loop.
With VB, I liked that it was "object based," by which I mean that you could use objects provided by the tool without having to create them. This was a great way for me to ease my way into OOP. By the time I wrote my first object, I already understood what objects were useful for.
Exactly. The writing was on the wall all the way back in 2001. It’s basically been a 20-year-long transition, and one has to admire Microsoft’s dedication to their developer userbase in that area.
Definitely. I was a huge fan of VB6, spent thousands of hours writing all kinds of things. When I first heard of VB.NET, I was excited to see what new features were implemented, expecting something like VB4->VB5->VB6. Boy was I in for a surprise. It seemed more like C wrapped in VB syntax. I started looking to other languages at that point, but as some other posters said I never found anything quite able to match the rapid prototyping GUI and debugging features of the VB6 IDE.
I never did VB6 or VB.Net, but I've done VBscript with classic ASP and VBA in Excel. Glad I went with C# instead of VB.Net.
Not trashing VB, but C# was always more capable and fully featured than VB (VB couldnt even do unsigned integers, and I dont it can even now), and almost immediately more widely adopted in even .Net 1.0. Hell, C++ with COM was more capable (if not extremely annoying amd error prone). Of course VBscript and VBA share very similar syntaxes, but they're not the same languages or std object models/libraries, just maybe 95% similar.
I totally agree and felt that such that after I went through the pain of learning VB.NET, I felt rather silly when I took a look at C# and realized I had learned like 99% of the whole thing is just the .NET ecosystem, so picking up C# was pretty quick.
Did the same thing, but in my mind, 50% of knowing a language is muscle memory, you type without even thinking about it because there is zero doubt or ambiguity about the syntax, even anticipating the reaction of the IDE as you type.
That’s why when I switched from vb.net to c# (when microsoft announced they were deinvesting in it 2-3y ago), I stopped writing vb completely. It is hard to fit two languages in muscle memory (unless the syntax is pretty close).
IIS ASP and the Shell CScript/WScript hosts are just environments for the COM-based Active Scripting engine.
At the time it was very capable as lots of software titles opened themselves up to automation via COM - that's why you could have Classic ASP pages that invoked Office Excel to generate charts dynamically.
Unfortunately it was all a mess, but it was also something beautiful because it meant that a desktop/server OS was more than just a place where heterogenous applications could live: they could truly interact with each other regardless of their programming language or runtime platform.
That grand vision - itself an extension of OLE from the early 1990s - died down with the rise of .NET (this wasn't intentional - Microsoft just had a lot of reorgs around that time and COM was more-or-less feature-complete, and no-one was really using DCOM) - but with Windows 8 and the "WinRT" API I was hopeful that COM would be back and new ways of automating applications would come around, and that Microsoft would have a great system for non-programmer users wanting to build workflows like they can with Apple's macOS Automator and AppleScript.
This also ties-in with the do-as-little-work-as-necessary being done for VBA support in Microsoft's products. While we all wish Microsoft would allow modern JavaScript as a first-class COM automation language - the Office VBA runtime only supports its own VB6-dialect (the VBA language), and while Active Scripting supports JScript (a snapshot of JavaScript version 3 from 1999-2001) it doesn't support static typing nor is any of the tooling inside Office compatible at all. - so instead we have JavaScript, but only for "Office Apps" which don't offer anywhere near the same kind of integration or control over Office applications (or things like filesystem access) that VBA does. It's like it's 2008 again and everyone's excited about the new iPhone OS App Store and thinking about all the cool iPhone OS system extensions they'd add, like a Today screen or a camera app that can record video by using low-level camera hardware APIs - only to be discover Apple will only let-in apps using nerfed and siloed high-level APIs that take away all of the fun from extending an OS.
I loved VB. I don't think I've ever been as productive as I was in VB - I could literally knock together a complete desktop application in an afternoon.
It wasn't perfect. There were lots of problems with it. It would never win prizes in CS competitions. But man you could build shit with it fast.
100% this to a tee! In the mid to late aughts I knocked out soo many junky little desktop apps that scratched very specific business itches we had at work.
A couple hours work in VB saved non-technical people hundreds if not thousands of hours of repeated effort. Killing it is a mistake in my opinion, Even if I haven't touched Windows since 2010, VB.Net is the one wonderful thing it had going for it.
VB the _language_ obviously has its limitations and frustrations, but VB the _tool_ will be missed. It seems like every alternative mentioned here adds a lot of additional friction for writing simple, one-off utilities.
I don't always want to dink around with the Visual Studio installer to make sure the right version of the MSVC or .NET libraries are installed, or fiddle with code to get a GUI layout to look nice, etc.
Having the IDE, compiler and GUI designer in one big coherent monolith had its advantages.
That's kinda what a C# .NET winforms project is. The WYSIWYG editor is pretty easy and the basics are pretty well documented for all the premade widgets that I feel like anyone who just needs to make a one off util program won't have much trouble.
My first real job was on a .NET stack that was 1/2 VB.NET and 1/2 C# for legacy reasons. It was weird at first, but I mostly stopped noticing after a few months - the two were completely interoperable and they both compile down to the same .NET IL. In practice, coding in VB.NET was 99% the same as coding in C#, just with a slightly more verbose syntax. Not my favourite language, but much better than its dismal reputation would imply.
Not completely interoperable. At least initially (and as far as I'm aware ever). VB.Net never could understand the unsigned integral & char types. If you used unsigned types in C#, those members wouldn't be BCL compatible and at sufficient warning level, you had to annotate members with [BCLCompliant(false)] if my memory serves correctly.
There were other language constructs at the time that werent 1:1 parity at v1.0, but in nearly 20 years time, I forget.
Well another one is case insensitivity. If you have a property and a function in C# which name only differs by casing, will be a problem to consume in VB. Not that it is good design in the first place.
"There’s something deeply right about how list indexing and function application are the same operation". That is a quote from a recent submission about K (https://news.ycombinator.com/item?id=22504106), and that is a perfect example of how I usually get VB nostalgia attacks: somebody talks about a thing in other language they consider amazing implying that that thing is unique for that language despite it was implemented in VB and earlier. Sometimes that somebody can ever be Microsoft as they brag about adding more features into C#'s switch statement with increasingly ugly syntax in every new version completely ignoring that they did them better in VB.
VB uses the same syntax for array indexing and subroutine invocation, but they aren't the same operation; you can't define a parameter that is either an array or a subroutine. So the extra expressive power that this unification provides in K is absent in VB.
Parentheses for array indexing dates all the way back to the original Dartmouth BASIC, and from there to the very first FORTRAN. It's one of the oldest pieces of PL syntax still around in its original meaning.
I'm pretty sure that there are a few languages where array indexing is basically calling a function that returns a reference to the cell you're accessing.
Since C# 1.0, any type can have an indexer property defined that can accept any parameter types and can can return anything - though it wasn't until C# 7.0 that we could return a first-class reference to a value, including array members (`public ref int this[int idx] => ref this.someArray[idx]`).
VB classic was my first programming language since it was so easy to spit out GUI programs that looked like any other program you use.
I'm afraid current popular languages like python and javascript do not offer that "instant gratification" and is scaring beginners. With only terminal or webpage output, they might get the feeling that what they're coding is far from what "pros" use to write desktop software that is all around them.
Csharp is great, I use it everyday, but is not a real successor. First, it is a massive install which can be an issue with others just starting out. The few things I dislike with Csharp are that executables are dependent on the dot net (or mono) framework and are not native, i.e. far easier to reverse engineer.
Lazarus/Delphi might be the next best things to a classic VB experience. There are efforts to make something similar for Freebasic what Lazarus is for Free Pascal. But they are nowhere close, and the next best alternatives are not free.
I have no right to complain, and I fully understand, but I could be happier if Gambas had native Windows support.
I started programming in VB6 so this is a little sad, but I'm actually surprised it has made it this far. I see C# everywhere but can't remember the last time someone told me they were using VB.
Readit News
As long as MS doesn't break my workarounds to run that old IDE or its EXE's, I'm happy. VB.NET was a great stepping stone, but after switching to C# I never looked back. The only thing I miss is global functions that don't need a class qualifier in front of them. And I still find the Edit-and-Continue debugging experience in C# hit-or-miss.
You can even mix powershell and C# together in the same script.
Once I realized I had a better version of everything I wanted, it became my new favorite.
VB6 got me into programming as a kid.
I mostly use python for stats stuff. I sorta understand how to run up a GUI using tkinter, but it seems like a huge pain in the ass.
I'm sure Visual Studio offers the ability to do whatever VB6 could with a GUI, but it isn't obvious how to get there.
VB6 was one nice thing - build 'a program' as you understand them in Windows. Why the fuck is it so hard nowadays? VS isn't intuitive - it's a firehouse of information and I feel like you need training to use it. That is a bummer.
I just want to Lego-assemble a cute GUI-based program that I can make into a binary and email my wife to use. But I need to dedicate 70GB and two weeks of study to get there, I guess.
Excel modules? OK not quite exactly the same but close.
I wrote a finite capacity planner system for a factory a fair few years ago in Excel to replace a huge number of Lotus 1-2-3 thingies with a vast amount of copy n paste from text screens and random sheets and what not.
I started with an automated forecast. We used an (memory may be fading) exponential fit which worked best using previous four weeks. eg last four Mondays would generate next Monday's demand.
The forecast could be tweaked by Planning at any time (aaaaiiiieee - Christmas!) The forecast was then fed into prep, make, bake, wrap and then dispatch. Between each process there is a stock holding. This is food so there are quite a few constraints on time, that's why we are making to forecast and not order. The customer will generally order your forecast if you are good enough and that is the whole point in the supply chain to the multiples: you know better than they do what will sell of your product.
The forecast cranks through the processes and stock points and generates a basic plan. It shows what efficiency is needed from each machine and the amount of manning etc. Oh dear you've got a Rademacher running at 170% which is a bit unlikely (110% is fine because 100% does not mean what you think it does in this industry - its a rate that is easy to achieve and not the absolute max). Oh and that machine is due 10 hours maintenance. Crap. OK, Mel off of Planning: do your thing ... a few parameters are tweaked, some production is offloaded to another member of the group and a packet of Hobnob biscuits is dispatched to a factory 200 miles away. The amended plan is run back through the model to ensure it satisfies the inputs and then when that is OK it is fixed for now.
I have not given too many details here as to specifics. I used a huge number of vlookups and I had a lot of code that ran through tables looking for the word "End" to indicate the last row (but one).
I basically found that VB gave me enough logic and whatever to get the job done in a reasonably safe way but without getting in the way of the business logic. I could concentrate on getting the job done.
Nowadays I'm a Linux (Windows and NetWare (lol)) sysadmin who masquerades as a PHB or MD but I still have a fondness for VBA. I recall getting someone's neural network spreadsheet VBA monster working after the most unlikely helpdesk call ever.
Good times.
The strength of VB6 was a simple and straightforward syntax and a great integrated GUI builder and IDE.
Powershell has none of that. The Powershell syntax is baroque due to the (necessary) compromise between command line syntax and scripting language and there is no IDE/GUI-builder.
Sure, Powershell is much more powerful in many ways, but that was not the draw to VB6 in the first place.
What feature are you referring to?
Deleted Comment
The debugging environment was better than any I have used since. You could drag the execution point anywhere, edit code in between steps, view everything. It was amazing.
IntelliJ is pretty good now, but not like that.
Other than the amount of work it would take, what's to keep someone from taking all of the specs and docs, and implementing a language compatible with VB6 and VB.NET?
But, ignoring that, almost any app of any complexity in VB6 land will rely on bugs, quirks, and implementation details. (Also, I was never clear if the binary format for editing forms was actually documented somewhere). Someone could implement their own VB6 parser, but it seems like a ton of work for a vanishing market.
All of that said, while typing this, a quick search revealed https://www.radbasic.dev/ , so maybe someone's trying. Well, it's a Kickstarter, so maybe someone just has an idea. Dunno.
https://www.xojo.com/index_xojo.php
Not open source but it looks quite interesting.
Deleted Comment
(And VB.NET is much less of a loss -- it was never as popular as classic VB. Even when it first came out, it was clear that if you were a VB developer, Microsoft really wanted you to move to C#; VB.NET always felt like an afterthought, a fig leaf they could use to say they really weren't abandoning VB when they obviously were.)
Edit: I should also mention that VB5/6 got me away from HyperCard. I loved the idea of being able to draw my GUI, and not having to screw around with writing my own event loop.
With VB, I liked that it was "object based," by which I mean that you could use objects provided by the tool without having to create them. This was a great way for me to ease my way into OOP. By the time I wrote my first object, I already understood what objects were useful for.
Not trashing VB, but C# was always more capable and fully featured than VB (VB couldnt even do unsigned integers, and I dont it can even now), and almost immediately more widely adopted in even .Net 1.0. Hell, C++ with COM was more capable (if not extremely annoying amd error prone). Of course VBscript and VBA share very similar syntaxes, but they're not the same languages or std object models/libraries, just maybe 95% similar.
That’s why when I switched from vb.net to c# (when microsoft announced they were deinvesting in it 2-3y ago), I stopped writing vb completely. It is hard to fit two languages in muscle memory (unless the syntax is pretty close).
Deleted Comment
It kinda still lives on in classic ASP. It will be supported indefinitely so far [1]
[1] https://support.microsoft.com/en-us/help/2669020/active-serv...
At the time it was very capable as lots of software titles opened themselves up to automation via COM - that's why you could have Classic ASP pages that invoked Office Excel to generate charts dynamically.
Unfortunately it was all a mess, but it was also something beautiful because it meant that a desktop/server OS was more than just a place where heterogenous applications could live: they could truly interact with each other regardless of their programming language or runtime platform.
That grand vision - itself an extension of OLE from the early 1990s - died down with the rise of .NET (this wasn't intentional - Microsoft just had a lot of reorgs around that time and COM was more-or-less feature-complete, and no-one was really using DCOM) - but with Windows 8 and the "WinRT" API I was hopeful that COM would be back and new ways of automating applications would come around, and that Microsoft would have a great system for non-programmer users wanting to build workflows like they can with Apple's macOS Automator and AppleScript.
This also ties-in with the do-as-little-work-as-necessary being done for VBA support in Microsoft's products. While we all wish Microsoft would allow modern JavaScript as a first-class COM automation language - the Office VBA runtime only supports its own VB6-dialect (the VBA language), and while Active Scripting supports JScript (a snapshot of JavaScript version 3 from 1999-2001) it doesn't support static typing nor is any of the tooling inside Office compatible at all. - so instead we have JavaScript, but only for "Office Apps" which don't offer anywhere near the same kind of integration or control over Office applications (or things like filesystem access) that VBA does. It's like it's 2008 again and everyone's excited about the new iPhone OS App Store and thinking about all the cool iPhone OS system extensions they'd add, like a Today screen or a camera app that can record video by using low-level camera hardware APIs - only to be discover Apple will only let-in apps using nerfed and siloed high-level APIs that take away all of the fun from extending an OS.
It wasn't perfect. There were lots of problems with it. It would never win prizes in CS competitions. But man you could build shit with it fast.
A couple hours work in VB saved non-technical people hundreds if not thousands of hours of repeated effort. Killing it is a mistake in my opinion, Even if I haven't touched Windows since 2010, VB.Net is the one wonderful thing it had going for it.
VB6 can call win APIs and C++ code for when some arcane functionality is needed.
I don't always want to dink around with the Visual Studio installer to make sure the right version of the MSVC or .NET libraries are installed, or fiddle with code to get a GUI layout to look nice, etc.
Having the IDE, compiler and GUI designer in one big coherent monolith had its advantages.
I sometimes miss VB.NET's XML Literals/Embedded Expressions feature. Back when virtually everything spoke XML, it was very nice to have first-class support for XML as a language feature. https://docs.microsoft.com/en-us/dotnet/visual-basic/program...
There were other language constructs at the time that werent 1:1 parity at v1.0, but in nearly 20 years time, I forget.
"There’s something deeply right about how list indexing and function application are the same operation". That is a quote from a recent submission about K (https://news.ycombinator.com/item?id=22504106), and that is a perfect example of how I usually get VB nostalgia attacks: somebody talks about a thing in other language they consider amazing implying that that thing is unique for that language despite it was implemented in VB and earlier. Sometimes that somebody can ever be Microsoft as they brag about adding more features into C#'s switch statement with increasingly ugly syntax in every new version completely ignoring that they did them better in VB.
I'm afraid current popular languages like python and javascript do not offer that "instant gratification" and is scaring beginners. With only terminal or webpage output, they might get the feeling that what they're coding is far from what "pros" use to write desktop software that is all around them.
Csharp is great, I use it everyday, but is not a real successor. First, it is a massive install which can be an issue with others just starting out. The few things I dislike with Csharp are that executables are dependent on the dot net (or mono) framework and are not native, i.e. far easier to reverse engineer.
Lazarus/Delphi might be the next best things to a classic VB experience. There are efforts to make something similar for Freebasic what Lazarus is for Free Pascal. But they are nowhere close, and the next best alternatives are not free.
I have no right to complain, and I fully understand, but I could be happier if Gambas had native Windows support.