Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Hearts and Minds

rom the time Visual Studio.NET was first in beta there has been a constant debate about a subject that is near and dear to all Visual Studio .NET developers. This debate centers around a single question: Which Visual Studio.NET language do I use for my development? Visual Basic .NET or C#? I have been holding off on this subject for some time now. It's a topic that on the surface seems pretty simple to write about but it is actually more complex than it originally seemed. So here's my take...

I come from a background in Visual FoxPro and Visual Basic development. I am intimately familiar with both of these development tools as well as a number of others including SQL Server, Cold Fusion, and Delphi. For years a war raged on about which was the better development tool-Visual FoxPro or Visual Basic. Well it all depended on your point of view. Visual Basic was a better behaved Windows development tool, supporting most Windows technologies. Visual FoxPro was a great RAD environment for building client-server and desktop applications. Which one won in my evaluation? It was a draw. I used the tool that best supported the types of applications I was developing. I really didn't care what tool I used because the big job was centered on the tasks of: gathering user requirements, analyzing problems, and meeting customer needs. Now the war over hearts and minds is centered on VB.NET and C#

Some programmers feel some type of need to develop in a "real programmers" language. Others just want to get a job done. I'm one of the latter. I have heard a number of arguments about using C#. Some of them include: C# is a cleaner language, C# will force programmers to write better code, C# is more maintainable, Microsoft uses C# in the Framework. Most of these arguments are without supportable data. I don't think C# code is any more or less maintainable than Visual Basic.NET code. Nor does it mean developers will write better code-bad programming seems to translate well across programming languages and development tools. Good designs will triumph over bad designs no matter what the language.

Does Visual Basic.NET have its warts? Absolutely. Visual Basic.NET has a keyword called ANDALSO. What the heck is this? It is Visual Basic.NET's version of an AND keyword that short circuits. You see Visual Basic 6 (and earlier versions) did not short circuit AND statements. Earlier versions of Visual Basic .NET short circuited but Microsoft listened to the whining of VB6 developers on this issue and backed down and bloated the language. So yes, that's one of probably several ways that Visual Basic.NET is bloated. Is it a real problem if a language supports a few more constructs or keywords? I don't think so.

Another topic to discuss is the future of Visual Studio.NEt. The next version, code named "Whidbey," will have some cool features for both C# developers and Visual Basic.NET developers. One of the key features of VB.NET is that it lets you "edit and continue" when developing applications. What this means is that when you get a run time error you will be able to edit (fix) that code and press continue. This feature is invaluable when writing and testing code. This feature is specific to Visual Basic.NET-C# will not support it. I have heard people pooh-pooh this feature as no big deal with comments like: "Real programmers don't need tools like that anyway." I used to see this same argument from VB developers whenever the OOP pronciple of inheritance was mentioned. "Don't knock it until you try it," the old cereal commercial used to say.

So, what do I recommend you do? If you are a Visual Basic, VBA, or Visual FoxPro developer you should look at Visual Basic.NET. It resembles a language you already know. Your learning curve will be lower. If you are a Java, C++, C, or Delphi developer, you may be more comfortable with C# but you could always give Visual Basic.NET a look.

From what you have read you will surmise that I don't really feel there's a significant advantage of one language over the other. That's why CoDe Magazine will continue to provide examples in multiple languages. No go forth and program young JEDI.

Rod Paddock is the Editor-in-chief of CoDe Magazine. He can be reached by e-mail at editor@code-magazine.com.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date