28 ms·

The chronic suffering of the VB.NET community

118 points by myu701 7y ago

gus_massa 7y ago
As a VBClasic user that never made the transition to VB#.NET, a wish you the best but I loose my hopes a long time ago.
- w3mmpp 7y ago
  Out of curiosity, do you develop professionally in VB classic?
  - foepys 7y ago
    I know somebody that does. It's working surprisingly well considering that it has been deprecated since 2001. Interop with C# is working fine and as long as don't have to do too much in the VB part of your program, you can just use it as a "library" (which is technically isn't because you should only call C# from VB, not the other way around). The only two disadvantages I know of are restriction to 32-bit and no easy CI/CD support. Maybe also that it doesn't support HiDPI forms and Windows just scales it up but who is really expecting that from a 90s technology?
    - w3mmpp 7y ago
      Yes, and I guess it could also be ran into a VM with Windows 95-98 or that other open source clone, can't remember the name now and still be useful.
      - jacobush 7y ago
        Wine + Linux and ReactOS would work equally well. Wine would probably be easier to setup.
  - aliswe 7y ago
    Anecdote: I remember in 2007 or '08 a colleague was assigned to Ericsson, to work on a time reporting "application" made in VBA, contained in a gigantic Excel spreadsheet. I also assisted in some troubleshooting. It was called Tratten, swedish for "the funnel", and I remember him telling me that when he presented it to some kind of stakeholder board and when said "sometimes, the application gives a 'read error'" and the whole board reverberated "read error?!" amongst themselves ...
  - vb6sp6 7y ago
    I do. We build a desktop app used by businesses around the world, including some mentioned regularly on hacker news :) At the time we stared (1999), vb seemed like a great choice for desktop apps: It had a ton of built-in controls for building UIs, it was quick and easy to do so, and there were tons of dlls and ocxes we could tap into from a ton of different vendors. The vb language was also appealing on a larger scale because you could take existing knowledge to other areas of the windows ecosystem: excel\outlook automation, classic asp if you need web stuff, windows automation\administration, and ie scripting. MSDN was also an incredible learning resource I attended a few small group sessions with microsoft in the early days of .net and we were planing on migrating ~100k lines based on what we were being shown. It looked awesome. I managed to get hold of an early beta version and did the obligatory "hello world" and was gut punched. It took a few seconds to load took like 20ish mb of ram. It seems laughable by today's standards, but in 2000 our target customers were still clinging to win98 and the pc's generally had garbage specs. IT people were livid we were wasting 4mb of their ram to run the vb6 version of our app. We lost sales and spent hours on the phone justifying our ram usage (fun times). A 5x increase in ram was completely unacceptable so we put it on hold in hopes that the release would improve things. Things didn't improve so we put the plans on hold in hopes that vb7 would get released or they would reduce the runtime requirements. Then something really strange happened: We almost lost a sale because the IT guy thought we were using .net and he refused to install the .net framework because it "used too much disk". I had to take 2 meetings with this guy and was literally screaming into the "WE DONT FUCKING USE THE .NET FRAMEWORK, DONT FUCKING INSTALL IT, WE DONT USE IT". And this wasn't the only incident. I'd get pulled into calls and would have to talk irate IT guys down from the ledge and assure them that no .net framework was required to run our program. Today, things are much different, no one cares about using gigs of ram or hundreds of gigs of disk space. But there is a new set of problems trying to explain how a desktop app works to someone who only knows how to admin web apps. And the .net framework eventually become ubiquitous via windows updates and other, more critical software, starting to require it. But the early days were really, really odd (at least for us and our customers). We aren't complete luddites though. We do utilize some .net (asp.net\vb.net) on the server side for a few tools. We have a mobile app (xamarin\c#) that has some companion features, raspberry pi (python) for some "smart" displays, Arduino, and have started to look at blazor to the replace the desktop app. I might still recommend vb6 for a desktop app with the caveat that it is a pain in the ass to install on later versions of windows. tldr: vb6 mostly just works and is a great tool for desktop apps
- bluedino 7y ago
  I've ran into it at a couple jobs in the last decade, there's more VB code out there than people might expect.
smacktoward 7y ago
As someone who was a VB developer back when VB.NET first shipped twenty years ago, I'm kind of surprised by this. VB.NET was very clearly a second-class citizen in the .NET ecosystem even back then. While Microsoft paid lip service to supporting it equally with C#, it was very clear from the huge volume of documentation, tutorials, books, etc. they put out for C# compared to the tiny volume for VB.NET that C# was where they really wanted developers to be. And syntactically VB.NET felt more like C#-with-training-wheels than "classic" VB anyway, which reinforced the impression. Given how big C# ended up becoming, I'm wondering why anyone committed to staying in the .NET ecosystem would have stuck with VB.NET all this time. What's the attraction? I could see it as a transitional stage to get classic VB developers started on the road to C#, but as a long-term solution it seemed doomed to chronic suffering from birth.
- danielbarla 7y ago
  I remember this slightly differently; the change to C# was swift and rather brutal, but VB.Net was very much the default choice for most organisations transitioning from VB. In 2001-2002, seeing C# in production eluded a response along the lines of "wow, you guys are quite brave, kudos". By 2003-2004 though, the switchover had pretty much happened, nevertheless there were still swathes of legacy code to be maintained. At least, this was my experience in the handful of companies I worked with around then. I've seen several moderately large and active projects (5+ developer maintenance team) still surviving to this day, running on VB.Net. In most cases though, these were started in the mid-2000s, simply due to manpower questions, not language advantages. I recall being moderately surprised even circa 2008 that the author of CSLA.Net (an interesting object-oriented framework) was mostly using VB.Net. I guess from their point of view, they were more proficient in that languages, and the cost of switching was too high. I definitely don't see any rationale for benefits, akin to say F# vs C#.
  - jeremyjh 7y ago
    That is how it was for my shop too but honestly I think the semantics of VB.NET was always closer to C# than it was to VB 6. I remember working on a mixed code-base and it was absolutely effort-less because the semantics and of course the libraries were all identical, you just had to switch syntax. Syntax isn't really what takes time to learn in coming up to speed in a new language; what takes more time is language concepts, semantics, APIs and tooling. Once you realize this and observe the fact that C# is winning mind-share there didn't really seem to be any need for VB.NET. It really seems to me like it should have been stopped entirely ~2006 but Microsoft just doesn't do that to products, to their credit in most cases.
nxc18 7y ago
I’d advocate for the opposite: VB is never going to get first class support. It was clear that I should jump ship when first learning it back in 2010. Microsoft should just kill it (aka put it into mature support) and give clear guidance that developers should move on. If you can learn and understand VB.NET you can learn and understand C#. It’s time to rip the band aid off.
rufius 7y ago
Why uhhh... why wouldn’t people just start writing new components in C#. Surely learning C# is not beyond them? It’s not like there’s a compatibility issue. Just stop writing it.
- czechdeveloper 7y ago
  There are 1 to 1 transpilers between languages (with few exceptions such as LINQ to XML in VB) that are really good. I've migrated hundreds of thousands lines of VB to C# in past years.
  - aljarry 7y ago
    Had similar experience - I transpiled a ~120kLOC legacy winforms app in day and a half - mostly spent fixing build errors between not exactly translatable elements / missing rules in transpiler.
- contextfree 7y ago
  what if they don't want to?
  - eropple 7y ago
    They're welcome to maintain their own ecosystem. Microsoft made it clear over a decade ago that VB.NET was symptomatic treatment at best.
  - chrisseaton 7y ago
    Are they going to pay Microsoft enough to maintain VB.NET just for them? Or they could re-implement and maintain VB.NET themselves? Those are their options. You can't just demand that someone provide you a product if they don't want to.
greatjack613 7y ago
As someone who started programming in VB.NET, this is so true. It was a great language for beginners that also had enough oomph to build commercial applications, everyone who I spoke to who actually used it loved it. Why a 1 trillion dollar company like microsoft can't hire 5 dedicated devs is beyond me.
- aliswe 7y ago
  That goes back to if the decision to assign them is strategic, or not. If they wish to deprecate the language, it will not be done. Also one could argue that that small code change which took 5 minutes could have cost the company hundreds of hours supporting their clients if something happened. So that would make that very small change a very big change, not based on effort but on impact.
Someone1234 7y ago
It likely takes 3-5 developers just to maintain what they already have until end of life. Whenever people come up with these tiny estimates for how much "effort" things take they ignore the organizational overhead and maintenance costs. For example, when changes are made to the CTS/CLS[0] a lot of time is spent considering how those changes will impact other .Net languages, that's a cost/overhead even without actual work on those languages. So it might take "3-5 people to keep VB.Net alive" but only if you ignore the man-hours lost in other teams (.Net Framework, Tooling, Libraries, etc) and the people already required to maintain existing VB.Net Support (3-5~). 15-20 people is a more realistic conservative estimate. Plus the language's popularity is almost gone: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F01dpgv,VB.net,C%23 https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0... [0] https://docs.microsoft.com/en-us/dotnet/standard/common-type-system https://docs.microsoft.com/en-us/dotnet/standard/common-type...
- nv-vn 7y ago
  With the interest fading so much, I think Microsoft probably just wants to nix the project as something official. While it's not expensive for them to maintain, I imagine they don't want to be tied to a dying product like that. They probably want to actively discourage development of VB because VB does not fit into their vision of the .NET ecosystem anymore. I think that's the point the author is missing here.
- phillipcarter 7y ago
  The author worked on the team for 8 years, including the transition to Roslyn which unified much of the expensive concerns around VB.NET and C#. It's the author's extremely strong familiarity with that engineering system that led to their claim. In the post he walks through how team sizes grew significantly smaller across the board. 15-20 people would be far larger than the current C# language/compiler team.
nv-vn 7y ago
One thing the author failed to consider when discussing F# was that F#'s community leans heavily towards compiler/programming language people. Historically, MLs have been extremely popular for writing compilers and a lot of the folks using F# today either come from that background or have been exposed to people from that background and learned about some aspects of compilers. I would wager that maybe 25% of F# users are _capable_ of somehow contributing to the F# compiler compared to maybe 5-10% for C# and VB.NET. I also imagine the F# compiler's source code to be drastically smaller and simpler given both its history and the ease of writing compilers in F#.
- josteink 7y ago
  Edit: disregard
  - contextfree 7y ago
    The VB compiler is written in VB: https://github.com/dotnet/roslyn/tree/master/src/Compilers/VisualBasic/Portable https://github.com/dotnet/roslyn/tree/master/src/Compilers/V...
  - deleted 7y ago
    [deleted]
- Arnavion 7y ago
  >I also imagine the F# compiler's source code to be drastically smaller and simpler given both its history and the ease of writing compilers in F#. I agree that the F# compiler's codebase is much smaller than C# (wc suggests 417k lines for dotnet/roslyn:src/Compilers/CSharp/ vs 190k lines for dotnet/fsharp:src/, which is hopefully all the right files). But as far as simpler goes, the compiler is quite a bit complicated by having to implement F# in terms of .Net. Enum variants are actually classes inheriting from the class representing the enum, modules are actually classes, core library members being called by different names in F# vs not, the desugaring of computation expressions into state machines, ... Then there's F#-specific stuff, like the core library, having two different kinds of parsers (#light on and off), two different kinds of generics, quotations, ...
- 7y ago
kstrauser 7y ago
I worked for a shop that was heavily invested in Visual FoxPro, after that time had come and gone. I spent a few years switching most stuff to Python and PostgreSQL, then moved to another city. When I checked in with some friends from there to say hi, I found out that they'd replaced all my "weird Python stuff" with good, standard VB.Net (starting in 2013). I didn't know whether to laugh or cry (with strong leanings toward the latter). It's too bad. I love that company and the people there, but I'd like to smack the person who convinced them to go for that particular rewrite, or at least make fun of them in public.
- eitland 7y ago
  The obvious choice for anyone who has tried a few languages should probably have been C#, but personally, if it was my choice to make and the team was experienced in Visual Foxpro I'd probably choose VB.Net if they wanted it. The alternative would be C#. Full disclosure: Languages sorted by when I learned them: - Basic - Visual Basic - C - Assembly - Java (well, I "learned" that I was hopelessly ineffective with it. Still got a B.) - Javascript - Python - PHP - AutoHotKey - Java (actually learned it) - Perl - Delphi - C# - VB.Net Reasons: Once I actually understood the value of a real typed language there's no way I'll go back except for scripting and small one-offs.
  - kstrauser 7y ago
    Thing is, there was only one person there who was really maintaining the VFP stuff. We'd already done the switch for everything else. I agree about strongly typed languages. I'd never give Python and its strong typing to switch to a scripting language.
- smacktoward 7y ago
  The hitch there is that there's not so much an ecosystem for individual Microsoft products as there is a Microsoft ecosystem, where all the products are puzzle pieces that snap into each other. So if you're in that ecosystem and a Microsoft product you're currently using stops being available, there will be a strong gravitational pull drawing you towards other Microsoft products to fill the gap. You can fight that tendency by bringing in non-Microsoft products, but even if they're much better than the MS alternatives, MS people are always going to feel weird about using them. It's like telling them to defy gravity by standing on a chair all day.
mellosouls 7y ago
"Chronic suffering" seems a wee bit hyperbolic, especially in the current apocalyptic climate. Perspective, please. OT I remember when VB.Net first came out and some VB6 devs were rather sniffily referring to it as "Visual Fred" due to the lack of resemblance wth VB beyond keywords. It was obvious from the get go VB was now a second class citizen, and c# was the future...
- wvenable 7y ago
  VB.NET's only purpose should have been 99% compatibility with VB6. Instead, it was too much like C# to be compatible and too much like VB6 to be consistent. I had lot of experience with VB6 back in the day but I moved straight to C#.
alkonaut 7y ago
VB is dead. Get over it. It was a concession to an army of classic VB devs to not risk losing them to other technology when .NET and C# were born. Since then, every VB develooper has had two decades to realize that VB.NET never was a "new VB", but just a C# dialect. It offers zero value over C#, and it's so closely related that anyone who knows VB.NET can pick up C# instead in literally no time at all. I don't see why the author brings up F#. F# is just as much a second class citizen in the .NET world, but it is a project of a great community and of ms research.
- nradov 7y ago
  For better or worse, VB is still very much alive as an embedded language inside Office. It hasn't been enhanced in years but it probably won't be removed any time soon.
  - marcus_holmes 7y ago
    is VBA the same as VB.Net? I thought there were differences?
    - nradov 7y ago
      It's almost completely different. There is only some superficial similarity in syntax.
    - TheRealWatson 7y ago
      VBA is a dialect that sits roughly between VBScript and VB6, both defunct technologies.
      - nradov 7y ago
        VBA syntax and standard library is nearly identical to VB6.
- runevault 7y ago
  F# is an interesting case. It's a second class citizen but it's also the testing ground for a lot of features that end up in c#
uk_programmer 7y ago
VB gets a lot of hate. But the language is perfectly fine for the most part. One of the most annoying things about VB.NET is that projects need to be configured with certain options out of the box otherwise it allows you to write some very sloppy code. I still use VB.NET for creating quick tooling for either myself or non-technical users. There doesn't appear to be anything else really these days for doing that. The newer options from Microsoft tend to enforce a lot of patterns, which just slow you down, when for small tools you don't really require all that guff. I hope with an open source .NET compiler it will be possible VB.NET to carry on well beyond Microsoft's culling.
manigandham 7y ago
A decade too late. This is like complaining that Flash and ActiveX are gone. The world has moved on. C# is easy enough to learn and unless there's maintenance required on legacy code, it's irresponsible to continue using VB on any new projects.
- swiley 7y ago
  When was it ever responsible to use VB on new projects for anything more than hacking excel?
  - smacktoward 7y ago
    Don't confuse VB with VBA (Visual Basic for Applications, e.g. Excel's scripting language). VB was super-useful for building things like graphical frontends for databases, back when such things were typically delivered as desktop applications rather than web applications.
    - benbristow 7y ago
      You can still do WPF/Windows Forms with C# if you wish just as you would in VB. Drag and drop and double click to write code, all that good stuff. Probably better to just go web-based nowadays though for the instant portability of targeting all of desktop/mobile/tablet all in one go unless you have a reason not to
      - smacktoward 7y ago
        Right, you can do that stuff with modern tools, but there's just not nearly as much demand for it these days. And back when there was demand for it, VB was among the best tools available to do that job.
    - ptx 7y ago
      VBA is the exact same language as VB 6, with the same implementation and the same IDE. It lacks some options (like compiling to an executable and setting some module attributes) and the forms library is different, but the language is identical. Since diverging, VBA has had some small revisions, with VBA 7 adding support for 64-bit pointers. You might be confusing it with VBScript, Microsoft's old vaguely VB-like alternative to JavaScript that was used in Internet Explorer and (I think) classic ASP.
