Joe Cheng
Posts: 65
Nickname: jcheng
Registered: Oct, 2002
|
|
Re: is VB.NET a TRUE object oriented language ?
|
Posted: Jun 2, 2004 11:06 PM
|
|
I would call VB.NET a true object oriented language, by most mainstream programmers' standards.
It uses the traditional class/object model, offers subtyping and (single) implementation inheritance, polymorphic method dispatch, method- and field-level access controls... pretty much what you find in Java and C#.
In fact, if you consider C# an OO language then I think you pretty much have to consider VB.NET an OO language as well. Sorry if that disappoints you.
As Matt points out, it's a pretty academic debate, when everyone has their own version of what a "true OO" language is anyway--or whether that's even a worthy goal. Bjarne Stroustrup, creator of C++, often derides Java for being "too OO" in its design. Python and Ruby consider the ability to write procedural code (in addition to classes) to be a feature. Lispers think of any OO language as inherently less powerful than Lisp.
Currently there are very few differences between C# and VB.NET in terms of things you can do in one but not the other. VB.NET is missing a few primitive data types that you weren't going to use anyway, and it doesn't have bit shift operators. I also think it doesn't let you override operators. On the other hand, you can write somewhat more dynamic code in VB.NET, since it allows you to use late binding, i.e. method calls that are not resolved at compile time (which you'd almost never want to do, if you ask me).
C# also has an "unsafe" mode that VB.NET lacks, that lets you work with pointers. I think this is probably less useful than it sounds; our (C#) codebase has a ton of platform and COM interop and we never use unsafe.
More data available here: http://support.microsoft.com/?kbid=308470
The differences will increase a little bit with the Whidbey release; VB.NET will get "Edit and Continue" support in Visual Studio (i.e. change code on the fly during a debugging run), and C# will get at least one unique language feature (closures, a.k.a. anonymous methods).
Visual C++.NET is a different beast altogether. From what I understand, it is basically halfway between C++ and C#. If you need to do very heavy interop with C/C++ libraries, there is stuff you can do very naturally in VC++.NET that you can only do very painfully (or not at all) in VC#.NET or especially VB.NET. But if you have to ask if you need VC++.NET, you almost certainly don't.
I think it is a bad idea to mix VB.NET and C# in the same codebase. In general I think you should just pick C# unless most of your people are VB6-heads who don't want to learn C#, in which case you should maybe just pick VB.NET. I find it hard to imagine a realistic scenario where the same development organization could justify supporting two languages when one would perfectly suffice, and if you have to pick between two languages with equally mature compilers and the same runtime libraries, why wouldn't you pick the one with less syntactic baggage?
Plus, VB.NET code just looks gross. ;)
|
|
Previous Topic
