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.
VB6 was a massive improvement and a fantastic platform for Rapid Application Development. I watched people kill themselves in C++ COM programming when I could create an app in a few days and re-use COM classes at will. DCOM components could be written in hours in VB6.
I have worked for a few companys now and have switched back and forth between C# and VB.Net languages regularly. The "too much typing" comment means you'r not using the IDE to it's full potential.
Most people I know switched to C# because it made them feel like they were using a big boy language. I found so little difference between the two I often thought that one or the other should be fazed out. I am however surprised they never replaced "VB" in Office macros with VB.net.
I still like VB, even though I'm trying to get into web stuff so the joys of PHP Javascipt etc..
For me the beauty (yes beauty) is it is readable.
There are many posts in this thread about the elegance of C-squiggle languages and what they can do in 10 lines that take 100 in VB. This is fair enough but most of this elegance relates to low level function stuff (string twiddling db connections etc) which once written goes into your back pocket library code.
VB excels at the mid level stuff on how to validate and process the lines in a purchase order against available stock and delivery scehdules. For business apps it's a modern day Cobol.
My other big bugbear is the what I call compiler delimiters, aka semi-colons and curly braces. Why-oh-Why are they necessary ? In any editor with syntax highlighting foldable code and code completion what do they add. They just seem to be left over from the computer science guys..
I used to like VB - well not like but I could bend it to my purpose. I even wrote a lot of add-ons for SQLserver 4.5 so it would do all the things I needed it to do. The sysadmin upgraded to 6 anyway so he could get the four or five weeks training in where menu items had moved.
What I liked best about it was you could write code that wouldnt scare people - two hundred lines of VB didnt scare people the same way the same code in 10 lines of C++ did.
My only real annoyance was, after a really large project, discovering they'd added OOP to it but not told anyone about it and it would have save me a couple of months writing the OOP bits myself.
-- idea, except for the drawbacks. Kind of like high explosives -- very useful until misused. Or used inappropriately.
In my misspent early days coding, I certainly wrote more than my share of very fast, very shaky VBA. Which was then used long past its "rotten now" date.
Last month I ported my last rather long-in-tooth VB6 application to Python. What a relief. So yes, while I remember VB6 with fondness, I also am pleased to be done; and I regard VB.net with a bit of (probably unnecessary) skepticism.
The biggest issue with VBA is "record macro" which leads to people that don't have a Scooby thinking they can code. Once got asked to help out a user whose macro no longer worked as expected. It was a recorded specimen that naturally relied on what tab you were on to start off with and which cell you were in - the muppet hadn't even looked at how it was referencing cells.
Maintaining 2 systems, one VB.Net (with very pretty DevExpress UI), and a clunky php api. Stuff works, and they keep me too busy at the moment to learn how to migrate to C#. I'm interested to learn it, as I never really got on with the C family. I *get* handling pointers, but the old c way always felt uncomfortable to me. Maybe I'm just getting on a bit - I started with COBOL.
Migration plans to Intercal pending.
C# is closer to Java than C. If you already do VB.Net then it probably won't be as big a leap as you think. I don't know if it's still the case, but MS's .NET documentation used to have examples in both VB.Net and C# - comparing the two would be a good way of getting an initial feel for C#.
Yes switching between VB.NET and C# is trivial really. A few days of remembering/forgetting to put in semicolons, or using the wrong sort of brackets, and you're back like you never left. They're functionally interchangeable. You build stuff in exactly the same way with either. You'll never see a pointer in C#.
VB6 runs on the Component Object Model (COM). Peering into the Windows boxes in every Boots store it looks as though COM is alive and kicking whilst being programmed now in, er , C#. (Their Nexphase prescription labelling program runs on thousands upon thousands of COM IDispatch interfaces.) And poking around in my own Windows boxes I see a huge number of GUIDS which show me COM isn't yet moribund. What I don't quite understand is why they didn't run a COM based Visual Basic alongside the .NET version. Unless they were afraid the punters wouldn't use the .NET version
As usual, the netties are totally in the ditch! Wrong assumptions, bad mathematics, pointless examples of others they know nothing about (you browsed it on google did you not?) and links that don't work. I am talking about real code that I write and that works, not google links or other half-baked graphics library from ... whatever. VB6 puts .net graphics to shame on every aspect, performance, capacity, speed, capabilites. Try a bilateral space domain bitmap filter in .net... (oopss no such thing)!
The programming world toppled over with VB6 : finally a top level language with limitless possibilities, so easy to use because of its free form and human like simple syntax, leaving you more time to concentrate on crucial aspects of the programming job at hand. There is a concept that netties just don't seem to get, and that is : PRODUCTIVITY.
A big share of the real world is about physics, mechanics and mathematics. I am much more interested in doing FFT's, convolution and correlation on mechanics problems than doing the programming. The language is just a tool to support other mathematical activities. Suddenly with VB6, scientific programming was 5% learning curve/maintenance and a full 95% productivity for problem that matters.
Last 15 years has been a joyride and many people just don't want out of the band-wagon just now...not ever in fact. Who in his right mind would give up 95% productivity in a painless programming environment where everything works so fine all the time and with an almost unlimited access to low level API's power? For what?
Face reality : .Net and the Framework are incredibly stuffy, cumbersome, low productivity, painful environnments born out of the symbiosis relationship between a bunch of micro-managing minded, OOP obsessed techies on a binge (techies are, by definition, people that like making things more complex than they really are) and a very ill advised managing class (pun) that let things go this way for too long, backing them.
The point you are not getting is that scientists and engineers have long masterered ALL the programming they really need, we like the 95% productivity of VB6 and we will just not settle for less or anything else for that matter.
It is pretty amazing to see a company spits out on its own creation, which ironically happens to be one of her best ever, and fail, in fifteen years, at making a successor product that competes with it.
A bunch of us, we are just watching from afar a company entangling herself in a web of doubtable OOP concepts and miscelaneous technologies, jumping from XML to AXML, Silverlight to LightSwitch, DAO to ADO, deprecating perfectly good working stuff at will along the way, for the benefit of their next new great idea that will work (or maybe not), due for deprecation anyway. And from a distance, it all looks pretty silly because it is mostly about stuff a scientific productivity programmer (or accountant or just about any other trade) does not want or even care about.
Fact is : circa 2000 had all the best programming tools (namely VB6) on an hardware base technology that remains unchallenged and is not to be for decades to come. If you want it in other words, that means that the low level kernels of Windows have achieved monolithic status for as long as there is a product called Windows. Then on the upper floor, the techies are having a ball, making Windows and .Net an ever harder thing to manage in the name of...how did you say? Something about managed.. and future ... hum there was also something about spaghetti but I lost you there, you were babbling and I have a short attention span for that sort of things...
I do appreciate that there is a whole sector of programming that is of little interest to me, and about which those fore mentionted programming technologies are promising wonders, and I have no problems with that. I say go for it, have a ball.
But in a sane, mature, productivity world, you don't fix things that are not broken, you do not throw away a winning recipe, you don't re-invent the wheel when yours is running so smoothly, you don't invent New Coke nor Windows 8 (or 10) nor .Net, and if you do, salvation only goes through bringing back Classic, or else drown yourself in your new taste nobody likes.
What the VBsixters are telling you is : we want a hammer and a nail, we'll take care of the rest.
Please bring back VB6! Nothing else will do really. Every year spent widens the gap. Run-time will last beyond 2024. Maybe at that time Xojo or similar will be ready to take over productivity programming and give us what we want. And when that time comes, it will probably not matter anymore whether it's written MS on the label or not.
A comment by MathScienceAndGraphics
VB6 is offering the possibility to focus more on building the algorithms rather than on writing time-consuming code:
TCA is one of the more recent software systems that is based on Visual Basic programming. Source code is written in more than one programming language but predominant is VB6. The reason is quite simple. VB6 is close to pseudocode, offering the possibility to focus more on building the algorithms rather than on writing time-consuming code. Understanding the studied processes and creating the algorithms are the core of any scientific software system building activity. Writing the code is just the implementation phase that offers the possibility to verify the results and that should happen quickly. Otherwise, the research of the phenomenons would be dragged over a long period of time due to the implementation phase. In border sciences, such as colour science (which requests knowledge in the fields of chemistry, physics and mathematics), it is important to have more time to study and understand how to address the problems, in order to create viable algorithms, than to waste time on writing complicated computer language syntaxes. Large software programs that aim to solve a variety of problems are usually not written today in only one computer language. That is because some languages are better suited to some problems, and some are not. I started learning computer languages when Fortran 77 was leader and learned several computer languages since then. VB6 is not a strongly typed object-oriented programming language and that's why I'm not exclusively using this language but VB6 earned its place among the top computer languages for good reasons that should not be underestimated. Ultimately, it is software developers that make computers useful and Operating Systems attractive, and if there's a large number who say that VB6 should be supported, then Microsoft should continue to support it in its own interest.
I started .NET with C# during the v1 beta. But the auto-complete and precompiler were much inferior to VB.NET's.
So we went with VB.NET (Option Strict and Explicit On!). Over a quarter of million lines of code later, with a commercial application that's still being intensively enhanced with new features and the deadlines that come with them, taking time out for a C# rewrite isn't practical. So we stuck with VB.NET and still find it far more readable. Auto-complete and intellisense make verbosity simply a non-issue.
I'm sure C# is intrinsically a superior language, though - tell me again how in the 21st century a language should still be using semi-colons as statement delimiters and nested blocks of curly braces that the IDE often can't even indent right...
While C# has taken over in a pretty big way I still prefer VB.NET (I'm forced to work in both). It seems to promote better coding practices that any C derived language. I noticed even with the same programmers at my company, they create better code in VB than in C# due to VB.NET's support of on the fly code refactoring like automatically changing the case of an identifier to match the declaration. C# because it's case sensitive can't do this, and I noticed that the programmers who would write C# code tend to get lazy and switch from descriptive variables (which are easy to mistype) and use single character identifiers. In VB they will write ProcessNewRecs whereas in C# they start doing B.S. like using just "pnr" for the name or worse just "p".
Even though my first language was C and then C++, I took to VB's way of doing things like a fish to water and am the better programmer for it.
Biting the hand that feeds IT © 1998–2019