What I love about VB.NET.

Via, Yag, Paul, and Jay, Scott touched on some of the nice things VB.NET has to offer.  So I thought I’d add to that list the things I love. Some of these are what I see as improvements over VB6, some as advancements compared to C#….

– Block property declarations.   This feature is one I use the most often (how can one avoid it after all <g>), but it is also one I really love.  It just feels more anatomically correct ๐Ÿ˜‰

– Structured Error Handling. (SEH) .  Once again, this just feels more natural to be able to explicitly wrap a block of code inside a specialized error handling block.  OF course you can achieve the same pretty much with VB6 style On Error GoTo, but the clear explicit structure is not there, rather you have to interpret it from the spaghetti

– Pretty listing.  Yeh it’s just an IDE thing, but one I love.  No more worrying about indenting code manually.

– Option Strict.  Detect errors at design time, rather than runtime.

– Background compiler.  Detect errors at design time rather than compile time.

– Formal Interfaces declarations.  Sure you could do these in VB6, but it felt more like an abstract base class rather than an interface.  So it’s more a style than a functionality thing, but one I like ๐Ÿ™‚

– Explicit Interface mapping.  This is incredibly cool.  Unfortunately a lot of people just don’t get how important this concept is to true OO.  I’ll blog about this separately me thinks, suffice it to say for now is that it formalizes the contract in a clear robust explicit and flexible manner.

– Delegates.  Them just sweet.  Not syntax sugar kind of sweet, no, these are the purest finest honey ๐Ÿ™‚

– Parameterized constructors (as Scott mentioned).  This really comes in handy when creating object purely to pass to another method.  When all is said and done it really is just a matter of cutting down on lines of code.

– Multiple types per code file and Nested Types.  Multiple types per code file is great when wanting to write quick tests etc, but I do tend to split code out to one type per code file for the most part. Nested types on the other hand are really cool as they allow encapsulation of types you don’t want exposed.

– Explicit Event handler mapping

– Explicit structure member layout. With win32 API this rocks !

– Explicit casting.  CType or DirectCast, such as CType(myfoo, IBar).DoIt

– Implementation Inheritance.  I think this one is highly over-rated, but it is also indispensable when you do really need it.

– Threading.  Also often over rated IMO, but also indispensable when you need it.

– ASP.NET versus ASP. No comparison, asp is just scripting totally devoid of event driven structure or strong typing etc.  ASP.NET kicks azz !!

There’s probably a lot more little things but I’ll leave the list at that for now. As to VB.NET over C#, VB.NET is actually a far more OO language when you look at the actual implementation details. It also is case insensitive which is closer to natural language. (u don’t have 2 spe4k 1337 to gr0k that 1) , and it is written more like we speak. The most obvious example of which is the End xxx constructs.  Compare VB.NET code to the }}}} of closing a if block inside a method inside a class inside a namespace, and you should easily see what I mean .

As to VB6 compared to VB.NET,  I think many of the enhancements I list above could easily be applied to VB6.  Yes I do strongly believe that another version of VB6 is still warranted, one with many of these enhancements.



