@ Head

>- 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?

TryCast.

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 An example is ForEach with arrays.

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.

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.










\

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.

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

Good One

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.