60secz 7y ago
> I am a PURE VB.NET developer. I have never used any other language full-time for any significant portion of my education or career—a client project here or there but nothing that somehow made me NOT a VB developer. How am I supposed to engage?" Every developer should be polyglot. Adapt or die.
- smacktoward 7y ago
  I dunno, there are plenty of slices of the programming world where you can quite profitably work in a single language for most or even all of your career. If you specialized in Java twenty years ago, you'd have skills that are still in demand today and will likely still be in demand twenty years from now (as long as you keep current with changes to the platform). But betting your career on a single language is definitely a big bet. And any bettor will tell you one of the key skills is knowing when to cut your losses.
  - balfirevic 7y ago
    It's fine to happen to develop (or only have developed) in a single language - you might have found your niche and all that. But the way the author of the article put it is just so weird - choosing the word "pure" in all caps - like it's a point of pride, or big part of their identity.
  - to11mtm 7y ago
    Java is a bit different though. Whatever we think of 'enterprisey', it does mean that a lot of systems were built with it with the expectation it would be around a long time. As far as 'bets' go, it's also a bet on oneself. The skills of an 'average' developer between two languages can have notable differences in concepts and requirements. i.e. I'd be a bit curious about an 'Average' C/C++ Developer who couldn't write a linked list (or at least groks them), versus an 'Average' C# or Java developer who may never have to write one in their career. I'll say that unless you intend to be a hardcore Systems developer or Finance Sector, Javascript is never a bad thing to at least learn enough of to at least pass equality questions on interviews. The nice thing about learning other languages however is that it may help expose you to patterns you don't normally see in your main language, or may expose you to things that make it easier to understand certain concepts (i.e. doing Javascript sites with KnockoutJS helped me learn better MVVM practices, as well as concepts like observables which I could then use back in C#)
