> I'm not going to preemptively switch ecosystems and banish technically good options from my tool belt because I have fears about what could happen.
This is exactly where I am at. I use Windows/C#/.NET without any shame for absolutely everything.
The more developers who give me grief on some principled basis that "<megacorp> bad, so everything related is bad", the more I double-down on my position. These non-technical arguments are read as desperation and incompetence from my perspective in 2023.
Long time .NET developer here - I think criticism of Microsoft as being worse than other companies, particularly at that time, is valid. For the longest time, choosing .NET also required it to run on Windows Server which, besides the cost implications, isn't great at scale. They also used it to try to push SQL Server. .NET Core solved some of this but some skepticism is still justified.
In the late 90's I used to sit next to a team of about 20 VB developers. When MS decided to make VB obsolete, those folks had to re-learn software development and were getting intern like opportunities because suddenly all that VB knowledge and experience was worth exactly zero. Hopefully y'all fare better when they decide to nuke C# and .NET.
If they had to relearn their craft because they changed tools, they weren't very skilled to start with. You've drawn the wrong conclusion here.
And yes, I hopped off the .net train after 15 years of using c# and took a job writing python, and some JavaScript. I had done JavaScript before, using jQuery. Now I had to learn react. And they used MongiDB as the primary data platform. I had spent the last decade working with SQL.
And it was fine, because my skill isn't tied to a single tool.
As of January 2023, the latest version of Visual Studio (2022) still offers to scaffold me a new Visual Basic project!
And VB exists in other forms, too. The other day, I was coding VBA macros for an Excel spreadsheet for my business. Worked great and saved me a bunch of time.
I personally know developers who switched careers after Microsoft transitioned to .Net. I worked with them around 2001.
They didn't understand OOP concepts and were not interested in having to relearn everything. It felt totally unfamiliar and strange to them. Microsoft tried to make the syntax somewhat familiar, but at the end of the day .Net is an object-oriented programming language and VB6, try as it might, was not. And that was too steep of a hill to climb for them.
Seriously? Good riddance to the "developers" that couldn't adapt. The job market is littered with garbage developers, and it's exactly the type of developer that can't adapt to a new language or style of programming that are the ones that aren't really meant to be a developer. Hopefully they found their niche in the economy. - Ex-VB6 programmer turned VBA programmer turned VB.NET programmer turned C# programmer turned Python programmer turned Javascript Programmer (and all the non-pro projects and gigs inbetween, C++, Go, Elixir, Java, Kotlin, etc).
VB.NET has only superficial similarities to VB 6 and before. Microsoft discontinued the original VB in favor of VB.NET, but the engine lives on in VBA and Microsoft has used VB6 to build various internal things (I think some of the UI to Windows Defender is VB6).
But for most "Microsoft shops", VB6 was a dead end, and that left a lot of VB developers out in the cold. They had to reskill with the .NET stuff (significant, especially in the early 2000s), or starve.
This always baffles me. It doesn't surprise me, but it baffles me. Why are so many professional developers having to "reskill" to adapt to a new language? We're not necessarily talking about new domains (that would be different, there's a lot I don't know about server administration and automation, for instance, given my background primarily with embedded and desktop systems). But a language? And a procedural/imperative language? VB, C, C++, Pascal, Delphi, C#, Java, JavaScript, Ada, Python, Rust, Go, Fortran, etc. are all, fundamentally, procedural/imperative languages with varying degrees of OO, functional, and metaprogramming capabilities distinguishing between them. Some are bigger jumps (I'd point to Rust as the biggest in that group) than others, but what "reskilling" does a programmer or developer need when switching between languages in roughly the same language family? It's not like they had to jump to Haskell or Prolog or something that was majorly different.
VB6 is an entirely different beast. A professional VB6 developer who didn't have formal training was very well insulated from what their code actually did - that's not to say that they weren't, or that their weren't extremely talented VB6 developers. It's just that for many developers who fell into it from scripting or who invested all of their time and learning into the pre-.NET ecosystem, they had to choose to relearn a significant amount of technical content. Even though the languages were syntactically similar, jumping from VB6 to VB.Net meant learning an entirely new framework and object model, and having to deal with some issues that were hidden from them before.
In many cases it was as different as using BASIC vs Pascal or even C to write CLI tools (a hurdle I jumped in high school in the mid-90s, and despite doing alot of stuff with PEEK and POKE in basic, understanding pointers took me longer than I care to admit :P)
Did you use VB6? It was less a language and more of a wysiwyg windows desktop GUI application builder. If that's what you learned in school and it was your first professional job, you would have a very difficult road ahead of you learning something like C. Maybe 3 out of the 20 were successful moving on. Some VB apps had almost no code at all that wasn't auto generated by the platform and bound to UI elements to handle button clicks and so on.
> Some VB apps had almost no code at all that wasn't auto generated by the platform and bound to UI elements to handle button clicks and so on.
Then they weren't programmers, so I could see them having to "reskill" (actually become programmers). But if they transferred to another wysiwyg toolkit then there is still no reskilling, just relearning (as I mentioned in my cousin comment to this one). Knowledge isn't skill, it's just knowledge. If your knowledge ends at "I know how to use this particular toolkit" and your skill is "I can do it quickly, make it functional, and make it pretty" then the skill should be transferable while the specific knowledge may not be and you may have to learn new knowledge. But the skill remains.
I sat in on a meetup of professional Microsoft admins once. It was... different. They seemed mystified by the concept of variables in PowerShell. Like, the idea that a variable can hold different things at different times, and the behavior of a script can change depending on what's in the variables... that astonished them.
A lot of professionals who work on Microsoft platforms are not like us. They're not even like Mark Russinovich or Raymond Chen, real smart people associated with Microsoft systems. They're filing clerks or middle managers or sales people for traditional companies. White collar working stiffs who aren't programmers by trade, they learned a bit of programming to automate their real job or add value because computing and the internet were becoming critical to their business, and they sort of fell into a developer role from something else. In Microsoft developer persona terms, they're Morts. And there are a lot of them, hidden in companies and organizations around the world. This was probably even more true in the 90s than today. And it was especially true of VB, which was explicitly designed for the Morts of the world.
And a Mort would be absolutely flummoxed by the changes between VB and VB.NET. VB is VB, drag some controls around, double click and add code. Its syntax and semantics are borrowed from QBasic. VB.NET is basically C# with a more Pascal-like syntax. You now have to worry about, like, classes and encapsulation and stuff. Any significant VB6 code will require considerable changes to run in VB.NET. If VB is what you're used to, VB.NET seems like intolerable change for change's sake. People toward the Elvis and Einstein side of the developer spectrum don't mind the differences; they're only as bad as, say, those between Java and JavaScript, but to someone for whom programming is a job, not a calling, those differences can be death by a thousand papercuts.
Microsoft actually caught a lot of heat for this back in the day, and people started calling VB.NET "Visual Fred" because it was so different from classic VB -- and difficult for classic VB programmers to get accustomed to.
> They seemed mystified by the concept of variables in PowerShell.
Then they hadn't been writing batch files before PowerShell existed, either. They probably weren't programmers. Windows admin at least used to be very UI-/wizard-driven.
That just shows their Mort-ness in their own domain though. In the Unix world, a sysadmin may not be a software engineer, but the ability to cruft up a program in bash, perl, or python to automate some task would be table stakes for the job. On Windows, not so much.
These admins learned just enough to be competent at the job that was in front of them. Many (not all) VB and VBA programmers are the same way.
> This always baffles me. It doesn't surprise me, but it baffles me. Why are so many professional developers having to "reskill" to adapt to a new language?
stretch your thinking a little, it's really not baffling.
you have people who teach themselves to code as teens or younger, then major in computer science then take jobs as professional developers by which time they've been experienced in a variety of programming paradigms, and where the nature of computer science is natively appealing to them.
In some large companies they might find themselves working alongside some people who were English majors/barristas and recently took a coding bootcamp to earn a better living writing some VB. Yes it's going to be harder for the latter group to drop what they know to pick up languages with more complex CS constructs and semantics. It's entirely reasonable for a not-so-experienced VB programmer to consider themselves a professional developer, even if it's a profession that they just took up, or even if they've been at it awhile but all their knowledge is within the VB ecosystem.
I 100% second the baffling nature of this. Maybe not baffling, but telling. If you can't relate your programming experience to new languages and paradigms, if you aren't curious and driven enough to learn the differences and likenesses between them, then you aren't a real developer. No shame in that, not everyone is cut out for it.
Different languages have different libraries with different functions that take different arguments and have different data structures. The tools you used with the old language might be different or required modification to work with the new language.
Maybe libraries they had written to solve problems in their domain have to be recreated.
It seems like switching from Delphi to Java or Go and changing the entire ecosystem would take a bit of time to get back to making the same productivity as with the toolset one has been using for a decade?
> Different languages have different libraries with different functions that take different arguments and have different data structures. The tools you used with the old language might be different or required modification to work with the new language.
Those are all knowledge differences, not skill differences. Programming is a combination of knowledge and skill, the skill part transfers between languages and environments very well. The knowledge, not always. But learning a new (to you) suite of libraries is not "reskilling". You're not developing a new skill by learning Java's API versus C#'s API.
> VB.NET has only superficial similarities to VB 6 and before.
There are differences, but the similarities are more than superficial. Some of my first apps were in 6, and then I transitioned to VB.NET in the early 2000s. At the very least, it pretty familiar and intuitive.
Even VBA is pretty similar to the VB.NET apps I developed in terms of OOP, syntax, autocompletion in the editor, event handlers, and so on.
Again, there are definitely differences, but there was no "[relearning] software development and getting intern like opportunities" like the comment I was replying to said, and my knowledge and experience was definitely not "worth exactly zero." It was just an evolution.
The VB developers I knew used the exact same super high quality IDE to start learning C# and a lot of the concepts either transferred or they would have had to learn them anyway to hop to VB.NET so.. this all just feels like normal forward progress to me.
I'm not totally sure what that means. VB and the change to .NET are kind of a one-off event. A "VB developer" could mean anything from someone writing VB/ ASP in a text editor with minimal syntax highlighting to someone using a drag and drop editor and never writing code to someone who was really just writing fancy Excel macros. If you want to suggest some of the people working in a GUI only had trouble making the transition, I suppose it's possible, but .NET offered VB.net and VisualStudio still had drag-and-drop editors. So why would they need to be interns? Because people started organizing code differently in folders and linking DLLs?
At the height of VB6 usage, there was no VB.net or Visual Studio. There was the VB6 windows binary that was a GUI form builder and IDE. ASP was brand new and for web development, so there was not much overlap in the dev community. I don't think it was even possible to write VB code in a simple text editor and compile that without the VB IDE. Cold Fusion and Power Builder were similarly corporate controlled and suffered the same fate.
A C programmer during the same time period saw almost no changes to their language or job opportunities.
Not to mention with a community that built an alternative implementation so strong that MS ended up buying the company the emerged from it. And this was before .Net Core was fully open sourced.
I was there in those days too. VB was a very beginner-friendly language, more akin to what we call today "low-code" than other languages. Those developers didn't have to "re" learn software development, as you think, instead they probably never knew software development well enough to use languages like VB.NET (which is what all of the VB devs I worked with ended up on). "C# and .NET" is equal to any language you can think of in terms of complexity, so C# devs are going to be just fine.
It was technically possible for someone to write a VB compiler and enough of a runtime to integrate VB code with Visual Fred and the rest of the .Net ecosystem. That this apparently never occurred to anyone says interesting things about that development culture, but the big lesson is to not rely on a single source for a language implementation or tooling in general. Go not only has an open-source primary implementation, it has, like, a few thousand righteously angry hackers in its culture who would take Google abandoning it as a personal affront and would work on a replacement Go implementation in a pure example of spite-driven development.
If you know C#, you aren't going to have to "relearn programming", and C#/.Net isn't going the way of VB anytime soon. Moreover, there's so much code in the wild written on this language/platform that there's not going to be any great loss of employability.
This is exactly where I am at. I use Windows/C#/.NET without any shame for absolutely everything.
The more developers who give me grief on some principled basis that "<megacorp> bad, so everything related is bad", the more I double-down on my position. These non-technical arguments are read as desperation and incompetence from my perspective in 2023.