This is why I stopped using the entire .NET environment long ago, and only program in real languages.
Microsoft program manager Mads Torgersen has posted about the company's programming language strategy, stating that the plan for Visual Basic has shifted from co-evolution with C# to a focus on "core scenarios". Torgersen outlines the strategy for the three pure .NET languages, C#, VB, and F#. C#, says Torgersen, is used by …
"This is why I stopped using the entire .NET environment long ago, and only program in real languages."
THAT is worth repeating. BIG thumbs up for that, thanks.
I never even started USING ".Not". It was like W.T.F. ??? You just re-invented EVERYTHING and forced ME and every OTHER senior developer to be "a junior developer" again! NO!, Micro-shaft. Just NO!
_MY_ applications and DLLs (when I need to write for windows) are stand-alone statically linked entities that define where the boundaries are and don't need "shared" anything, thank-you-very-much, especially a monolithic bass-ackwards inefficient collection of spaghetti-code like ".Not". Computers have a lot of RAM these days and an extra 100k or so per C-runtime copy is insignificant.
As for VB, I developed an application with a VB front-end and C-language back-end WAY back when VB was version 1.0 and it looked like a good idea. It was filled with a zillion hacks to get it to work, which had to be re-thought for VB 2.0 and re-re-thought for VB 3.0. At that point I stopped upgrading VB for that application... and eventually stopped using VB altogether!
QBasic --> Visual BASIC was a REALLY GREAT THING I thought. Adding ".Not" to VB was the WORST thing that was ever done to it, and most likely what will _KILL_ it to death.
Stuff changes, get over it. Bit like DOS developers complaining when they had to learn this new Windows stuff.
I moved from QBasic to VB5 to VB.Net with a sprinkling of other bits along the way. Once .Net 2,0 was released, it became obvious that there were no advantages to staying with VB. Switch to C# was relatively painless as I'd done som Java along the way. OO had been learnt through Smalltalk.
None of use should be dependent upon a single language.
You're not a commercial developer, are you?
Imagine you have a huge - and popular - commercial application written in classic VB, with hundreds of thousands of lines of code. Suddenly MS decides to pull the rug under your feet (and everyone else's, really).
What are you going to do? Re-write the whole application in C++? Your competitors would REALLY, REALLY, like that - as a real world example of what would happen, take a look at Netscape: one day they decided to re-write from scratch what was, at the time, the most popular Internet browser. By the time they finished - two years later or so - they had a huge buggy mess on their hands and the world had already moved on anyway.
So no, the only solution is to keep at it and pray every day that MS does not suddenly think that killing the VB run-time in a future version of Windows (perhaps we should say 'release' now, instead of version) would be a good idea too.
P.S. In retrospect, had I know back then how popular the application would become and that MS is NOT to be trusted under ANY circumstances - not even when talking about what was then the most popular development language EVER - I would have written it in C++ from the get go instead of VB. But, as they say, hindsight is 20/20 vision, no?
"In retrospect, had I know back then how popular the application would become and that MS is NOT to be trusted under ANY circumstances - not even when talking about what was then the most popular development language EVER "
How many times did people warn you (and others like you)?
How many times did you (and others like you) think "Yes OK but it'll never happen to *me* because I'm special, and because MS wouldn't be that silly, surely"
It seems to be sinking in now.
Please go read about the "sunk costs fallacy"  and then consider whether it would be better to be nearer the front of the exodus, or nearer the back?
Best of luck.
 e.g. http://www.lifehack.org/articles/communication/how-the-sunk-cost-fallacy-makes-you-act-stupid.html
> How many times did people warn you (and others like you)?
Oh, come down your high horse already! :) That's not the point. If everyone followed that advice to the letter, the only 'safe' programming language to use would be Assembly/machine code.
There was a time there where not even MS would dare to challenge market pressure. Now they seem to think they are too big to fail. I guess IBM thought the same too.
Technologies will always come and go, sure, but new and old were allowed to co-exist peacefully until the old *naturally* faded into oblivion as more and more people adopted the new. Now MS doesn't even bother waiting - they just downright kill the 'old' so they can force feed us the 'new' (which, given MS's total lack of vision, never stays 'new' for long). And woe to you if you believe them and invest your livelihood in one of MS's fab new technologies - tomorrow it's you they will be turning their backs on without as much as a second thought.
"Stuff changes, get over it. Bit like DOS developers complaining when they had to learn this new Windows stuff."
Heh, you should have heard the FORTRAN programmers when they got rid of the last five card punch machines when I was at uni in 1986 (no, not a typo). Apparently terminals are the spawn of the devil or something.
"Stuff changes, get over it. Bit like DOS developers complaining when they had to learn this new Windows stuff."
THAT was 'change for the better' (I was near the bleeding edge of that bit of technological evolution). However ".Not" is CHANGE FOR THE WORSE. Like OBAKA. And "the RIBBON". And "the METRO". And Win-10-nic. And 'clippy'.
So as for ".Not", keep your "change". Don't want the FAIL.
haha I remember being the C programming king of high school and Windows came out and even with all the help that I could get from the Charles Pezhold book *which I spent two weeks of grocery store wages on), I couldn't for the life of me figure out the API.
Of course, X11, Windows, Mac all have horrible low level APIs... but now, I just code language and environment doesn't really matter anymore. It's more about simply just sitting down to type.
I nearly died laughing at the guy who said that simply changing the language made him go from senior developer to junior developer. I never met a senior level developer who was senior because of how well he could use one particular tool or paradigm. I always considering the most versatile person to be senior and people who speak like he did as ready to be promoted to janitorial staff.
I still remember back in the early 90's when I tried to transition from TurboPascal 6 under DOS to, eh, whatever Borland's C compiler was for Windows. I could do cool stuff with TP with no problem, but I remember looking at a small sample Windows program and it was like 18 lines of code just to get an empty window on the screen. Bleh. So I stuck with DOS for a few more years. In '94 I found a copy of VB 3 for sale for $15 in the back on Computer Monthly, so ordered it (and a $5 copy of Windows 3.0), and decided I was GOING to learn it. And I did. It's served me well over the intervening 23 years. I never did take a liking to the low-level Windows API. Fast, sure, but ugly as hell to code.
One of the top VB book writers argued "forget VB.Net, it's a C programmer's idea of VB."
I decided very quickly that VB.net was inferior to C# and for RAD and Prototyping (of microcontrollers in another language) that VB6 was superior.
So mostly I used Java if it wasn't private prototypes (for which I stuck with VB6).
So VB has been dead since Vb.net "replaced" VB6. C# was really MS replacement. YET!!!! They could not decide on a "model" for the GUI or APIs! It kept changing and there seemed to be three competing "solutions" none of which seemed sufficiently finished to really replace VB6.
Also why has 64 bit Win7 "broken" VB6 apps? Stuff compiled for NT3.51 using Stony Brook Modula-2 STILL "just runs" on Win7 64 bit and most VB6 applications don't!
Why too did MS not put the 64bit code in Program Files(x64), and instead broke everything (starting with XP Itanium 64 bit or NT4.0 Alpha 64? I don't know) by putting 32bit in Program Files (x86) and 64bit in Program Files?
Back in 2003 or so, I think they started to lose the plot.
Direct 3D API for regular forms!
"Metro" / Win8 / Win10
They have never properly supported VB since after VB6. Easier to re-do from scratch in Java or C# than port from VB6 to VB.NET, and that was with decently written stuff (Option Explicit, no "clever" tricks, just Modula-2/Pascal/Delphi style programs). For a start no support in VB.NET for arrays of form widgets.
how many organisations are going to struggle to upgrade their legacy VB6 apps ? Quite a few, if my experience is anything to go by.
Yes, you can soldier on. It's not like they'll stop working tomorrow. But lacking support, how long till you need an old - unsupported - virtual machine to continue ?
(revises day rates)
Actually, that problem is already here. I worked on a commercial application with some legacy VB6 code, and owing to some dll hell with MSCOMCTL.OCX, we were unable to find a way to compile it using Windows 8 or 10 (we tried very hard). I've since left the company, but I believe they still have to do their release builds from a win 7 VM.
Once compiled it works on most machines, but really that timebomb started ticking years ago.
To be fair the writing has been on the wall for at least a decade. When VB.Net came out almost everyone I know in the financial services sector said that company policy was to move all new development to C# (that is, development that would have been VB6 or ASP so not the C/C++ or server Java stuff). The reason being that C# was a first class citizen and VB.Net was not and the differences between VB.Net and VB6 were enough that the learning required meant it was more beneficial for devs to learn C#.
I do remember one major re-insurer where the head of development took the line of "no we won't be using C# I want all GUI code done in VB.Net, that is the future". Wonder how that's working out?
That may be the case, but there's a lot of people not looking at the wall. I know a fair number of financial organizations that are still heavily invested in VB - not to mention a few governmental ones I have visited in the last few years.
Microsoft may eventually state that it is stopping development and/or maintenance on VB, but just like Window XP, it doesn't decide when people finally stop using the damn thing.
I've converted a lot of legacy VB6 apps with a tool called Xojo http://www.xojo.com. It very much looks and behaves like VB6 except that it's been updated 4 to 5 times a year for the past 20 years. Sure, it uses the BASIC syntax but it's a modern object-oriented language.
The added benefit is that Xojo is cross platform meaning the IDE works on macOS, Windows, Linux, and compiles into native (not interpreted) desktop applications for macOS, Windows, Linux. The same framework lets you do console and web applications too so there is a LOT of flexibility. They currently have iOS support and have announced Android support by the end of 2017.
They have a converter app that helps convert UI into Xojo and leaves the code for you to convert. Sounds cheap, I know, but some of the things that developers worked around in VB6 are easy to do in Xojo. Control subclassing and threads are easy in Xojo. There are a few other utilities and services available to help get VB6 apps working in Xojo.
You never forget the joys of trying to get shit installed on other machines that works perfectly on the dev box. OCXs and licensing being a bit of a shit, and various controls that were on your box but not theirs.
There's a reason the .Net framework came about, VB6 could be a c*nt to install.
VB died after v6. It was a very useful language to get stuff done and done quick. It may not have had all the features of other languages but it didnt have half the problems either. Code was easy to read and drag and drop made life simple if you just needed an interface and needed it now. The only serious limitation was being stuck on windows systems.
I know some people hated the language and to that I say to each their own.
VB lives forever on in the myriad of Excel spreadsheets that run plenty of businesses, unfortunately. It is still handy for rapid prototyping - have used it on many trading desks for prototyping strategies - but you have to have a policy of bedding down the system in something better once it has functionally stabilised even if the accountants claim that is just developing the same thing twice. We used to move the strats from VBA to C++ in the execution engine where it's a bit tough to prototype them.
Agreed. Classic VB made Windows programming bearable, even if us VB guys did have to hang our heads in shame and be cruelly mocked by the Visual C++ guys. At least we were keeping our kids fed. VB.NET was a stretch too far for me, so I've just stuck with VB6. I'm an admin now, not a programmer, so any coding I do is for my own use. And in truth, I don't use VB6 much these days, since I learned Powershell (which is its own form of purgatory, and is in no way a programming language, but is handy for doing admin work on Windows boxen). But every now and then, I have to tweak one of my old VB6 tools, so I fire up the XP VM and have at it.
Bit of an odd decision - not that that in its self is unusual from Microsoft these days
As Office uses VBA which is presumably sharing a lot of that code, could that mean the end to VBA / poisoned documents and spreadsheets ?
What about MS Access - doesn't that use the same framework too. Do they even still do Access ?
VB kind of has a place, but its also the cause of a lot of departmentally generated "headache applications" that bypass any form of proper development control / testing / inclusion in any DR plans but also become business critical.
You'll always get end users reach for Access to get shit done, but really SQL Express should be your starting point (up to 10GB database size) given it is free. I know of places where Access is not installed by default with Office in order to prevent the breeding of MDBs. Excel is harder to resist though.
I always found the attitude to 'BASIC' was simply down to the actual name. I find BASIC to be more or less adequate for anything I need, afterall, calling a dll fundtion is almost identical in use as in C(squiggle of choice), you just use slightly different syntax to do it.
Honestly, I imagine with enough effort, anything written in C@ can be replicated in BASIC. Besides, I think it should be rebranded as APSIC, which sounds much nicer IMO, and loosed that highly outdated Beginners moniker.
"How can you mention Visual Basic's decline without mentioning Delphi?
Delphi showed how things _should_ be..."
You can still buy Delphi, but only at corporate prices. So no new users....
But there is Lazarus, free, open source and appears more complete "cross platform" than anything else I tried. And it looks and feels just like Delphi did when I last used it, some 16 years ago.
Some exclusions may apply. See terms and conditions for more details .
Past MS performance may not be indicative of future MS results.The value of your investment in MS (hours, $$$$) may go down as well as down.
 Terms and conditions available via
"Rekon 20 years later a similar article will be talking about Microsoft dropping C#?"
No, Micro-shaft wouldn't be THAT SMART. Instead, they promote "wrong" until people stop hating it. Win-10-nic comes to mind, as does ". Not" and _ESPECIALLY_ C-POUND!
Well, I hope Micro-shaft REPENTS of their evil ways and POUNDS C-POUND back into the hell-mouth from which it was excreted. But I doubt I'll get my way. Micro-shaft will just throw more money at it, move the target around in circles a bit, and call it "a good thing" again. Meanwhile, the '.Not' framework fills up even MORE with cruft, legacy, confusion, and bass-ackwards inefficiency.
For some reason many people consider a project which doesn't supply regular updates "dead". Even though said project is working like a charm and doing everything one could expect from it. Probably because some believe that it can always be done better, but as usual we're not going to bother trying to expand on things ourselves. Effort and all...
Quite frankly I can't help see a parallel here.
If MS didn't believe in VB anymore then I don't think they would have provided the runtime libraries in both Windows 8 as well as Windows 10. Just because they won't be developing the language as actively as they used to doesn't mean things will die off.
I mean, if you look back then the same thing was once said about VBA. Yet VBA can still provide an excellent way to automate Office and make it do all sorts of things. Who cares if new features will no longer find their way into it? It doesn't make the language obsolete, because the language can already do so much. Yet that's the part which most people forget or ignore: they don't look at what a product can do, they only keep staring at what they think it should be able to do.
Even up to a point where something already is possible but which people think should be done "better" or "easier".
Seeing is believing, but I don't think VB isn't going anywhere near /dev/null anytime soon.
Biting the hand that feeds IT © 1998–2019