asdfman123 7y ago
They make the argument that it would take very little effort for MS to maintain VB.NET. If that's true, I wonder if part of the reason MS is killing VB is that it doesn't serve any necessary purpose, and it is simply uncool. I wonder if "uncoolness" is a primary factor. It sounds silly to write, but think about it -- technologies live and die by coolness. MS is doing everything they can right now to shake off their uncool past, and VB is certainly a relic of the uncool past. Developer share is crucial. You get a lot of developer share by being cool. Thus, being cool is very important. Damn, I want to drop a Medium article on hackernews now with my hot new take.
kelvin0 7y ago
Imagine how the poor Fortan and Cobol devs feel.
- vb6sp6 7y ago
  I imagine they feel pretty good considering the type of money they make
  - chrisseaton 7y ago
    Is there a lot of money in Fortran? Anyone could learn Fortran in a week if they wanted, and there's tons of research assistants who know it already. How's it lucrative?
  - insulanian 7y ago
    Is that really true, or is it just a myth?
ourmandave 7y ago
My take away from this is either: 1. Start a go-fund-me to get a VB.net team started. 2. Start work on an open source VB.net to F# transpiler.
benjamoon 7y ago
We're a .NET dev company (all C# coders, but most of us have a background in VB as well), I asked my team if they had to choose would they rather have to develop with: A: C#, but with WebForms (including using code behind and the built in web controls where possible). or B: VB, but with MVC and WebApi. They all chose C# WebForms even though they all hate WebForms, just not as much as they hate VB. Personally I love VB and WebForms, I never get to do work with it nowadays (I'm not even sure we have any legacy systems that still run it), but I built my company from scratch off that stack and coming from a classic ASP background I was blown away with controls like GridView and Repeaters etc. I remember our first designer being so confused with the mess of html outputted by these controls and the hatred our purists had for viewstate that polluted their lightweight designs. I still remember how excited I was when I first used the AjaxControlToolkit and the UpdatePanel control, it was like magic! Now everything's pretty much all C#, RazorPages, WebApi, Angular or Vue and I'd never go back, but I do miss the old days. It's not often I see tech that seems magical any more, SignalR was probably the last big thing that blew me away in terms of just doing something that felt so different, but it's really rare now. I would add that we just finished a prototype app for a client using Blazor WASM and coding that did seem like witchcraft and certainly brought back some of the old feelings of being amazed, maybe we'll all look back on javascript frameworks in the same way we look back on VB in a couple of years if Blazor play outs.
jbn 7y ago
I don't even like VB, but this is a great read. Very informative. The author clearly points out that the deficiencies of the organization that sign the death warrant of VB.NET, regardless of the intrinsic value of that language/compiler/environment.

