Executive summary: The world does not work on VS20xx developed code and is not likely to -- ever. We need better tools.
I confess that I too go to VB6 when I need to hammer out a quick GUI application. The last code I delivered into production for a client was C# developed in Visual Studio, but the clunky tools for building user interfaces and the tortured dependencies are too agonizing for someone used to effortless RAD tools like VB6 or Delphi.
I write lots of little tools to assist me in doing various tasks. I go to scripting if its manipulating OS stuff like copying files, Vanilla ANSI-C when doing simple utilities that don't need a GUI and VB6 when building a GUI application. I use perl, PHP and vanilla HTML when building web back-ends. Web stuff expected to be maintained for clients use packaged stuff like MediaWiki backed by MySQL or SQLite. To the extent possible, I use open source code for everything as a matter of self-defense. Except for venerable tools like VB6 the only things that have survived over the years have been things for which the source was available. When VB6 is finally dead and buried its demise will be entirely attributable to the fact it is not open source.
I am ever hopeful that some genuinely usable open source cross-platform RAD tool will appear, but so far everything has been disappointing. As time goes on, we appear to be moving further away from what I consider to be powerful and expressive tools that produce small, self-contained or minimally dependent software.
I am not now and never was a fan of .NET which to me seems to be an almost sinister extension of DLL hell deeper into the development process.
I was marginally OK with write once debug everywhere Java until it became a vendor dominated dead end. But even before then I had dropped it due to security issues. Beyond that, I don't like Java much. It may be 'C++ without all the guns, knives and clubs', but it seems like they added sticks and stones as replacements and that is not really an improvement. Worse, rather than picking up a stick to do battle with knife-wielding languages, it requires that you instantiate and run a factory-factory to build a factory to create the stick before you have a stick to pick up. It hardly matters how elegant and capable that stick is after you have been stabbed to death waiting for it.
I have done work in just about every language. I constantly review new stuff. That includes programming paradigms. C and BASIC have some serious limitations, especially with respect to OOP, but their limitations are outweighed by the fact that they work when written and long after delivery into production. They are also both very nimble. You can develop and deploy things in less time than Java programmers spend discussing their object hierarchy and which GOF techniques they will use or how pure their pair programming regime is.
Most of the software I actually use started as someone scratching an itch and they had something working, if imperfectly, very quickly. Good designs should call for something that can be built and tested almost immediately.
Like others who work in these aging languages, I am something of a dinosaur, but you know what? Us dinosaurs wrote the world's working code upon which we all depend. Literally tens of millions of people use things running portions of my code every single day and have done so for years. Likely most of the code that actually gets run to do useful stuff in your life goes back decades. I am pretty sure a lot of banks still use COBOL coded systems whose inception date goes back nearly half a century.
C is the most portable language I use and the most ubiquitous of my code has been written in C. This is not a coincidence.
As a developer, I only care about producing working software. It ought to be obvious but that means software that is actually operating in production, not some variant of hello world in a textbook or shaky example code the author warns is unsuitable for real use. Getting there and staying in environments like Communications and embedded systems requires code that simply works, compiles cleanly today and can be expected to compile cleanly in the years to come.
I would never specify current versions of Visual Studio and .NET for an important production system that had to remain in operation for any significant length of time.
It was entirely possible more than 20 years ago to build capable and reasonably light-weight development tools that supported 'rad' RAD. I have no doubt that it is *possible* to deliver something just as good or better today. There are a lot of seasoned professional programmers out there and eventually we will join forces to make it happen. When it does, it is a safe bet that merging ANSI-C will be easy if not effortless. I am not sure how safe a bet it is that merging C# or Java will be, but my hunch is that it will be difficult if not impossible.
The long suffering software developers of the world deserve better than VS 20xx.