8 Comments so far

  1.   Geoff Appleby on February 26th, 2005          

    >- Explicit casting. CType or DirectCast, such as CType(myfoo, IBar).DoIt

    Of all the things that whidbey is giving us, do you know what i’m most impatient for?



  2.   Bill McCarthy on February 26th, 2005          

    Hi Geoff,

    Yeh I wanted TryCast way back in the beta’s of 2002, but more for performance issues than anything else. If you use TryCast, you then have to test for null, as opposed to testing the TypeOf the object before doing a DirectCast, well there isn’t really much difference in coding style, rather the difference is in the under pinnings.

    Personally, as much as I like TryCast, especially as it does make it easier to port C# code to VB.NET, I would have preferred the effort went into recognizing and optimizing the If TypeOf foo is bar Then …. x = CType(foo, bar).

    Or basically what I am saying is that a high level language should not force us to use different constructs for optimisation where it is posible for the compiler to do it for us smile An example is ForEach with arrays.

  3.   Dan McKinley on February 27th, 2005          

    In my blog post, I completely misunderstood what you were tryingn to say with "End XXX," apologies. Although, it’s probably obvious that I don’t agree. I’d like to hear examples of your thoughts on how VB is more object-friendly.

  4.   Bill McCarthy on February 27th, 2005          

    Hi Dan,

    Actually on the End XXX constructs, I said that pretty badly What I meant to say is they are more readable, but they do also more closely mimic the spoken language. Try this yourself at home, write a couple of blocks of C# code then try to read the code out aloud including all block and flow constructs. Presume the person listening to you cannot see the code. When you do that, you will or should find yourself uttering "end if" for your }’s that indicate the end of an if block etc.

    As to VB.NET being more OO, well interfaces, event handlers, are all implemented in mroe OO fashions. I’ll blog about these separately as I think a lot of people haven’t yet seen the forest for the trees on these issues. Think polymorphism, think encapsulation, then look at how the two languages compare.


  5.   Dan McKinley on February 28th, 2005          

    On readability, what I’m saying is that I can more quickly look at C#/Java/whatever and understand it. Obviously "end" is more natural than "closing brace thingy," but I’m not saying the words in my head. My brain just parses it. VB is slower for me because of its verbosity. If I needed to read the code aloud to someone else, sure, "End XXX" is better.

    On event handling, I can understand your argument. But I consider event handling in VB to be a very leaky abstraction (as Joel on Software would say). Serialization issues, inadvertent GC rooting, et al come into play here and it all comes crashing down.

    The issue, I think, is that VB (currently) has the abstraction in lieu of the "nuts and bolts" pieces that you need to get event handling to work, 100% of the time, in every context. The "RaiseEvent" keyword doesn’t do me any good if, for instance, I want to raise the event asynchronously. This is elegant in C# because the underlying implementation is accessible.

    So in conclusion, I think OO abstractions are great. But we need the fundamentals there first.

  6.   Bill McCarthy on February 28th, 2005          

    hey Dan,

    On readability: yes on both counts VB.NET is indeed the more natural language. As to it’s verbosity, well that is coded telling you things, rather than being reliant on added in comments, the code itself is explanatory. (which also brings with it conformitiy) It’s all part and parcel of declerative programming.

    that being said, I do think at a shallow level, C# code has a lot more whitespace in it, which visually, for some folks can make it easier to scan. I think for Vb.NET, improvements in the IDE can make a significant change there.

    But as to your difficulty in parsing VB.NET code, well as you said, VB.NET is actually more natural. It is probably more that you need practice reading and writing the code. Your mind will soon pick up on keywords and skip similarly to how you do in C#. For example, you won’t focus on the Dim keyword, rather just mentally note the declaration is there and when looking at it you will focus on the variable name and the type. So on the visual side of things, that really is a matter of experience.

    As to events in Vb.NET, I’m sorry but there is no "inadvertant GC rooting". I don’t know who told you that, but you/they were sorely mislead.

    On serialization, Vb.NET has absolutely no problems with XML serialization. There is however an issue with binary serialization and MarshalByRef classes. The real problem is MarhsalByRef classes, eg a Windows.Form, cannot be binary serialized. If you need to work around that, you can do so in Vb.NET 2005, and more elegantly than C#

    As to async event raising, I’m sorry but once again you have been sorely misled, but that is also a common misunderstanding. I remember sometime ago Juval Lowey wrote me saying you couldn’t raise events in VB.NET asyncronously. I wrote back and told him you could, but it took a couple of emails and the code before he was convinced. Then happily a couple of months later he told me that you could raise events asyncronously in Vb.NET <bg> Anwyay, so the experts are all in on this, and indeed you can *easily* raise events asyncronously in VB.NET, and have been able to since day one.

    So when we look at what you claim to be a leaky abstraction, you are basing that purely on not being able to binary serialize events if any handler is MarshalByRef. That is not the fault of the abstraction. In fact if you look at the VB.NET 2005 implementation you can keep the abstraction AND also customise the storage and raise method in an encapsualted design that uses the full CLR spec, something which C# still doesn’t do.

    I will follow this up later this week with a couple of posts on Events and Event handlingn in Vb.NET. Seems there may still be some folks who need to learn the facts there

  7.   Antony on April 4th, 2005          

    Good One

  8.   baby jim on August 31st, 2005          

    vb is nice don’t get me wrong. i’m a firm believer in using the right tool for the right job. vb is nice because so many people know how to use it (even though many people don’t take advantage of it’s full potential).

    with that said, i must agree with the above comment, c# is MUCH easier to read than VB. the reason is because c# "usually" uses symbols rather than words, leaving the words to things like variables and function names.

    when i look at a page of vb code, it looks more like a dictionary with words scattered all over the page. i’m sure the code was easy to write, but when a developer who didn’t write the code has to come along later and debug it, it can really be a pain in the arse. i would much rather debug a c# application as i can almost instantly see what the programmer was trying to do without having to siff through a bunch of words.

    finally, the biggest advantage c# will always have over vb is that it’s almost identical to the languages of java, java script, and c. if you master 1 you will be well rehearsed in the other languages. if programing languages were instruments, the language syntax of c would be the piano.

    again, vb has it’s place too and we use it all the time. but when it comes to programing low level or internet intensive application, i always use c# and for good reason.