118 points by myu701 7y ago

gus_massa 7y ago

As a VBClasic user that never made the transition to VB#.NET, a wish you the best but I loose my hopes a long time ago.

w3mmpp 7y ago
Out of curiosity, do you develop professionally in VB classic?
- foepys 7y ago
  I know somebody that does. It's working surprisingly well considering that it has been deprecated since 2001. Interop with C# is working fine and as long as don't have to do too much in the VB part of your program, you can just use it as a "library" (which is technically isn't because you should only call C# from VB, not the other way around). The only two disadvantages I know of are restriction to 32-bit and no easy CI/CD support. Maybe also that it doesn't support HiDPI forms and Windows just scales it up but who is really expecting that from a 90s technology?
  - w3mmpp 7y ago
    Yes, and I guess it could also be ran into a VM with Windows 95-98 or that other open source clone, can't remember the name now and still be useful.
    - jacobush 7y ago
      Wine + Linux and ReactOS would work equally well. Wine would probably be easier to setup.
- aliswe 7y ago
  Anecdote: I remember in 2007 or '08 a colleague was assigned to Ericsson, to work on a time reporting "application" made in VBA, contained in a gigantic Excel spreadsheet. I also assisted in some troubleshooting. It was called Tratten, swedish for "the funnel", and I remember him telling me that when he presented it to some kind of stakeholder board and when said "sometimes, the application gives a 'read error'" and the whole board reverberated "read error?!" amongst themselves ...
- vb6sp6 7y ago
  I do. We build a desktop app used by businesses around the world, including some mentioned regularly on hacker news :) At the time we stared (1999), vb seemed like a great choice for desktop apps: It had a ton of built-in controls for building UIs, it was quick and easy to do so, and there were tons of dlls and ocxes we could tap into from a ton of different vendors. The vb language was also appealing on a larger scale because you could take existing knowledge to other areas of the windows ecosystem: excel\outlook automation, classic asp if you need web stuff, windows automation\administration, and ie scripting. MSDN was also an incredible learning resource I attended a few small group sessions with microsoft in the early days of .net and we were planing on migrating ~100k lines based on what we were being shown. It looked awesome. I managed to get hold of an early beta version and did the obligatory "hello world" and was gut punched. It took a few seconds to load took like 20ish mb of ram. It seems laughable by today's standards, but in 2000 our target customers were still clinging to win98 and the pc's generally had garbage specs. IT people were livid we were wasting 4mb of their ram to run the vb6 version of our app. We lost sales and spent hours on the phone justifying our ram usage (fun times). A 5x increase in ram was completely unacceptable so we put it on hold in hopes that the release would improve things. Things didn't improve so we put the plans on hold in hopes that vb7 would get released or they would reduce the runtime requirements. Then something really strange happened: We almost lost a sale because the IT guy thought we were using .net and he refused to install the .net framework because it "used too much disk". I had to take 2 meetings with this guy and was literally screaming into the "WE DONT FUCKING USE THE .NET FRAMEWORK, DONT FUCKING INSTALL IT, WE DONT USE IT". And this wasn't the only incident. I'd get pulled into calls and would have to talk irate IT guys down from the ledge and assure them that no .net framework was required to run our program. Today, things are much different, no one cares about using gigs of ram or hundreds of gigs of disk space. But there is a new set of problems trying to explain how a desktop app works to someone who only knows how to admin web apps. And the .net framework eventually become ubiquitous via windows updates and other, more critical software, starting to require it. But the early days were really, really odd (at least for us and our customers). We aren't complete luddites though. We do utilize some .net (asp.net\vb.net) on the server side for a few tools. We have a mobile app (xamarin\c#) that has some companion features, raspberry pi (python) for some "smart" displays, Arduino, and have started to look at blazor to the replace the desktop app. I might still recommend vb6 for a desktop app with the caveat that it is a pain in the ass to install on later versions of windows. tldr: vb6 mostly just works and is a great tool for desktop apps
bluedino 7y ago
I've ran into it at a couple jobs in the last decade, there's more VB code out there than people might expect.

smacktoward 7y ago

As someone who was a VB developer back when VB.NET first shipped twenty years ago, I'm kind of surprised by this. VB.NET was very clearly a second-class citizen in the .NET ecosystem even back then. While Microsoft paid lip service to supporting it equally with C#, it was very clear from the huge volume of documentation, tutorials, books, etc. they put out for C# compared to the tiny volume for VB.NET that C# was where they really wanted developers to be. And syntactically VB.NET felt more like C#-with-training-wheels than "classic" VB anyway, which reinforced the impression. Given how big C# ended up becoming, I'm wondering why anyone committed to staying in the .NET ecosystem would have stuck with VB.NET all this time. What's the attraction? I could see it as a transitional stage to get classic VB developers started on the road to C#, but as a long-term solution it seemed doomed to chronic suffering from birth.

danielbarla 7y ago
I remember this slightly differently; the change to C# was swift and rather brutal, but VB.Net was very much the default choice for most organisations transitioning from VB. In 2001-2002, seeing C# in production eluded a response along the lines of "wow, you guys are quite brave, kudos". By 2003-2004 though, the switchover had pretty much happened, nevertheless there were still swathes of legacy code to be maintained. At least, this was my experience in the handful of companies I worked with around then. I've seen several moderately large and active projects (5+ developer maintenance team) still surviving to this day, running on VB.Net. In most cases though, these were started in the mid-2000s, simply due to manpower questions, not language advantages. I recall being moderately surprised even circa 2008 that the author of CSLA.Net (an interesting object-oriented framework) was mostly using VB.Net. I guess from their point of view, they were more proficient in that languages, and the cost of switching was too high. I definitely don't see any rationale for benefits, akin to say F# vs C#.
- jeremyjh 7y ago
  That is how it was for my shop too but honestly I think the semantics of VB.NET was always closer to C# than it was to VB 6. I remember working on a mixed code-base and it was absolutely effort-less because the semantics and of course the libraries were all identical, you just had to switch syntax. Syntax isn't really what takes time to learn in coming up to speed in a new language; what takes more time is language concepts, semantics, APIs and tooling. Once you realize this and observe the fact that C# is winning mind-share there didn't really seem to be any need for VB.NET. It really seems to me like it should have been stopped entirely ~2006 but Microsoft just doesn't do that to products, to their credit in most cases.

nxc18 7y ago

I’d advocate for the opposite: VB is never going to get first class support. It was clear that I should jump ship when first learning it back in 2010. Microsoft should just kill it (aka put it into mature support) and give clear guidance that developers should move on. If you can learn and understand VB.NET you can learn and understand C#. It’s time to rip the band aid off.

rufius 7y ago

Why uhhh... why wouldn’t people just start writing new components in C#. Surely learning C# is not beyond them? It’s not like there’s a compatibility issue. Just stop writing it.

czechdeveloper 7y ago
There are 1 to 1 transpilers between languages (with few exceptions such as LINQ to XML in VB) that are really good. I've migrated hundreds of thousands lines of VB to C# in past years.
- aljarry 7y ago
  Had similar experience - I transpiled a ~120kLOC legacy winforms app in day and a half - mostly spent fixing build errors between not exactly translatable elements / missing rules in transpiler.
contextfree 7y ago
what if they don't want to?
- eropple 7y ago
  They're welcome to maintain their own ecosystem. Microsoft made it clear over a decade ago that VB.NET was symptomatic treatment at best.
- chrisseaton 7y ago
  Are they going to pay Microsoft enough to maintain VB.NET just for them? Or they could re-implement and maintain VB.NET themselves? Those are their options. You can't just demand that someone provide you a product if they don't want to.

greatjack613 7y ago

As someone who started programming in VB.NET, this is so true. It was a great language for beginners that also had enough oomph to build commercial applications, everyone who I spoke to who actually used it loved it. Why a 1 trillion dollar company like microsoft can't hire 5 dedicated devs is beyond me.

aliswe 7y ago
That goes back to if the decision to assign them is strategic, or not. If they wish to deprecate the language, it will not be done. Also one could argue that that small code change which took 5 minutes could have cost the company hundreds of hours supporting their clients if something happened. So that would make that very small change a very big change, not based on effort but on impact.

Someone1234 7y ago

It likely takes 3-5 developers just to maintain what they already have until end of life. Whenever people come up with these tiny estimates for how much "effort" things take they ignore the organizational overhead and maintenance costs. For example, when changes are made to the CTS/CLS[0] a lot of time is spent considering how those changes will impact other .Net languages, that's a cost/overhead even without actual work on those languages. So it might take "3-5 people to keep VB.Net alive" but only if you ignore the man-hours lost in other teams (.Net Framework, Tooling, Libraries, etc) and the people already required to maintain existing VB.Net Support (3-5~). 15-20 people is a more realistic conservative estimate. Plus the language's popularity is almost gone: https://trends.google.com/trends/explore?date=all&q=%2Fm%2F01dpgv,VB.net,C%23 https://trends.google.com/trends/explore?date=all&q=%2Fm%2F0... [0] https://docs.microsoft.com/en-us/dotnet/standard/common-type-system https://docs.microsoft.com/en-us/dotnet/standard/common-type...

nv-vn 7y ago
With the interest fading so much, I think Microsoft probably just wants to nix the project as something official. While it's not expensive for them to maintain, I imagine they don't want to be tied to a dying product like that. They probably want to actively discourage development of VB because VB does not fit into their vision of the .NET ecosystem anymore. I think that's the point the author is missing here.
phillipcarter 7y ago
The author worked on the team for 8 years, including the transition to Roslyn which unified much of the expensive concerns around VB.NET and C#. It's the author's extremely strong familiarity with that engineering system that led to their claim. In the post he walks through how team sizes grew significantly smaller across the board. 15-20 people would be far larger than the current C# language/compiler team.

nv-vn 7y ago

One thing the author failed to consider when discussing F# was that F#'s community leans heavily towards compiler/programming language people. Historically, MLs have been extremely popular for writing compilers and a lot of the folks using F# today either come from that background or have been exposed to people from that background and learned about some aspects of compilers. I would wager that maybe 25% of F# users are _capable_ of somehow contributing to the F# compiler compared to maybe 5-10% for C# and VB.NET. I also imagine the F# compiler's source code to be drastically smaller and simpler given both its history and the ease of writing compilers in F#.

josteink 7y ago
Edit: disregard
- contextfree 7y ago
  The VB compiler is written in VB: https://github.com/dotnet/roslyn/tree/master/src/Compilers/VisualBasic/Portable https://github.com/dotnet/roslyn/tree/master/src/Compilers/V...
- deleted 7y ago
  [deleted]
Arnavion 7y ago
>I also imagine the F# compiler's source code to be drastically smaller and simpler given both its history and the ease of writing compilers in F#. I agree that the F# compiler's codebase is much smaller than C# (wc suggests 417k lines for dotnet/roslyn:src/Compilers/CSharp/ vs 190k lines for dotnet/fsharp:src/, which is hopefully all the right files). But as far as simpler goes, the compiler is quite a bit complicated by having to implement F# in terms of .Net. Enum variants are actually classes inheriting from the class representing the enum, modules are actually classes, core library members being called by different names in F# vs not, the desugaring of computation expressions into state machines, ... Then there's F#-specific stuff, like the core library, having two different kinds of parsers (#light on and off), two different kinds of generics, quotations, ...
7y ago

kstrauser 7y ago

I worked for a shop that was heavily invested in Visual FoxPro, after that time had come and gone. I spent a few years switching most stuff to Python and PostgreSQL, then moved to another city. When I checked in with some friends from there to say hi, I found out that they'd replaced all my "weird Python stuff" with good, standard VB.Net (starting in 2013). I didn't know whether to laugh or cry (with strong leanings toward the latter). It's too bad. I love that company and the people there, but I'd like to smack the person who convinced them to go for that particular rewrite, or at least make fun of them in public.

eitland 7y ago
The obvious choice for anyone who has tried a few languages should probably have been C#, but personally, if it was my choice to make and the team was experienced in Visual Foxpro I'd probably choose VB.Net if they wanted it. The alternative would be C#. Full disclosure: Languages sorted by when I learned them: - Basic - Visual Basic - C - Assembly - Java (well, I "learned" that I was hopelessly ineffective with it. Still got a B.) - Javascript - Python - PHP - AutoHotKey - Java (actually learned it) - Perl - Delphi - C# - VB.Net Reasons: Once I actually understood the value of a real typed language there's no way I'll go back except for scripting and small one-offs.
- kstrauser 7y ago
  Thing is, there was only one person there who was really maintaining the VFP stuff. We'd already done the switch for everything else. I agree about strongly typed languages. I'd never give Python and its strong typing to switch to a scripting language.
smacktoward 7y ago
The hitch there is that there's not so much an ecosystem for individual Microsoft products as there is a Microsoft ecosystem, where all the products are puzzle pieces that snap into each other. So if you're in that ecosystem and a Microsoft product you're currently using stops being available, there will be a strong gravitational pull drawing you towards other Microsoft products to fill the gap. You can fight that tendency by bringing in non-Microsoft products, but even if they're much better than the MS alternatives, MS people are always going to feel weird about using them. It's like telling them to defy gravity by standing on a chair all day.

mellosouls 7y ago

"Chronic suffering" seems a wee bit hyperbolic, especially in the current apocalyptic climate. Perspective, please. OT I remember when VB.Net first came out and some VB6 devs were rather sniffily referring to it as "Visual Fred" due to the lack of resemblance wth VB beyond keywords. It was obvious from the get go VB was now a second class citizen, and c# was the future...

wvenable 7y ago
VB.NET's only purpose should have been 99% compatibility with VB6. Instead, it was too much like C# to be compatible and too much like VB6 to be consistent. I had lot of experience with VB6 back in the day but I moved straight to C#.

alkonaut 7y ago

VB is dead. Get over it. It was a concession to an army of classic VB devs to not risk losing them to other technology when .NET and C# were born. Since then, every VB develooper has had two decades to realize that VB.NET never was a "new VB", but just a C# dialect. It offers zero value over C#, and it's so closely related that anyone who knows VB.NET can pick up C# instead in literally no time at all. I don't see why the author brings up F#. F# is just as much a second class citizen in the .NET world, but it is a project of a great community and of ms research.

nradov 7y ago
For better or worse, VB is still very much alive as an embedded language inside Office. It hasn't been enhanced in years but it probably won't be removed any time soon.
- marcus_holmes 7y ago
  is VBA the same as VB.Net? I thought there were differences?
  - nradov 7y ago
    It's almost completely different. There is only some superficial similarity in syntax.
  - TheRealWatson 7y ago
    VBA is a dialect that sits roughly between VBScript and VB6, both defunct technologies.
    - nradov 7y ago
      VBA syntax and standard library is nearly identical to VB6.
runevault 7y ago
F# is an interesting case. It's a second class citizen but it's also the testing ground for a lot of features that end up in c#

uk_programmer 7y ago

VB gets a lot of hate. But the language is perfectly fine for the most part. One of the most annoying things about VB.NET is that projects need to be configured with certain options out of the box otherwise it allows you to write some very sloppy code. I still use VB.NET for creating quick tooling for either myself or non-technical users. There doesn't appear to be anything else really these days for doing that. The newer options from Microsoft tend to enforce a lot of patterns, which just slow you down, when for small tools you don't really require all that guff. I hope with an open source .NET compiler it will be possible VB.NET to carry on well beyond Microsoft's culling.

manigandham 7y ago

A decade too late. This is like complaining that Flash and ActiveX are gone. The world has moved on. C# is easy enough to learn and unless there's maintenance required on legacy code, it's irresponsible to continue using VB on any new projects.

swiley 7y ago
When was it ever responsible to use VB on new projects for anything more than hacking excel?
- smacktoward 7y ago
  Don't confuse VB with VBA (Visual Basic for Applications, e.g. Excel's scripting language). VB was super-useful for building things like graphical frontends for databases, back when such things were typically delivered as desktop applications rather than web applications.
  - benbristow 7y ago
    You can still do WPF/Windows Forms with C# if you wish just as you would in VB. Drag and drop and double click to write code, all that good stuff. Probably better to just go web-based nowadays though for the instant portability of targeting all of desktop/mobile/tablet all in one go unless you have a reason not to
    - smacktoward 7y ago
      Right, you can do that stuff with modern tools, but there's just not nearly as much demand for it these days. And back when there was demand for it, VB was among the best tools available to do that job.
  - ptx 7y ago
    VBA is the exact same language as VB 6, with the same implementation and the same IDE. It lacks some options (like compiling to an executable and setting some module attributes) and the forms library is different, but the language is identical. Since diverging, VBA has had some small revisions, with VBA 7 adding support for 64-bit pointers. You might be confusing it with VBScript, Microsoft's old vaguely VB-like alternative to JavaScript that was used in Internet Explorer and (I think) classic ASP.

