Gimme a break....

16 Comments

• Can I have a link to one of my posts on the subject? ;-)
  

• Sorry man, copied the wrong link. Fixed. :) Thanks.
  

• 
  
  While I am in your camp I know of at least 1 company that has over 1 million lines of COBOL..er I mean classic VB...and that code will still be around at least 10 years from now.
  
  
  
  They made this decision just before the days of VB.NET and the .NET framework came to light and with counsel from Microsoft. These guys are smart, smart enough to know that they can't stop innovating on that code base without loosing customers.
  
  
  
  They are not old gaurd, in fact all of them are younger than myself (although I admit I am old now for this business at 38)...and they have not stopped learning but they have significant long-term challenges getting to the new world. It's a long painful process and one that Microsoft thrust on them and of that there is no question. It is easy for us to sit here in 2005 and say that they should have known better but that is only 20/20 hindsight.
  
  
  
  Personally I would never touch old VB6 code with a 10 foot pole...run screaming from the room IMHO. In fact even the sight of VB.NET makes me ill (can you tell I am a C# bigot 8-)).
  
  
  
  However I can at least understand the situation that they are in and not resort to grouping them into the 'old guard' camp. They are in a camp I very much respect...the 'we have shipping code that customers depend on camp and god damit we are going to support them'. Microsoft should take a page out of that playbook don't you think?
  
  
  
  Perhaps one day, when you have shipped that much code you will also appreciate that perspective.
  

• Rob,
  
  
  
  While I appreciate your perspective, and I share your sentiment of an initial respect for the "old guard", I can't at all respect the bellyaching over the end of support. As Wally and others have mentioned, the code doesn't stop working because support ends. Microsoft has no financial reason to continue free support. If they don't want to invest in the future by porting, they're going to pay for it (in more ways than one), plain and simple.
  
  
  
  And I resent the fact that they're going to complain about the move 3+ years after the launch of .NET. The rest of us had to make the switch. You thought the move from VB6 to VB.NET was excruciating? Try from ASP to ASP.NET and VB to VB.NET at the same time. But most of us did it. We whined and complained a bit, but we did it. They haven't, and to me, they're stomping their feet on the ground and saying that they won't. And that's fine. But I can't respect that at all.
  
  
  
  Managed code is the future of development on Windows. There is no going back if you want to be able to take advantage of the latest and greatest features. Get on board or get left behind... it's that simple.
  

• And PS, I had a ton of respect for Richard Grimes. Until he published that temper tantrum thinly veiled as an article. It basically said "they didn't listen to my complaints, so I'm not using .NET anymore." And that's total BS.
  
  
  
  But that's just my opinion.
  

• "Does IBM still support PC/DOS? NO"
  
  Correct, and while I'm in your camp (hell has frozen over! ;) :P), IBM also still supports 25 year old AS/400 software.
  
  
  
  Though some software has a longer lifetime than other software, but OTOH, some software written in VB6 is positioned to have the same long lifetime... the error made is that the software shouldn't have been written in VB6, but in C++ using win32 in that case.
  

• The point your blog misses is that Microsoft has not only dropped VB6, but also hasn't provided a usable upgrade path.
  
  
  
  To ask for one is not either pro- or anti-NET. It has nothing to do with .NET at all.
  
  
  
  To accept that Microsoft can get away without providing an upgrade path should be a worry to you. The key people in the developer tools division at Microsoft seem to have lost sight of the concept that a language and a platform are two separate things.
  
  
  
  Platforms come and go. What will you do with the code you have written and need to maintain when the .NET platform goes and Microsoft abandons the languages that formerly targeted it? Of course, it will still be available for a while even after Microsoft stops selling it, so people will tell you "C# hasn't gone away, carry on coding in C#". But the time will come when modern platforms no longer support the latest version of the framework you can still compile to. At or before that point, you will be faced with abandoning all your code and starting again in a new language.
  
  
  
  If anything, as a programmer in a new and untried language without any track record in long-term stability, it would be in your interest for the petition to succeed, simply to concentrate the minds of the people at Microsoft on the need to allow developers and application owners to preserve and manage their code assets, lest Microsoft pull the same trick on you in some years time.
  
  
  
  So how about a signature from you?
  

• Every once in a while something big happens. VB.NET was something big for VB6 users, as VB was to QuickBasic and that was to GWBasic. I can fully understand the inability for Microsoft to provide as much of an "upgrade path" as some people suggest they should have. The fact is, nobody _needs_ to upgrade. There are excellect opportunities to interop with managed code, and if your application was designed with even a hint of modularity, this will make writing new parts in .NET quite straightforward.
  
  
  
  Of course platforms come and go. One of the nice things about VB6 at the time was that it was a platform _and_ language all in one, that mapped back to Win32 with the various runtimes. Dotnet is another platform, one that has proved successful enough for large parts of the next version of Windows to be written against it. It seems to me that the VB6 developers who continue to whine are the ones who have lost sight of the concept that a language and a platform are two separate things.
  
  
  
  MS could release a new version of VB6 that targetted the .NET platform with, say, Windows Forms as its presentation framework. But then how would you interoperate with the object oriented nature of this platform? I guess you'd have to upgrade the VB language with various features to bring it in line. Oh wait, that's what they did.
  
  
  
  Microsoft have always been pretty good at enabling interop between successive platforms and technologies, and this is no different. I guess I'm amongst the programmers in this "new and untried language without any track record in long-term stability". How do I know it will succeed? Because it's Microsoft, and because they're banking on it with Longhorn and large parts of the company have shifted to managed code development. Nothing like that ever happened with VB6.
  
  
  
  I'll sign a petition against Richard's.
  

• VB could take & compile Quickbasic code, line numbers and all, so long as you had the UI code removed. You *do* keep your UI code separate?
  
  
  
  Platforms come & go. Algorithms don't. Once you have (for instance) a working Quicksort algorithm, there's nothing about a platform change that should ever require you to rewrite it in order to be able to target the new platform. If you think Quicksort is too trivial a case, think instead of the thousands of business rules that have been coded in VB.
  
  
  
  Of course, for the time being you can interop. but the day will come when that VB6 code that you have been maintaining and using with interop will no longer run on Microsoft's latest platform. Someday, that code *will* have to be rewritted, if the language is no longer available that compiles to a current platform.
  
  
  
  If Microsoft breaks a language once, what's to stop them breaking it again? The proportion of development in Microsoft that actually uses managed code is still pretty small. It could easily be jettisoned in favor of the Next Big Idea.
  
  
  
  You can produce all kinds of scholarly arguments to the effect that ClassicVB is outdated. I would probably agree with many of them. But they are not relevant to the Microsoft's problem, which is how to encourage adoption of their new platforms. You don't encourage adoption by artificially raising the price by including the need to rewrite algorithm code as well as UI code in the cost.
  

• VB.NET can take a lot of VB6 code too, if you're not talking about UI. It's still inherantly BASIC, after all. Functions like Left, Mid, Right etc are still there even where there are alternatives present in the framework. If we are talking algorithms written well in VB6, which we apparently now are, I suggest that the same code would run in VB.NET without much modification.
  
  
  
  The argument that one day VB6 code will somehow stop working is silly. That is the same as saying that someday Microsoft will stop supporting Win32 EXEs. Sure, one day I'm sure they will, but even Win16 and DOS applications continue to live in in current Windows. That argument really doesn't stand up. They have stopped updating "oldschool" VB, but that shouldn't be confused with any lack of support for applications written with it.
  
  
  
  The proportion of development in MS that uses managed code is not insignificant, and one only has to look at the direction the company is taking to see that the rate at which it's increasing is accelerating.
  
  
  
  If it's jettisoned in favour of the Next Big Idea? Well guess who will be there producing apps for the Next Big Idea before it even goes RTM. Me.
  

• How about giving me a break. VB6 is fully event driven and cosumes objects like a pitbull eating dog chow.... now, what did you like about VB.Net again?
  

• Biggest reason: code is portable between two languages. Multiple languages can use the same code without COM crap.
  
  
  
  Bottom line: .NET made VB grow up. Maybe it's time the developers followed suit?
  

• as if the world doesnt change at all...
  

• Amen brother. Sure, there'll be a lot of VB6 maintenance for years to come, but does anyone in the tech industry really expect things NOT to change?? If you do, you're in the wrong field.
  

• The vb obsolesence will provide jobs for theys guys when they get tool old to think - just like the cobol guys coming out of retirement and making big bucks
  
  

• Algorithms don't need to be rewritten. That's why they reversed their early decisions on VB.NET's array declaration and default short circuiting. I read algorithms with sample code in ADA and Pascal... doesn't change a whole lot to C.
  
  
  
  As far as "one day it'll stop working"... yea, when COM stops working, they'll have to rewrite. Now, let see, I can write 8086 assembly programs and they still run on Windows XP. So, how long do you think it'll take 'till COM stops working? Perhaps after... hmm, I dunno, pretty much every app for Windows is rewritten, Windows & Office & Visual Studio included...