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.
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!
I am, quite frankly, exhausted.
> ...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.
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.)
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.
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.
Same. But I have remained with Delphi. I think we are now known as the lost generation. :-)
Accepting new members into the club? :)
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. :-)
Delphi is a victim of its stewards management post Borland.
Last great decision, remove reference counting and back to full manual memory management on the upcoming Delphi version.
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.
Or maybe Xojo: https://www.xojo.com/
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.
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.
If you're interested in a GUI editor, this is the tool people are using these days:
It's a paid product, but comparatively cheaper than VB6 was.
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.
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.
Maybe coding the Arduino/ESP32 game boy clones is appealing to today's kids.
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.
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.
I'm now write C++ for a living.
If you're starting from scratch, VB.NET is not really any harder to use for this purpose than VB6.
edit - I'm guessing whoever downvoted doesn't know who Trent Lott is.
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!
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.
myfunc -param1 this -param2 that
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:
Set-PSReadLineKeyHandler -key Tab -Function MenuComplete
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.
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.
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.
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.
Structured data with direct access to any OS API, regardless how it is provided, .NET, COM or straight C like DLL.
UNIX world never had that, beyond trying to fit language repls as user shell, which on UNIX always feels like a leaky abstraction.
But just so you are aware you can use the 'class' modifier To change this behavior.
It is one of the most fundamentally bizarre language design choices I have seen in my career
I usually get frustrated with it and bash out a quick cmdlet instead.
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.
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.
I don't think people compare it with bash, but with more modern languages.
[PS] C:\> Get-MyReallyLongFunctionName -Server furtle
$ lol --floop
PS is fine but it takes ages for the bloody thing to wake up and notice command completion. It is like dealing with a teenager in bed.
Actually, I have no problems with PS but with MS's idea of search as deployed to users.
(I run KDE on Arch. Search is faster than I can blink)
Autocompletion still works, just type first letter or two after get and filter most stuff out.
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.
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.
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.
You don't even need Excel!
This is the VB6 comparison in my book.
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?
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.
That market isn't going anywhere anytime soon, though.
There are a lot of XP machines out there running critical VB code...
Not open source but it looks quite interesting.
(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.
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.
Apparently VB does support unsigned data types in some version: https://docs.microsoft.com/en-us/dotnet/visual-basic/program...
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).
It kinda still lives on in classic ASP. It will be supported indefinitely so far 
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.
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.
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.
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.
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.
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...
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.
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.
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?)
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.
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.
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. :-)
- 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.
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.
It's an exception.
If VB was meant to survive and move the XXI century, these things had to be fixed.
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.
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.
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.
Then next year I enrolled in AP Comp Sci - hardcore turbo c++. Just blew my mind!
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.
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."
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.
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
200 REM Baz stuff
300 REM Bla stuff
1000 REM Code that grabs input
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.
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.
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.
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.
It is like having an army of soldiers armed with a David Crockett 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.
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 isn't about VB; its from 1975, VB was released in 1991.
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.
Or maybe Dijkstra was wrong.
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.
You're a real team player. That's both rare and invaluable on current days of resume-driven-development.
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.
There would have been no need for Python syntax or Golang with Visual Basic's simplicity
in a windows only world.
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.
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.
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 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.
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 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 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
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 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?
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.
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.
VB.Net is not the same thing, it has C# features added to it.
Now I move to Python from Classic Visual BASIC.