60secz 7y ago

> I am a PURE VB.NET developer. I have never used any other language full-time for any significant portion of my education or career—a client project here or there but nothing that somehow made me NOT a VB developer. How am I supposed to engage?" Every developer should be polyglot. Adapt or die.

smacktoward 7y ago
I dunno, there are plenty of slices of the programming world where you can quite profitably work in a single language for most or even all of your career. If you specialized in Java twenty years ago, you'd have skills that are still in demand today and will likely still be in demand twenty years from now (as long as you keep current with changes to the platform). But betting your career on a single language is definitely a big bet. And any bettor will tell you one of the key skills is knowing when to cut your losses.
- balfirevic 7y ago
  It's fine to happen to develop (or only have developed) in a single language - you might have found your niche and all that. But the way the author of the article put it is just so weird - choosing the word "pure" in all caps - like it's a point of pride, or big part of their identity.
- to11mtm 7y ago
  Java is a bit different though. Whatever we think of 'enterprisey', it does mean that a lot of systems were built with it with the expectation it would be around a long time. As far as 'bets' go, it's also a bet on oneself. The skills of an 'average' developer between two languages can have notable differences in concepts and requirements. i.e. I'd be a bit curious about an 'Average' C/C++ Developer who couldn't write a linked list (or at least groks them), versus an 'Average' C# or Java developer who may never have to write one in their career. I'll say that unless you intend to be a hardcore Systems developer or Finance Sector, Javascript is never a bad thing to at least learn enough of to at least pass equality questions on interviews. The nice thing about learning other languages however is that it may help expose you to patterns you don't normally see in your main language, or may expose you to things that make it easier to understand certain concepts (i.e. doing Javascript sites with KnockoutJS helped me learn better MVVM practices, as well as concepts like observables which I could then use back in C#)

