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.
>>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.<<
Great question. And I agree with the sentiment.
My opinion for "why is it so hard today": it has to do with the way .NET evolved right after its birth. .NET was a response to Java by Microsoft. What Microsoft did in effect was attempt to smother the Java juggernaut by introducing their own Java with J++ (Anders' team) but only available on Windows (their attempt to prevent the allure of Java's platform independence).
By all accounts that attempt was an astounding achievement from Redmond. It boasted interactive tools to create GUI drag and drop features users were accustomed to in VB6 but glaringly missing in the Java world. This was with Visual Studio 97. Then the lawsuits with Sun came. The aftermath of the J++/Microsoft Java debacle was the beginning of .NET. A "Java" for Windows with attendant crazies of the Java world. This is the reason why it is hard. Java was "hard" compared to VB6, therefore .NET had to be hard in the same way.
All analogous complexities associated with the Java world: build tools, runtime versioning tools and intermediate code compilers etc were forever required, keeping this huge katamari ball of technical debt alive for over 20 years.
Now we have .NET Core. So we've just reset the clocks and in one swoop gone right back to 1998 with a new Microsoft Java but this time it is cross platform!
22 years of a meandering path that ends up right where we started!
> ...astounding achievement from Redmond. It boasted interactive tools to create GUI drag and drop features users were accustomed to in VB6 but glaringly missing in the Java world. This was with Visual Studio 97
Thay were not "glaringly missing in the Java world" in 1997 when Visual Studio was released. By that time at least these 2 IDEs with "drag and drop" were released and used already: Symantec Visual Café (a good one!), and a beta of IBM VisualAge (second part of 96). VisualAge came with specific ibm's understanding of drag and drop, however the Visual Café's experience was really similar to VB and much easier than J++ from what I remember. I tried all of them at the time including JBuilder and Sybase. JBuilder was my best for quite time.
Correct. I myself used "eclipse's" parent (Visual Age) in the early days but the point I was making was not so much that "drag and drop" was missing - it was just too cumbersome and difficult even in that! In VB6, it was trivial to get a form to look the way you wanted it to look. Gridbag layout on Java Swing maimed many, and those that got off the VB6 boat soon realised that Java land was much much harder even with their GUI drag and drop tools.
BTW, I used JBuilder extensively. What a topnotch tool from Borland. Pity they didn't survive the virulent competition during those IDE wars period. I still remember settling an argument with a colleague about his insistence to use the newly arrived Netbeans, while I fired up my JBuilder IDE (Yellow Porsche splash screen IIRC), created a gui, added jdbc data controls, coded a few lines and hit compile - ALL while his Netbeans was still loading with that dastardly progress bar.
(These comments have been much needed catharsis for me.)
From memory JBuilder did have issues with its GUI builder.
Code emitted JBuilder's tools was not isolated from other code that was written for the application. It was easy to add a line of code that would make the included builder tool to not show the resultant GUI correctly.
This was from JBuilder 9 and JBuilder 2006, other than that issue it was a really nice IDE to use.
In 96 there was also Xelfi which later became Netbeans.
The original version was an attempt at Delphi for Java and I liked it far better than Netbeans later, but I came from Delphi to Java so that makes sense.
Doing .NET and Java nowadays, started using Borland products with Turbo Basic, jumped into Turbo Pascal 3.0, all the way up to Delphi 1.0 and C++ Builder, before caving in to the MFC world back then.
Delphi club membership is only for those who possess a ruthless, deep and time-transcending sense of commitment to these two aspects of software development:
1."No bullshit" - stick to the fundamentals and don't waste time over-engineering, relying on complex builds, producing ambiguous compiles (ok, we're still fixing this), relying on bulky runtime architectures. Have straightforward source code. Native. Straight-talking. Quick-compiling. Hard-hitting. Because Shipping Matters(tm). Only thing that matters. Shipping. No bullshit.
2. "Fiercely independent mindset" - Members know that they must use the right tools for the right job, but members must also display a strong ability to not be swayed by what employers are hiring for. Latest shiny flavour of tech, framework, language, might look good on your CV but many times the conclusion for "What is the right tool for this job?" can still be answered: "Delphi". Stand your ground.
So, if you are a CV-oriented programmer, you will most likely not want to do Delphi. There is an indelible and horribly misinformed meme out there that there are no Delphi jobs or that Delphi is dead, is old, outdated and irrelevant in modern software architectures. I have seen this ageist misinformation come out as lame attempts to ridicule Delphi programmers (jealousy?), branding them luddites and dinosaurs. We never retaliate. Quiet stoicism is a prerequisite for club membership.
Finally, the Delphi club also has a new membership protocol: always buy them a beer. No matter whether they eventually get accepted in the hallowed halls of this quiet corner. :-)
Still delivering stuff on ASP.NET Framework 4.7.x, have delivered a couple of Forms/WPF projects during the last decade to lifetime science R&D labs, own all Delphi books from Packt, I guess it kind of qualifies for the membership pitch. :)
I doubt there any thing today that even come close to Delphi in terms of RAD. It is unfortunate that Software as an industry is even worst than fast fashion.
That is what happens when one stays with AWT, does everything on the main thread, and doesn't bother to read Java UI design books like Filthy Rich Clients, or integrate component libraries like JGoddies.
However I do agree Visual Basic and Delphi were much better, and if Java hadn't happened we wouldn't have lost 20 years playing around with VMs and dynamic languages, to finally start paying attention to AOT, value types on type safe languages.
I think Xojo was known as "RealBASIC" in the late 90s/early 00s and was really in the same spirit (but more cross platform) as VB6.
HyperCard occupies the same spot for me that VB6 seems to occupy for you. Today for stuff I'd have used that for in the 90s, I just stand up a quick little web app and text or email a link.
That's in no small part because nearly all of my wife's computing is done on an iThing and not on a computer that she could readily download and run something on. Unless I want to throw my cute GUI in an app store, it needs to be web-based now.
Eh. VB6 was paid too. IIRC it used to be on the order of $600 to get the standalone version.
I downloaded Xojo and kicked the tires. It was absolutely cool to see that an environment like this lives on. It really does feel like a successor to VB6.
Yeah VB got me into programming as well, there was a book literally called "programming for kids", it came with a copy of Visual Studio 6 and it was a few simple things like making a calculator, making a simple pong clone etc....that was the best thing as a 10 year old. Now I'm a professional C++ programmer, so....yeah, thanks VB! We'll miss you.
Oof. I hate powershell studio. It weirdly splits up the files and none of them are .ps1 and they obliterate all good standards and practices forcing you to leave arbitrary code in the project so that theres no way to know what pieces fit with what. Youd sh*t yourself if you saw how the Sapien community handles not blocking the rendering thread that their GUI forms run on (so it doesnt literally freeze up and crash).
Scratch is the easiest way to teach programming to kids in a visual way. Much easier than VB, you can start at a younger age, but you can’t make real apps. You can however make games and control devices like the microbit.
The progression from there is python for those who want to control devices, or web dev for those more drawn to the visual design part. A missing piece is something for making games that sits in the middle of scratch and C++/unity. I don’t know how kids make that transition.
No wonder so many programmers stick to boring business apps! ;-)
I got into coding qbasic (meh) & amiga (yeaaah) game engines in the 80s.
Currently teaching kids with Computercraft, to manipulate virtual worlds rather than boring spreadsheets.
IMO that sort of computer work will be obsolete by the time today’s kid are grown.
I’d probably avoid more than basic coding in general anymore and focus on math-y stuff. Just my take on where need will be, and discussing this with education researchers, and other thinkers.
I have a hard time believing we’ll carry as much code from the last couple decades as we had to from the previous few.
So much of it these days is web ui’s with a short shelf life relative to foundational code we shlepped forward in kernels, banking, and complex industry systems.
HTML/JavaScript. That has the shortest start-making-a-GUI story (plain JavaScript; React/Webpack/etc. absolutely do not have this level of accessibility).
> VB6 was one nice thing - build 'a program' as you understand them in Windows. Why the fuck is it so hard nowadays?
My takes is because it's not modular enough. Sure it's easy to plop this and that components here and there, add events, etc. However as requirement changing each pages / sections need to be changed as well. Not to mention portability to linux or mac. That and we're talking about db access, drivers, and security (in memory data sniffing / tepering).
Of course it doesn't applied to all kind of apps, but those who need constant changing are the one who pays Microsoft bills.
Same. My brother brought home an illegal copy of visual studio and I was hooked pretty much immediately. We had no internet at the time so I found myself using the MSDN knowledge base articles for potential explanations.
It really annoyed me that I couldn't get nice bitmaps in menus so I eventually learned about Ownerdraw. That changed my life. Having to hook into the wndproc and all the other windows api calls introduced me to C, and so I naturally started experimenting with C++. All without internet, stackoverflow or groups.
Books! I read one that was all about custom controls, must have been about 300 pages and at the end presented code that provided subclassed versions of all the MS Windows 3.1 controls with 3D effects.
It wasn't exactly sure randomness. I was registering for some band forum as an edgy teen and he was on CNN stroking Strom Thurmond's ego
It's wierd enough that any old niche forum friends I've lost touch with would recognize it...and I can't imagine anybody else would use it coincidentally. He's been a non-figure for years and years
Your curiosity demands more upvotes than I've got!
Yeah, I write a ferocious amount of PowerShell it's an amazingly bad language. I use it for its API, but its language design is a nightmare.
I'm not talking about its unorthodox syntax - that's the least of its problems. The language is hellishly inconsistent and has an inexcusable number of legacy issues for being so young.
And the quality of the standard library is poor. More and more often I find I have to drop down into .net commands to work around showstopper bugs in their PowerShell wrappers.
I don't find it ugly, just strange. It's optimized for interactive usage though from what I understand. I think of it mostly as calling .NET methods that all have named parameters:
myfunc -param1 this -param2 that
instead of:
myfunc(param1: this, param2: that);
I get the impression it's designed with the intent that you're supposed to type the dash, then hit Tab to get tab-completion in most cases. Same with the verb/noun syntax (I know I want to 'Get' something, so typing Get-<Tab> for the list of things is usually the thing to do). I do find it a bit difficult sometimes to think of an approprioate verb right off the top of my head (is it Get- or New- that I need?).
I'd also love to see the concept of proper namespaces in PowerShell; it seems really inconsistent right now (unless I've missed something). For example, type Show-Command and hit ENTER, then look at the different modules that are available. Some will express a 'namespace' by having it prepended to the noun (see for example, commands from the BitLocker module, their nouns all start with BitLocker) while others express no namespace at all (see for example commands from the 'Dism' module). For everyday use I've gone with the 'add the name to the noun' approach in my own scripts. That does mean I tend to use short namespace names though.
I've mentioned this in an older PowerShell-related thread here - MenuComplete is absolutely awesome and improves the PowerShell experience in the console. I actually think it should be the default. If you havent already, try these commands:
PowerShell is my full-time shell in Windows now (and it will be in Linux also when I get back into it); I rarely use CMD for anything and parsing text in bash just seems antiquated.
It isn't inevitable by any means, fish shell scripting is clean and pleasant.
I use fish as my command line, but I still write scripts in bash, even personal ones I only expect to use on my own machine. Just out of a vague sense that I might reuse it, or it might escape confinement, or something.
The decision to make the console output as the return value of a function alone almost destroys it for larger scripting projects. It’s a really bad decision and they could still fix it by adding some environment variable that disables this “feature” while staying compatible with old scripts.
It seems like it might make some kind of sense, since it doesn't output directly to the console but rather to a pipe. Bash functions sort of work the same way since they don't have complex return values (aside from exit codes) other than the function's output stream.
Yeah, keep in mind that the output is a fully-fledged object, it is not the text you see. The text is generated by the PowerShell host if the returned object makes it back there and the host is set up to present that object to the user that way.
Take the following in PowerShell:
ls | sort DateTime -d
ls returns an array of objects, sort then sorts the array by each object’s DateTime field (and here I’m asking it to sort in descending order with -d). The point is that sort isn’t depending on any text output, so it works with any array of objects regardless of the command that returned them.
The other cool thing this enables is auto-complete awareness in the shell. If I typed:
ls | sort <Tab>
then the shell knows what makes sense in auto-completion here as ls has an actual return type and in this case it will give me a list of available fields that I can sort on.
For those unfamiliar: ls and sort here are shortened aliases to more wordy verb-noun commands. These (as well as a large bunch of others) are given to you by default.
Possibly, though bash is from a much earlier time when shell scripting language design probably wasn’t a very well known topic and bash evolved more naturally from open source. Powershell is much more recent plus had much more complete control over the language to prevent the kind of syntax warts bash has. Even then I would still probably take bash over Powershell for scripting but that’s probably more because of familiarity than anything else.
The first release of bash was in 1989. Shell scripting was already a thing at that time. Csh and ksh were also around for roughly a decade at that time. I think you are confusing bash with sh with this kind of statement.
Is it widespread? I've never seen anyone else using powershell 'in the wild', admittedly for the last 3 years I've mainly worked alone, but I still see people using CMD scripts.
I usually get frustrated with it and bash out a quick cmdlet instead.
CMD is the worst language I ever saw. It's full of hacks for simplest tasks. The only reason I'm using it is for old systems where PS is not preinstalled.
I used PS to write small scripts and I actually like it. I'm more fluent with bash, but that's only because I used bash a lot. PowerShell feels more robust, no silly space-in-filename problems, no silly parsing of text output to access fields. May be it's ugly for big scripts, I don't know, for me it looked like a vastly superior version of shell.
I would love to learn why people think that power shell is ugly, especially comparing with bash.
For me the big problem is that I know it can do loads, but it's not C#. So between the awkward wait for it to boot, the stupid naming convention, and the knowledge that the whole power of the .net framework should be at my finger tips, but in a really alien and unintuitive way, I prefer to either write a really small bat, or write a small C# console app.
And so I never become comfortable with it, even though I've tried several times since it was released.
The newer IDE is pretty good too.
But C# shows what it could have been if they'd had a talented language designer do it (which no-one can determine if someone is beforehand I admit).
I just wish they'd admit defeat and just use a subset of C# instead of stubbornly sticking with something that seems fairly widely loathed.
Verb-first was also a bad choice. When I type “get” I am getting thousands of suggestions which makes autocompletion pretty useless. There is also no way to find all cmdlets that deal with active directory. It would be much better if I could type “AD” first and then get all cmdlets that deal with active directory.
I don't think it's that bad. Better than bash where every command has is either something archaic or just what whoever wrote it wanted it to be. It better resembles English than the other way around. Plus you can use "get-command "something`" which gives you everything that contains that string, or search for a certain provider for all commands related to a specific thing.
Autocompletion still works, just type first letter or two after get and filter most stuff out.
Powershell was made to allow launching arbitrary programs with redirections and pipes. That's why some language choices were made and that's why I'm interested in comparison with bash.
sysadmins who are fully invested in the MS ecosystem do use it a lot. People doing cross-platform work, don’t.
In terms of wider adoption, it suffered by maturing at a time when a lot of people had moved on to more powerful devop solutions. And of course, being MS tech (although technically it was acquired), it carries a stigma.
I just found it un-intuitive, ugly, and verbose. Compared to my beloved python it looks really really bad.
It’s pretty widespread if you have to do sysadmin scripting. There are a lot of useful cmdlets. I am embarrassed to admit that I also run it on my Mac with good success.
>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.
PS wasn't invented when my smart new Pentium 60 was crunching the thing I wrote about above! Cripes: OLE was the latest whizz bang thing in Windows back then.
I'm pretty sure that if you partner with someone that can package your food supply chain knowledge into a nice UI/UX experience (or doing it yourself, idk), you could produce and sell a decent piece of niche software for planning in food plants.
At $work we are into software for managing plants (not in the food industry), and the demand for tailor made planning functions is obvious.
I'm a PHB these days but I'm 2/3 the way through building a Prusa 3D printer so all hope is not lost. Also, unlike most other MDs, I have a soldering iron and a fair few ESPx devices on my desk ...
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++.
Working in a windows environment you often end up dealing with powershell already .. which means you don't have to learn another language and ends up simplifying everything.
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.
My final year project was a VB6 -> JVM compiler. I underestimated how big VB6 actually was and so only had time to implement a small fraction of the language. I did discover a bug in the IDE's code completion/formatter that would cause a compilation failure when the project was next loaded. That code is on a floppy somewhere
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.
Thing is, it was never about language capability. VB6 with COM was still faster in terms of development cycles for people used to the woes back then. Though I'd argue that the few differences there were between VBScript/VBA and VB6 made it much more capable from a development perspective back then... Most of my VB6 bubble moved to VB.Net during the transition, the widespread move to C# with those folks came years later when it became somewhat inevitable. After all, for the typical type of application, language is honestly mostly irrelevant as long as it does not get in your way.
All this feels a little like history repeating itself. We even naively made up a petition back then to keep VB6 around, somewhat glad that led nowhere in retrospect. A few decades ago I loved that the VB ecosystem was approachable and combined beginners and professional users. I somewhat think we have enough other good tools that fit this description these days, some of which incidentally even come with a good programming language.
In terms of data structures, absolutely. Thing is, for a lot of applications you don't need all those extra features. Lots of apps are boiled down to "The user inputs this, I do some crunching, they get this output." Whether your ints are signed or not doesn't matter because you're only counting from 1 to 100 anyway. One thing it did do very well was to make string manipulation and conversion simple.
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 wouldn't say that COM died with .NET - .NET had COM support baked deeply into the platform, to the point of language hacks where to this day, you can "new" a specially defined interface in C# (originally it was a way to reference the associated default coclass for a COM interface, if any). It's very easy to use and create COM libraries, and WinForms fully supports ActiveX controls.
Even as late as 2010, COM support in .NET was still being developed - C# 4 got named indexers for this reason alone, and its "dynamic" supported IDispatch out of the box - its main scenario being Office automation.
I argue that COM "died" when .NET rose in reference to the COM ecosystem because prior to the release of .NET on Windows most non-Java developers were writing in either VB6/Delphi or C/C++ for their desktop applications.
VB6 and C++ (specifically, Microsoft VisualC++'s __declspec-punctuated dialect at least) were both intimately connected to COM with their respective compilers have built-in support for DOM/DCOM/etc (e.g. VC processing IDL files and generating TLB files, while the VB6 compiler seemingly reads-in TLB files natively - and can generate its own too) - and all major components for Windows desktop development (such as ADODB for OLE and ODBC database access, the Macromedia Flash player, OLE objects in general, and VB-ecosystem "components" like charting widgets and new styles of buttons were all done using COM - which means programs written in VB6 running in the VB runtime could use the same GUI components and platform feature libraries as C/C++ code running in its own world - that is cool!
While .NET is fully compatible with COM - the ecosystem isn't the same: WinForms and WPF GUI components written for .NET now cannot be used by VB6 forms or C/C++ windows (at least not without hosting .NET in-process and then facing additional issues integrating your Win32/User32 GUI with a WinForms hosting surface) - while hosting COM GUI components in WinForms is straightforward and just like VB6, hosting a COM GUI component in a WPF environment is very, very painful (google "wpf airspace" to see why this is a bad problem).
Additionally, consuming COM from .NET (even VB.NET) isn't as easy or as straightforward as it is with VB6 either - as you have to contend with the ISA of your .NET process (e.g. you can't load 32-bit COM components into an x64 .NET process).
I feel the amount of third-party software on Windows that offered COM automation has dwindled in recent years because of those reasons.
I think we need to distinguish between COM and OLE/ActiveX here. COM interop in .NET is two-way, and the consumer doesn't even need to be aware that there's a VM running the code that they're invoking. OLE is much more challenging, because the UI framework needs to be aware of it, and because it's built on Win32 UI primitives - so any framework that doesn't use those is going to have issues much like WPF (Qt is another example).
Bitness is not a new problem - VB6 similarly has problem consuming COM components written in C++, but compiled as 64-bit. Or, to put it another way: VB6 didn't have a problem, because 64-bit wasn't a thing back when it was popular, and didn't really became common on Win32 until relatively recently. But in a similar vein, if you always compile .NET code targeting x86 rather than AnyCPU (which is the default for new .NET VS projects - not sure when that changed, but it's been several years), you get the same exact behavior as VB6.
Getting back to OLE and ActiveX - I would say that it was killed by Microsoft directly, not because of .NET. Back in the day, most non-trivial Windows apps made by MS supported OLE for embedding - this was most commonly used with IE, but you could also do it with e.g. Word and Excel... until you couldn't anymore. If I remember correctly, it was Office 2007 that killed it as an officially supported scenario (you could still do it, but if anything broke, you were on your own). That roughly coincides with WPF, and I don't think that's a coincidence - but it doesn't mean that WPF/.NET was the primary cause.
> COM interop in .NET is two-way, and the consumer doesn't even need to be aware that there's a VM running the code that they're invoking.
I understand that's because .NET components loaded into a native process via COM are done so in-proc but using a single instance of the CLR, means you can't have .NET 2.0 CLR and .NET 4.0 CLR components loaded at the same time into the same process. I also understand (but am unsure) about what this means for AppDomains.
.NET Core simplifies things considerably: by being utterly broken when it comes to COM support and generally requiring each .NET Core program to have its own independent process rather than supporting multiple AppDomains in the same process (okay, that's a bit of hyperbole: .NET Core supports strongly-typed COM objects but they removed support for using `dynamic` with late-bound COM objects - and I can't find any documentation regarding loading .NET Core components via COM into a native VB6/C++ process.
> But in a similar vein, if you always compile .NET code targeting x86 rather than AnyCPU (which is the default for new .NET VS projects - not sure when that changed, but it's been several years), you get the same exact behavior as VB6.
I understand the default for .NET Framework application projects is still AnyCPU but a new option called "Prefer 32-bit" is selected by default. Whereas for library projects and all .NET Core projects the default is AnyCPU ("Prefer 32-bit" is only an option for *.exe projects).
> If I remember correctly, it was Office 2007 that killed it as an officially supported scenario (you could still do it, but if anything broke, you were on your own).
> That roughly coincides with WPF, and I don't think that's a coincidence - but it doesn't mean that WPF/.NET was the primary cause.
I understand the reason was because very few applications in the wild depended on this functionality (that's what Microsoft's telemetry in Windows is for) - I think the only real application that made full use of this was MS Binder (rip 2002) - and I only ever got annoyed at the times when Internet Explorer would load Office Word or Excel directly into the browser shell.
Office 2007's radically redesigned UI required much more screen real-estate - whereas Office's support for being loaded into an OLE window was back when people were running at 640x480 or 800x600 (if you were lucky!) and Office had 16px-sized toolbar buttons - which is another reason to avoid wasting developer time working on it.
> I understand that's because .NET components loaded into a native process via COM are done so in-proc
That's not necessarily so. By default, a .NET class exposed via COM is free-threaded, so it'll be instantiated in-proc. But you can have all the same complicated apartment arrangements as with native - and marshaling is done via type libraries that are generated from assembly metadata. So if you want an out-of-proc COM server written in .NET, it's quite possible.
> but using a single instance of the CLR, means you can't have .NET 2.0 CLR and .NET 4.0 CLR components loaded at the same time into the same process.
If you use in-proc components, then yes, the runtime is loaded. But .NET 2 and .NET 4 runtimes are intentionally designed to be possible to side-load. They don't see each other as .NET, of course - so if you take a reference to an object in one runtime, and pass it through native code as a COM reference to the other runtime, it'll see it as an opaque COM component.
.NET Core is its own thing - it's clear that everything Win32 is legacy there, including COM. I was surprised it even got WinForms...
The new ways of automating applications is Powrshel with its COM/.NET/DLL integration.
And UWP as modern COM is here to stay, no matter what, Microsoft seems to be willing to spend the money to keep it going, even it requires a new programmer generation.
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.
You don't need any of that. VB6 had C FFI (Lib/Alias), structs, and function pointers (AddressOf). So you could just implement a function in straight C, compile it into a DLL, and invoke it from VB.
I know but already function prototyping of a DLL your write to get around language limitations isn't quite in the spirit of "things you can do in VB6". And technical you could do it in VB, but it was pulling teeth. I could just as easily write it in java and shell out to it. In VB it was hard pretty difficult. But you are completely correct, that's the right thing to do. I don't have bad feelings towards VB at all. Even today it was probably the most productive GUI development environment I've ever seen. But function prototypes returning structs / buffers? OnError GoTo <label>? Nostalgia only goes so far.
ps - noticed the employer on the profile. Powershell + .NET assemblies crushed it, and VB.NET was a far superior language (though, just like all the jvm languages have the same feel, all the IL based ones did and why not use C# at that point?)
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.
To me, this shows the huge risk of building on a language/platform that depends on a single company.
This even happened earlier. Visual Basic .NET is grossly incompatible with Visual Basic 6, so much so that Visual Basic .NET is essentially a different language and was derisively called Visual Fred http://catb.org/~esr/jargon/html/V/Visual-Fred.html ... Of course, it was possible to rewrite software so that would work with Visual Basic .NET, but that completely misses the point. Most people in The Real World have better things to do than rewrite working software just to keep it working. Most of us want to solve new problems, not re-solve the same problem again.
Those who chose to use Visual Basic for non-trivial software got the shaft twice, including the transition from vb6.
But don't worry, I suspect in a few years many people will forget about the risks of tying yourself to a single company and will get the shaft again. History so often repeats itself because people don't learn from history. I wonder how many people will actually learn from this. Maybe the community of software Ddvelopers will learn from this. But I fear it will just happen again. If someone could prove me wrong that would be great. :-)
As an ex-VB6 programmer, my view is that Microsoft has been fairly supportive of VB users.
- The IDE itself was supported for 10 years, till 2008
- The runtime is supported till 2024, which is like 26 years. I think you can get it to work on Windows 10 as well, though I haven't tried it myself. I still see people using VB apps.
My view is that VB.Net should never have been created, since it was closer to C# than it was to VB. Neither should it have been adopted by VB programmers (if they did a fair analysis), but Microsoft messaging around that time may have suggested it's a workable path forward.
The typical working career is 40 years. If 10-26 years is considered an acceptable lifetime for a language all your experience in the languages you use will be forcibly reset fairly early in your career.
It isn't going to be major in itself, but becoming known for being a specialist in a corporate sponsored language is a pretty catastrophic career error. Anyone who learned C on the other hand looks pretty clever.
On the other side the reason VB.net broke backward compatibility was to correct things that were obviously bad design decisions in VB6. Like parameters being byref by default, having to use the Set keyword for objects, inconsistent 0 or 1 based collection structures, etc.
If VB was meant to survive and move the XXI century, these things had to be fixed.
VB.NET half-broke the compatibility, which got it stuck in the weird space where automatic translation from VB6 was no longer possible, but VB still had lots of quirks that made it harder to coevolve it with C#.
It works in Windows 10. It's a problem to install because VB6 expect a very old version of Java and the 16 bit installer doesn't work in the 64 bit Window. But after a few trick, it still works.
Totally agree. I'm always confused why people eg buy in to TypeScript, when for me the entire point of using JavaScript is its portability and ubiquity. If you're willing to accept a build/compilation step, then there are much, much better languages out there IMO, rather than slowly shoehorning weakly-typed languages to become "more like Java", and creating guaranteed portability and lock-in issues along the way.
I never understood why F/OSS didn't kick in to provide a portable runtime for VB or classic BASIC. There is/was something like GWA Basic, wasn't there? At least I'm not aware of a formal language spec for (classic) BASIC from the likes of ISO.
> I'm always confused why people eg buy in to TypeScript, when for me the entire point of using JavaScript is its portability and ubiquity
Javascript's ubiquity and portability does not change the fact that on its own, it is a pretty bad programming language. There are a plethora of reasons to choose Typescript, most prominently is the much much better development experience Typescript give you.
I'm not sure if you've used Typescript, but using Typescript still gives you the portability and ubiquity of javascript because all it does is compile down to Javascript.
It's not like they're going to break VB.NET or drop support anytime soon. Existing software will keep working. At this point there's no real point in continuing to add to it -- new stuff should be written in C#. It's better.
VB was a great and successful language. It empowered a lot of departments to create bespoke programs that, while not having been built on solid comp sci principles, were good enough and solved real business problems without having to involve the IT department. That’s a strength and a weakness.
VB is one of those things that let the determined create useful things. Not unlike Microsoft Access.
Instead of actually learning principles and practices, and a 'good' language, they could just hack something together than managed to just barely work, armed with a $99 copy of Visual Basic and a 'Teach Yourself VB in 21 Days' books from SAMS publishing.
And by the time they knew any better, they were up to their ears in shit. Chances are, if you have a big project in VB, you also have the following problems:
* You're not using version control. Or worse, you're running Sourcesafe.
* You're not using secure encryption or communication
* You're not using secure programming practices
* You're not using a modern, secure OS
* You're also using some 16 or 32-bit utility libraries that nobody has the code to
* You're employing developers who have 20 years of "1 year experience with VB"
* No need to write a business case with fake ROI figures. No IT committee meeting. No need to teach a “solutions architect” who doesn’t really care to learn.
* Easier to evolve as requirements change because the front line person is fixing it.
* Proof of concept done already when you need IT involved for version control, security, etc.
Do you have any hard evidence of an actual causation between VB and the symptoms you describe? I think any non-bleeding-edge mid and later hype-cycle technology will have its monsters. I get the feeling VB is past
all that, and what's leftovers can't be sooo disfunctional.
In 2001, I was 11 and started my programming career with Visual Basic 6. John Smiley book!
I was obsessed with theme parks and roller coasters at that age, so I made a 'theme park' application that let you look at maps, rides, and buy tickets.
Just having the basic logic of OOP down at 11 was a game changer, I started to look at the world in a new way. I felt like I could solve any problem if I could map it out on paper first.
It's coincidental to have this announcement come on the same day Bill Gates announced he is resigning from the Microsoft board (I'm sure completely unrelated). Microsoft was founded on the idea of writing Basic interpreter by Gates so a legacy of 45 years from both has ended today.
Gates was still a huge fan of BASIC in 1990s, and I think VB would probably not be what it became at its peak without him constantly pushing it to the front of Windows dev stack.
I learned how to program in VB4 too. My parents had no idea why I wanted it or what it was for. I used to take the textbook sized manuals with me to read/study while camping and fishing.
I first learned it by myself in VB5. I didn't even understand functions, but writing those MessageBoxes with buttons and then having them create even more message boxes was so great! I remember a high school friend bringing me 5 diskettes with VB4 installer because I didn't have it on my home computer.
Then next year I enrolled in AP Comp Sci - hardcore turbo c++. Just blew my mind!
> Then next year I enrolled in AP Comp Sci - hardcore turbo c++.
Funny enough, AP Comp Sci went the other direction in the early 2000s, switching from C++ to Java precisely because it was too hardcore for the average high school student.
My high school in ~2010 had the progression C -> C++ -> Java. I remember the C++ that we were taught being easy enough to learn after a semester of C, and graduated before I could take Java.
haha. I was so excited to learn about C-style strings in AP comp sci 2 I think. And bitshifting, and crazy recursions, queueing, etc. Good old days... I was so arrogant after that too. C is the best and everything else is garbage because it's "slow".
E.W.Dijkstra would disagree: "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
When Dijkstra wrote that quote in 1975 he didn't had Visual Basic in mind, he was thinking the much older BASIC dialects that used line numbers and GOTOs for flow control.
Dijkstra was trying to promote structured programming languages like Algol and Visual Basic is based on the QBasic dialect which has full structured programming features like WHILE and FOR loops, IF that would work with compound statements (that is have the THEN part be more than a single command), local variables, functions, recursion, etc. It might be hard to image nowadays but there was a time when those weren't available to all languages. Though note that the next year after Dijkstra wrote that quote, the original Dartmouth BASIC actually got structured features. Though it wouldn't be until QBasic that you'd see a (popular) BASIC dialect having those in home computers.
Regardless, this quote was outdated long before Visual Basic 1 was made, let alone VB6.
GOTO for flow control is not that bad, it's just a tail call after all. The real damage is things like having everything be global variables. But part of that was a technical limitation, as things like "proper" call stacks and reentrant code as the default still had plenty of overhead, and even FORTRAN didn't support them.
I'm not sure what you have in mind but in the 1975 dialects of BASIC the code was something like
10 REM Grab input
20 GOSUB 1000
30 IF VALUE=BAR THEN GOTO 100
40 IF VALUE=BAZ THEN GOTO 200
50 IF VALUE=BLA THEN GOTO 300
60 GOTO 20
100 REM Bar stuff
110 blahblah
199 RESUME
200 REM Baz stuff
210 blahblah
299 RESUME
300 REM Bla stuff
310 blahblah
399 RESUME
1000 REM Code that grabs input
1010 blahblah
1100 RESUME
Note that this is a bit more readable than what people worked with since now you have syntax highlighting.
I'm not sure where tail calls enter in the picture... there wasn't even support for functions, at best you had GOSUB/RESUME which was essentially assembly-like CALL/RET.
I don't think that example you've posted is right (the grab input one, not the game on Github).
Firstly, RESUME was to continue execution after an error (eg ON ERROR RESUME NEXT). I think RETURN is what you might have meant?
Secondly, you cannot RESUME/RETURN from a GOTO. I think you meant GOSUB; which was a crude approximation of subroutines. BASIC did also have GOTO as well though.
Yes you are right, i meant GOSUB/RETURN. Though instead of "RESUME" (which should have been RETURN) most programs would use GOTO 20 (in an opposite expression of what Dijkstra wrote about, i accidentally used a 'function call' idiom instead of a spaghetti 'jump wherever' one :-P).
> I'm not sure where tail calls enter in the picture...
GOTO essentially involves setting the continuation of your program to something other than the following instruction(s). That's what a tail call does. No "functions" involved except as a high-level description.
Goto has its place. It's not evil, but should be used judiciously. After all, C family constructs such as break, continue are glorified/specialized, albeit scoped and unlabelled gotos.
One of the places I like gotos is when I need to break out of a nested loop. A goto to outside of the outer loop is far more obvious than a flag and a conditional to break from the parent nested loop. It also generates better machine code and uses fewer registers, at least in debug mode.
Sure, goto can be abused, just like every other language construct. They have their time and place, though.
The issue was not the presence of goto itself, but the fact that is was one of the main tools for flow control, while as you say it should be used sparingly.
It is like having an army of soldiers armed with a David Crockett[1] instead of a regular rifle. Things may get ugly fast.
Yes. And Dijkstra would be wrong. (Or, perhaps more accurately, prone to somewhat bombastic hyperbole.)
BASIC is structurally similar to ASM, moreso than is any other HLL, at least of any popularity. Like almost any language (or paradigm) it is possible to get stuck in its particular ruts, and when BASIC was at its peak popularity there were probably lots of people stuck in those ruts just as later happened with Java and the static, class-based OO paradigm more generally. A learning language isn't something you stock with exclusively, it's something you learn with and then diversify from, ideally, and for that, BASIC (old-school unstructured imperative BASIC) is great.
BASIC (old-school unstructured imperative) is structured as the "ASM" language for an old-school desk calculator from the 1960s, with a few tacked-on features around string manipulation, input handling etc. plus more, depending on the hardware. It was fine for what it was in the 1960s (a simplified "scripting"-focused version of FORTRAN), but the needs of even slightly more modern coding are very different, and BASIC would not serve them well.
to me, that was always a great example of the difference between IT and CS.
I totally understand how someone trained in VB was "mutilated" for CS. Because the priorities for CS coding are totally different than for commercial coding.
But from an IT perspective the point of programming is to be profitable, not perfect. VB allowed people to write profitable programs quickly. It was a fantastic environment if all you wanted to do was write desktop applications for businesses.
The quote is about BASIC. Visual Basic is a variant of BASIC.
The quote was also thrown around a lot in the late 90's as a "VB sucks, you should use a real programming language" comment in the usual language flame wars.
Certainly, the next few years of my learning to program was unlearning ideas I had developed from coding in Visual Basic. But it gave me the start in understanding how functions work, how sub-procedures work, and how objects work. More importantly though, Visual Basic gavve me the excitement and possibility that I could make this thing on my family's desk do pretty much whatever I wanted. And Visual Basic made that very accessible.
IMO it depends what you mean by “good programming”. An Excel spreadsheet with a bunch of VBA macros is by absolutely no means graceful programming or beautiful programming but it’s highly effective and has served as an entry to the world of programming for a huge number of people, myself included. It’s productive programming with little of the bikeshedding you’ll find in much less “mentally mutilated” setups.
Probably just hyperbolic. Bad habits are a common complaint in music and sports education too. Not insurmountable, but not helpful, and it must be frustrating as a teacher to have to unteach bad habits.
Christian theology was historically a great impediment to learning about physics; some Christian cults continue to impede people from learning about biology.
People who are really good at manipulating other people seem to have a hard time learning to do productive things, maybe because it's too easy to manipulate other people to do them instead, but maybe because people sometimes follow the Law of Attraction, where you make wishful thinking come true by believing in it hard enough, while software and Volkswagen engines do, if anything, the opposite.
More broadly, I think any field of learning carries with it a sort of implicit value system: we consider things x and y centrally important, while things a and b are inconsequential details. Much of learning a field involves internalizing these values to the point where you apply them automatically without even being aware that there's an alternative. But often they are suboptimal or even counterproductive in a different field. Volkswagen engines don't care about paint color or whether your grandfather just died, but they do care about thousandth-of-an-inch tolerances and not making mistakes. Interior decorating doesn't care about thousandth-of-an-inch tolerances or clean abstractions, but it does care about paint color and whether your grandfather just died. Debugging software doesn't care about not making mistakes or paint color, but it does care about clean abstractions.
This is even true in subfields within the same field: real-time engine control software cares about memory allocation in a way that seems completely insane to anyone who programs in Python, for example.
BASIC tends to reward novice programmers for banging on a piece of code cluelessly until they get it to work in some cases. Dijkstra, by contrast, believed that what was important was having sufficient logical understanding of the program's space of possible behaviors that you could be sure it would work even before testing it; he in fact designed and successfully taught an introduction-to-computer-programming course that used no actual computers. It's unsurprising that someone who had internalized BASIC's value system would be extremely resistant to Dijkstra's preferred approach, and that Dijkstra's disciples would be extremely resistant to the BASIC approach, even though in fact they are complementary, and each one works best for some classes of problems, so those who are best at one of these ways of working are those who would gain the most from learning the other.
I had 7 years of C# experience in 2015 when I had to make an unanticipated job change. With some trepidation, I took a position with another company in the same industry whose codebase was all vb.net. I used Telerik's code converter a lot to bootstrap my proficiency with vb syntax. The boss said I could just write in C# if I wanted to, but I saw no need to make more mental work for the rest of the team.
Interestingly I was in a meeting with Brendan Burns (of k8s fame) last year where he was extolling the virtues of VB. Not that it was the greatest language or anything, but that it brought programming to the masses, the ability for shirt and tie managers to do little things that increased their productivity.
I evaluated Visual Basic as an alternative to Borland C++ to develop Windows programs. It was just not there. Borland C++ allowed easy GUI design and was easy integrated with Windows APIs for any low-level needs.
Several years later the jump in quality was astonishing. Good ODBC drivers and easy linking between database rows and your UI make it a fast development tool that fit many needs.
I do not miss the big colored buttons that many developers used at the time. Never as bad as Access applications used to be, thou.
I took a VB course in college and was immediately hooked. Then I immediately switched to Borland. There is something about being able to compile a runtime-free, native binary.
Visual Basic and Python are not that simple. Simplistic maybe. Go is a lot closer to the mark, though. It might be the closest thing we have today to classic QuickBasic (the "Visual" part being pretty GUI-dependent, all things considered). Haskell is also getting there - the baseline syntax is extremely simple.
The semantics of VB6 are basically that of OLE Automation (or vice versa - it can be hard to tell sometimes). That doesn't make it impossible to port to other platforms, but it would require extra effort. And the result wouldn't have all the benefits VB had on Windows, where COM was pretty much OS-level native at the time.
Even with such a decision it would have been quite a lot of work to make VB relevant to the non windows way of doing things (i mean anything that is not done as event handlers to UI widgets of some sort)
I think VB6 served a useful purpose. I used it for internal utilities all the time when I worked for Microsoft.
I haven't used any of these tools in probably 20 years but in addition to VB6, I also liked Delphi and C++ Builder quite a lot back in the day. Delphi was probably my favorite of the bunch. Embarcadero still sells both Delphi and C++ Builder but their pricing is far too expensive, I think.
Anyway, thank you, VB, and thanks for all the fish.
Wonder what is going to happen to Visual Basic for Applications? I hope it pushes Microsoft to move toward a new language like Python to automate Excel.
The two are completely district languages. Kind of like comparing Java with JavaScript.
I'm sure in general Microsoft would love to scrap VB in Excel but there's too many companies that run entire areas of business on it, or the whole business itself.
It is the typical legacy/back compat problem. Python or even Powershell would be a vast improvement, but you're going against billions in sunk cost/skills/knowledge.
VB.Net was slowly losing popularity, VB in Excel isn't.
Would it be impossible for Excel to allow coding in multiple languages? I totally get that there's a huge (disturbing) amount of business critical stuff using the current scripts, but they really should move on to something more modern.
Multiple-language runtimes typically don’t get popular - people just end up choosing one language and standardizing on it. See for example Windtows Scripting Host: you could always use Javascript with it, but almost nobody ever did in practice. After a while, typically the vendor sees other languages as a drag on development, and they get dropped in favour of the main one.
Retrofitting a multiple-language runtime under VBA would likely be a big endeavour, and in the end most people would probably stick to the established language anyway.
Microsoft pretty much built it (would allow any .net language to behave like VBA, with an integrated IDE and ability to save code inside the document). Then they killed it. I think that was a huge mistake from a productivity point of view, and also to get a fighting chance to retire VB6.
Python seems to be the new "beginners" programming language (the "B" in Basic), it's taught in schools now and makes Basic look rather archaic in comparison. So I would say the writing is on the wall. What was good about Visual Basic was the IDE and GUI builder. Sadly this has no real modern competitor in terms of ease of use.
The adblocker doorslammed me. Here's the text of the article.
Microsoft said this week that it will support Visual Basic on .NET 5.0 but will no longer add new features or evolve the language.
“Starting with .NET 5, Visual Basic will support Class Library, Console, Windows Forms, WPF, Worker Service, [and] ASP.NET Core Web API … to provide a good path forward for the existing VB customer who want [sic] to migrate their applications to .NET Core,” the .NET team wrote in a post to the Microsoft DevBlogs. “Going forward, we do not plan to evolve Visual Basic as a language … The future of Visual Basic … will focus on stability, the application types listed above, and compatibility between the .NET Core and .NET Framework versions of Visual Basic.”
When Microsoft released the .NET version of Visual Basic, originally called Visual Basic .NET, alongside C# at the beginning of the .NET era, the two languages were evolved together and had roughly identical feature sets. But this changed over time, with professional developers adopting C# and many fans of classic VB simply giving up on the more complex but powerful .NET versions of the environment. Today, virtually all of Microsoft’s relevant developer documentation is in C# only, with VB source code examples ever harder to find.
Worse, Microsoft in 2017 announced that its original C#/VB co-development strategy was over. Only C# would get all of the new features, while VB would focus on the simpler and more approachable scenarios that it once dominated. But that never really happened, and Microsoft effectively abandoned VB. This week’s announcement just makes it official.
What this means to VB developers is that they might be able to bring their existing codebases forward to .NET Core or, soon, to .NET 5.0, which will replace both the traditional .NET and the open-source and cross-platform .NET Core when it’s released in late 2020. The issue is that not all legacy technologies will be supported going forward, so developers using WebForms, Workflow, or Windows Communication Foundation (WCF) will need to stick with classic .NET. Those applications will continue to work and be supported until the underlying Windows versions are retired; classic .NET support life cycles are tied to the Windows versions on which they were initially deployed.
Microsoft also notes that VB developers will occasionally benefit from improvements to Visual Studio.
“Visual Studio regularly adds new features to improve the experience for developers, including those using Visual Basic and either .NET Core or .NET Framework,” the .NET team adds. “An example is the recent addition of IntelliCode for Visual Basic.”
This is a sad day, and one that hits me personally. I started my writing career with Visual Basic 3, went on to write several books about VB and its various variants, and most recently wrote an entire Notepad clone called .NETpad in Visual Basic, Windows Forms, and the .NET Framework.
VB3 was my first real language. I'd attempted stuff before on spectrum and BBC BASIC and later QBASIC, but VB3 not only allowed easy development of a GUI application, it allowed you to distribute an EXE -- a real grownup program, not a ".bas" file. I wrote my first commercial program in VB3 or VB4, to look after book orders, had an access database behind it, and all sorts of oddness to do printing if I recall rightly. Used VB4 as well, and I guess I used VB5 as well.
I moved on, to the web, to things like TCL/TK, Java, and Perl. Some things never change, I have a full screen vim window with a brand new perl script on my right-hand monitor as I type this.
Despite having dumped windows 20 years ago, I've still got a place in my heart for visual basic.
I'll always fondly remember Visual Basic as the language that let me make real Windows applications with the language I already knew and understood.
I was just a kid, maybe 10 or 12, when I learned to program with QBASIC and later VB5. I remember strongly feeling that a ".bas" file wasn't a real program. I so much wanted to be able to run my programs as real .EXE files. There was some kind of QBASIC compiler that made an .EXE but I felt like that was just... still not real enough. That desire for making a real bonafide .EXE was one of the driving reasons I (tried to) learn C.
I got started with VB1 and did my first commercial product in VB3. I wrote many applications in VB6 over the years and I was maintaining one application continually from 2000 to 2019. It worked great, with excellent debugging but was getting a bit long in the tooth over the last few years and the big fear not so much VB itself but the continued compatibility of third party components.
Like most developers I migrated to the curly braces languages (C# -> JavaScript -> TypeScript) but my first love will always be VB.
As long as they give me something to use in the place of VBA, I can't wait for all forms of Basic to die. It hurts to use it, but I have to because there isn't anything else in Excel.
I wonder what the cost of creating a vb6/ Delphi style environment with Python as the language would be. This could be a very popular project if someone could get it off the ground. Something like a vscode plugin?
I have no idea how that would work, but I would put real money into a kickstarter for someone who did know.
I hate GUI programming in Python. Even simple 'click here' to run involves more concepts than my kids want to know yet
Scratch is probably the most logical choice for teaching programming to kids (at least in an age when it's still hard for them to concentrate on multiple concepts before seing some results)
I started my career on a project that was 90% C# and 10% VB.Net. Most of the work in VB.Net was junk code that I had to refactor; ultimately, it didn't make any sense to use VB.net for that code.
I could never really understand why there was VB.Net. It had some language features that C# didn't have, but they were features I'd never use in an industrial strength program.
The spirit of VB continues to live and prosper in B4X. B4X is a cross platform, native, RAD tool for mobile and desktop apps.
There is a large community of B4X developers and many of them were previously VB developers.
Most of the tools, including B4A - native Android apps, are completely free and the framework is open source.
You are all welcome to try it.
Many fond memories here, can't say I share them. Throughout my career, vb code or programmers/architects from a vb background have been the bane of my existence.
The kind of language that supports the construct:
> on error resume next
(i.e. if any errors happen, just run the next line regardless), needs to die. I appreciate this is harsh but IMO, good riddence.
I thought HN was supposed to collapse duplicate submissions to a single topic? URL appears to be identical. Is there some kind of cache issue in HN's backend?
Caching issue is unlikely, given that HN runs as a single thread on a one server, writing to a flat-file backend. As far as I'm aware the main cache involved is the OS's page cache.
To your main point, the dupe detector seems to be fairly limited; I think it only checks for the same URL in the past 12 hours or 100 posts or something. It seems to be just to keep the same post from showing up multiple times in /new.
When the resubmission is very soon, they are collapsed. After some time, the new submission lives. The exact time is not officially available, and the mods may tweak it from time to time without warning.
I never understood the purpose of VB.Net. My second job out of college was a mixture of VB6 and C++ where we would use C++/ATL (COM) to mix and match languages. Of course the VB6 IDE was miles better than the C++ IDE.
But, Windows Forms with C# was just as easy as VB6 and VB.Net was just as complicated and more verbose than C#.
Microsoft politics after hiring Anders Hejlsberg who designed C# as a competitor to Java so Java's compile-once-run-anywhere wont take a foothold on the desktop market and thus endanger the dominance of Windows, required that everything related to developing software for Windows was focused on C# and .NET to drive home to ISVs that this is the future, but up until that point VB6 was wildly popular - and absolutely incompatible with anything related to C# or .NET. So they reskinned C# with some VB clothes and paraded it in front of VB6 developers, hoping they wont notice the sharp bits sticking out - which worked as well as you'd expect. But with Microsoft having full and absolute control over VB6, it isn't like anyone could do anything about it, so over time people moved on. VB.NET never managed a hint of VB6's popularity and was always in the shadow of C#, which made perfect sense since outside of liking QBasic-like syntax more than C-like syntax, there wasn't any reason to use VB.NET.
I started with Visual Basic 3 which I loved.
Other programming I was doing at the time was with PIC micros.
Never really got into VB6, got into Linux and used PHP, Ruby, Java, C/C++ and Python.
Drifted in and out of electronics, chemistry and software.
What a time to be alive.
In about 1998 I got introduced to programming beyond CMD prompt through VB. My first form was just an input box, a button, when clicked, alerted the box contents onto a dialogue box. My mind was blown when I found that using & in label makes the Alt+ keyboard shortcut.
Microsoft started with BASIC, so this is pretty sad news. I made cash with VB and really liked the whole "buy some VBX/OCX components, hook the together, and ship app" economy. I cannot help but think that this is bad for other reasons.
It is a shame that Microsoft never open-sourced cLassic Visual BASIC. Let the fans support it with donations. I made a lot of money by programming in Classic Visual BASIC.
VB.Net is not the same thing, it has C# features added to it.
Is there really a lot of production VB.NET? I wouldn't be at all surprised to learn there is more production VB 6 code and development on that stopped two decades ago.
Yes, it is the to go programming language in life sciences corporations when Office users outgrow their VBA skills and get to have IT install VS on their computers.
I know a couple of places like this, no R, no Python, VB all the way.
Python didn't have the developer will to embrace interop between Python 2 and 3 transparently in bytecode, so you had a hard switch over.
CIL doesn't have that problem, you can keep writing in VB.Net without being forced off a supported compiler.
I was in a fork in the road and had the choice between Python or .Net to move forward with my career a few years back, there were a few factors on why I went .Net. Being one of very few pleasing to use and (extremely) widespread languages with static typing, along with MS's early embrace of WebAssembly were both major influences. Yet the biggest was the Python core devs refusal to address Python2/3 in a better way. There's no good reason why you couldn't use the same Python 3 interpreter for Python 2 code. I get the maintenance argument, but this raises questions about the future, and it makes their platform look rinky dink today. I came to the conclusion I'd never build anything important on it, which is essentially everything you write, as projects tend to grow.
Visual Basic was one of first languages i have learned. A lots of its spirit was moved into C#. Maybe its good, but on the other hand we loose a good one leaving more Space for JS and the creature called TS.
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.