> The king of this kind of line-of-business app used to be VB6.
You say that like it's not still happening... VB6 is still the go-to tool at a certain blue cross and blue shield franchise - and probably at many others around the country. They post jobs(active postings right now) for .NET developers with VB6 experience. They do it under the guise to "help port existing applications", but in reality they are still developing new features with it, and will likely never stop.
If by easier you refer to the whole lifecycle of a reasonably secure application, I’m sure that many web frameworks with rapid CRUD builders are much easier, and don’t require distributing binaries, standardizing the desktop platform to Windows, or giving the client binary direct access to a SQL server.
Why not move to VB.NET? I thought the whole point of VB.NET was to give heavy enterprise VB6 developers an obvious non-legacy transition path that doesn’t require any retooling, and only a little (mostly automatic) refactoring.
Microsoft botched VB.NET so completely that there is no path forward. VB.NET was derisively called Visual Fred by VB6 developers because it's essentially a different language that should have a different name.
It would have been entirely possible to make a CLR version of VB that was 99% compatible with VB6 -- and that's what they should have done. It would have given a clear upgrade path for a huge number of applications. Instead they just re-skinned C#.
VB.NET was 99% compatible with the good parts of VB6. The problem was and remains that every project ever actually written in VB6 was written with at least some of the worst parts of VB6 in use. That list of "breaks" is a lovely list of some of the horrors that probably shouldn't have existed in VB to begin with.
> VB.NET was 99% compatible with the good parts of VB6.
Without backwards compatibility with VB6, there are no good parts of VB.NET. The Visual Basic syntax isn't that great to begin with and VB.NET then added more horrible keywords like `AndAlso` and `OrElse`.
In my opinion, most of that list isn't actually too bad. But it doesn't matter, all the horrors should have been included and then deprecated, giving a smooth upgrade path. Instead all VB6 code had to stay on VB6 as it was no where near 99% compatible. You have a language with different semantics, completely new way of building the UI, and superficial but incomplete syntax similarities. Anyone who was forced to rewrite, and was smart, went to C#.
Sure there is, I have done quite a lot work in life sciences enterprises where VB.NET rules, not R nor Python as many HNers would like to talk about.
Heavy Office users that have outgrown VBA and turn to VB.NET to keep doing their little department apps for data analysis without additional help from IT other than getting Visual Studio on their systems.
Also VB.NET gets all the tooling that C++ and C# get, not like the black swan in .NET, F#.
VB.NET has only superficial similarity with VB6. If you move from VB6 to VB.NET you have to rewrite the whole thing so you may as well go to C#.
that's the problem with the .NET front-end tools in general. They have no transition path to their previous version. VB6 to VB.NET is hard. WinForms to WPF is hard. WPF to UWP is a little better but still hard. Yes, they all still run but moving your project to the new shiny tech is very hard.
> you move from VB6 to VB.NET you have to rewrite the whole thing so you may as well go to C#.
Since C# and VB.NET are essentially equivalent in capability, if you are a programmer with no .NET experience and a background in VB6 but not C/C++/Java, looking to rewrite an existing VB6 codebase for .NET, why would you go to hassle of additional unfamiliar syntax to go to C#?
> that's the problem with the .NET front-end tools in general. They have no transition path to their previous version. VB6 to VB.NET is hard.
VB6 to VB.NET is not a successive version of a .NET tool, front-end or otherwise.
"if you are a programmer with no .NET experience and a background in VB6 but not C/C++/Java, looking to rewrite an existing VB6 codebase for .NET, why would you go to hassle of additional unfamiliar syntax to go to C#?"
That sounds obvious. Yet, the group I was in using VB6 thought VB.NET and what people were doing with it looked like it was going to be a bigger learning experience that wasn't just VB6 on a new VM. More like we would be learning a new language, libraries, and so on. So, some of us learned a new language, libraries, and so on with some extra benefits over another BASIC.
C, C++, Java, and C# are where everyone went among those I knew. Some of us kept using stuff with VB6, clones, and/or homebrew 4GL's that were BASIC-like. Most folks just put all that time and effort they perceived as necessary into a language that was a step up. Especially, career-wise.
"VB6 to VB.NET is not a successive version of a .NET tool, front-end or otherwise."
Correct. But VB6 was the main tool for quick UI development before Winforms took that place. Things that would have been written with VB6 would be written in Winforms once it came out.
I really don't know - I was never in that section of the business. Speculating...maybe they have their framework or some other VB6 piece certified for HIPPA compliance and don't want to change?
That industry is very old fashioned though - another good example is that every blue cross franchise uses the same software to process medicare/medicaid claims, and that software is powered by COBOL. At first it's shocking and you wonder how on earth things stay on the rails...but after a while you get used to it, a strange status quo.
I feel like it makes sense to use COBOL to talk to a government mainframe that’s likely also using COBOL, and likely has a wire protocol specced as a set of ready-to-use COBOL client structs.
Sort of like, in the modern day, it makes sense to use Go if the goal is to write an adapter that takes stuff from your database and pushes it out to some remote consumer that speaks ProtoBuf, and has a ready-to-use ProtoBuf schema.
You say that like it's not still happening... VB6 is still the go-to tool at a certain blue cross and blue shield franchise - and probably at many others around the country. They post jobs(active postings right now) for .NET developers with VB6 experience. They do it under the guise to "help port existing applications", but in reality they are still developing new features with it, and will likely never stop.