asdfman123 7y ago

They make the argument that it would take very little effort for MS to maintain VB.NET. If that's true, I wonder if part of the reason MS is killing VB is that it doesn't serve any necessary purpose, and it is simply uncool. I wonder if "uncoolness" is a primary factor. It sounds silly to write, but think about it -- technologies live and die by coolness. MS is doing everything they can right now to shake off their uncool past, and VB is certainly a relic of the uncool past. Developer share is crucial. You get a lot of developer share by being cool. Thus, being cool is very important. Damn, I want to drop a Medium article on hackernews now with my hot new take.

kelvin0 7y ago

Imagine how the poor Fortan and Cobol devs feel.

vb6sp6 7y ago
I imagine they feel pretty good considering the type of money they make
- chrisseaton 7y ago
  Is there a lot of money in Fortran? Anyone could learn Fortran in a week if they wanted, and there's tons of research assistants who know it already. How's it lucrative?
- insulanian 7y ago
  Is that really true, or is it just a myth?

ourmandave 7y ago

My take away from this is either: 1. Start a go-fund-me to get a VB.net team started. 2. Start work on an open source VB.net to F# transpiler.

benjamoon 7y ago

We're a .NET dev company (all C# coders, but most of us have a background in VB as well), I asked my team if they had to choose would they rather have to develop with: A: C#, but with WebForms (including using code behind and the built in web controls where possible). or B: VB, but with MVC and WebApi. They all chose C# WebForms even though they all hate WebForms, just not as much as they hate VB. Personally I love VB and WebForms, I never get to do work with it nowadays (I'm not even sure we have any legacy systems that still run it), but I built my company from scratch off that stack and coming from a classic ASP background I was blown away with controls like GridView and Repeaters etc. I remember our first designer being so confused with the mess of html outputted by these controls and the hatred our purists had for viewstate that polluted their lightweight designs. I still remember how excited I was when I first used the AjaxControlToolkit and the UpdatePanel control, it was like magic! Now everything's pretty much all C#, RazorPages, WebApi, Angular or Vue and I'd never go back, but I do miss the old days. It's not often I see tech that seems magical any more, SignalR was probably the last big thing that blew me away in terms of just doing something that felt so different, but it's really rare now. I would add that we just finished a prototype app for a client using Blazor WASM and coding that did seem like witchcraft and certainly brought back some of the old feelings of being amazed, maybe we'll all look back on javascript frameworks in the same way we look back on VB in a couple of years if Blazor play outs.

jbn 7y ago

I don't even like VB, but this is a great read. Very informative. The author clearly points out that the deficiencies of the organization that sign the death warrant of VB.NET, regardless of the intrinsic value of that language/compiler/environment.