Scott Swigart responds to Richard Grimes

Richard Grimes posted some fairly negative thoughts around .NET and VB.NET specifically, comments that Scott decided to reply to with his own post.

I have to say that Richard’s comments about C# vs. VB.NET are something that I hear all the time, that it is easy for a VB6 developer to pick up C#, and (just like Scott says) that just isn’t true at all. To pick just one example, case-sensitivity is a language ‘feature’ that leads to confusion and errors, and trying to work in that environment after growing up inside Visual Basic is a lot harder than people make it seem. In the end, a VB6 developer will be productive faster with VB.NET. Could they learn C# eventually? Sure, why not… but why should they when they can build wonderful .NET applications without having to learn a completely new language?

Metaphors are not always useful, but the same one comes to mind every time someone tells me that VB developers should just ‘pick up’ C#. Imagine if you will, an American has to start a new job and has a choice of two languages to work in… British English or German. Now, British English is not exactly the language they’ve grown up with, so since they’ll have to learn a bunch of new concepts anyway (signing-off on emails with “Cheers”, etc.) they might as well move to German. Richard says;

“I’ve said, VB.NET is not VB, and since a developer would have to learn principles of OOP and .NET principles like threading, exceptions, and delegates, the developer may as well learn a new language.”

Right… Hey you have some new stuff to learn, so you might as well learn even more while you are at it, no sense benefiting from any of your years of past experience. That doesn’t strike me as a logical conclusion, but I won’t pick away at Richard’s entire set of comments… I’ll leave that to Scott đŸ™‚

Author: Duncan Mackenzie

I'm the Developer Lead for the Channel 9 team, formerly worked on MSDN as a developer, content strategist and author.

5 thoughts on “Scott Swigart responds to Richard Grimes”

  1. The apparent compatibility of VB.NET is a mirage. For an application of medium or higher complexity the only answer is a re-write of the software.

    For every compatible piece of syntax there is a another that is a minefield. And for anything dealing with forms it is a whole new world and much of the techniques that worked with the VB6 forms are not appliciable or need to be greatly altered.

    The effort in converting a app from VB6 to VB.NET is equivalent to the conversion from jave to c#. Both share familar syntax but uses vastly different librares with vastly different quirks.

    While C# is case sensitive, it does elminate many of the problems between trying to shift from VB syntax. The two most notable are use of object reference variables and the use of the “dot” syntax for accessing members.

    For some people going C# may be more productive as they will learn the dotNet approach instead of trying older VB6 techniques. For example short for integer, the lack of control arrays, the lack of bounded arrays, etc.

    What I find inexcusable about MS is the fact that .NET clearly can support a myriad of languages. There was no reasons to provide a VB6.NET other than lack of foresight or greed. It is obvious that nobody on the VB.NET team tried to switch over a vb application of any complexity.

    Rob Conley

  2. You know that argument is still there. I don’t see a lot of C# coders complaining about porting their ANSI C legacy code to C#. Is there some big bad man at your job with a gun to your head saying “port”. No one says move everything by noon tomorrow or die. Just don’t write anymore new software in the aging language from last millenium. Backwards compatability is a cute concept, but at somepoint you have to cut cords and stop dragging bagage around with you. Why are you upgrading at all? Why not just stick in VB6 and never open your mouth? Why must fundamentalists always be so bloody vocal.

    Damnit if VB.NET breaks existing VB6 code I defy you to, with a straight face, say that maintaining VB6 code in C# is a walk in the park. Oh and I don’t know what point someone was trying to make about reference variables or the dot member access operator but I choose to believe I wasn’t the only one who missed it.

    Microsoft didn’t make VB.NET because of greed. They didn’t make it to piss you off. They made it so as not to say “f_ck off”, we’re making a new cool platform and you can’t come. Have fun in VB6. All you curly-brace folk this-way, laugh at the VB coders with their silly inadequate language on your way. They even stopped to bring J++ and C++ on the way. What is it about the way that you percieve the world that prevents you from recognizing when someone cares about you? About the last decade that you’ve been typing Dim x As Single(not float x;) and typing with reckless abandon with regard to case and typing strings without escaping every backslash. Go learn Java you ingrates.

  3. You don’t see a lot of C coder complaining because Microsoft is still has a Visual C++ that is an upgrade not a replace of earlier versions. In addition the CLR support in C++ is built so that you could intermix legacy code with CLR code.

    VB.NET and VB share similarity but then so does C# and Java and there are the same issues trying to port between VB6 and VB.NET and Java and C#.

    What makes it terriable in my book is that Java and C# are competitors but VB6 and VB.NET are from the same company.

    VB.NET is a good language and the object basic that I always was looking for. But it does little to help me to move on from VB6. I have done two major coversions in the 15 years I have been programming. The first from DOS to VB3 and the second from VB3 to a object oriented VB6 version.

    The DOS to VB3 was a major untaking because the original software was written in Rocky Mountain/HP Basic. This meant while all the math code (the software was a CAD/CAM app) was readily transferrable everything else was not.

    In constrast the jump from VB3 to VB6 was a lot easier, the steps were a lot more predictable because I could convert one subsystem at a time from the older array/type based data storage to the new object oriented/collection classes setup.

    I have been working with VB.NET since it was released in order to learn it and prepare for a future conversion. And I found out is like the jump from DOS to VB6. The graphics engine, and a hundred small details have changed.

    A first I thought “Ok they added all this stuff this is a price.” But now three years later, seeing the work done with other language compling to IL I feel there is no excuse for MS not having a VB Classic.NET langauge.

    I can emulate many missing langauge features of VB6 in .NET by constructing classes and using interfaces. It just boggles my mind that MS would FORCE VB6 into a conversion effort or to ditch their old code.

    Most work in software is not in making new applications but maintaining old applications. And not maintaining for just the sake of continuing with old tech but refactoring them to take advantage of new techology. With VB.NET any developer of a VB6 app is faced with a stark choice. A choice that a C++ developer is not faced with.

  4. Maybe this discussion is too shallow. You say this conversion is particularly difficult. Could you offer tons of examples? I’m not saying your issues aren’t legitimate so much as that I’m having a hard time imagining them.

    How is COM Interop insufficient to your VB Classic .NET? What is it that you were doing in VB6 that you simply can’t do in VB.NET (aside array bounds and the whole 20MB download requirement)? Somebody is missing something here and I want to know what.

  5. > How is COM Interop insufficient to your VB Classic .NET? What is it that you were doing in VB6 that you simply can’t do in VB.NET (aside array bounds and the whole 20MB download requirement)? Somebody is missing something here and I want to know what.

    It’s largely not about not being able to DO it, it’s about having to REWRITE it (in our case, millions of lines of code that works fine today).

    Sure, we can stay in VB6, but at some point, we will have to REWRITE EVERYTHING in one fell swoop just to get back to square one (having an equal feature set). When we decided to use VB, it was based on a history of stable improvements and easy migration ability. We could add new features gradually, keep current with the OS, and make changes within the same platform. Rewriting from scratch is not financially viable. If we were starting TODAY, obviously we would not choose VB6, but now we are in it (since vb3).

    Not that Microsoft owes us VB6 coders anything, but we feel extremely skeptical about moving to a Microsoft technology if they are just going to abandon it — which is why we have been looking at Delphi and Realbasic (and even Java).

    Anybody else have success stories regarding migraing vb6 code to a low-risk platform that won’t be dead-ended.

    Seems to me, if someone wanted to make a nice profit, they could write a book on “how to convert a VB6 app to _______ (fill in the blank with any language)”. I would buy it (if it was complete)…..

Leave a Reply