ISerializable - Roy Osherove's Blog

I don't think the "My" namespace is a VB lanaguage addition per se. I think it's a set of classes that are part of the VB.NET library. However, those classes are implemented in managed code so I don't see a reason why you couldn't call into the "My" namespace from within a C# app. I would think it would just be a matter of setting a reference to Microsoft.VisualBasic.dll, add 'using' statements for the appropriate namespaces and be off and running.

It might look a bit funny to see
using Microsoft.VisualBasic;

at the top of a .cs file, but it seems like it would be worth it for the added productivity of the "My" namespace!

Steve: Now - why didn't I think of that? that's probably how that'll work, I hope. Which would make most of my post irrelevant *bangs head on table*
:)

Different languages are supposed to have different features. Microsoft made the move to differentiate in Whidbey, and Orcas will be even more RAD than it is now. What if every language was a cookie cutter port of the other one? What would be the point?

Roy, Steve,

Actually - you are both correct. The My classes are managed classes from a .NET assembly, so are usable from C#. However, "MY" is a VB keyword. In C# you'd have to declare/instantiate the "My" objects explicitly and continue from there.

Roy, your original post presents an interesting point, although I don't think that the goal with .NET is to allow developers to seamlessly switch from language to language - then why bother with different languages if they are SO similar ? The real benefit of .NET is the seamless multi-langauge code integration (i.e. cross-langauge calling, inheritance, debugging, etc.). Even more important, for VB developers, is that palying field has been levelled - since it is a single run-time and set of framework classes, there is no functionality that is unavailable to VB developers.

Of course, the playing field is really levelled (and is getting more uneven) - we will always be able to do many things much faster and easier in VB !! :-)

I think that one of the following may be applicable. Of course, there are doubtless many other possibilities but it's too early in the morning for my poor brain to deal with more than two.

1 MS thought that homogenising the languages would draw the broadest audience to .NET in the quickest time. Interestingly, many VB folks didn't like VB.NET and a goodly number of C++ folks were similarly dismissive of C#. Looking at it from a long history of VB involvement, I'd suggest that a lot of professional VB developers have jumped tracks to C#, possibly because it's less likely that they'll get caught out by similarities.
If MS had added the features needed to include scripting languages then they'd have had a broad audience indeed.

2 MS planned to diverge languages' capabilities as the product developed, knowing that getting buy-in from the (millions of) casual VB developers was going to take more simplimafication (and edit-and-continue) than was desirable in the 1.0 or 1.1 versions. So now VB.NET's heading back to RAD-land. Or at least it's acquiring more of the RAD-ish capabilities that "classic" VB has.

I've been programming in vb.net for almost 2 years now. I think I'll switch from vb.net to c# because the way they treat us is not acceptable: we can't use the normal API (or so they think) so they develop a new keywoard for make is simpler...

I do see some akwardness in this too. VB is indeed being targeted as the more RAD language and C# as the more code-oriented language for developers.

But why not have all the extra tools and features be as language independant as possible, then the programmer can have the best plethora of tools, whatever language they have chosen.

* the 'My' classes should not be in the Visual Basic namespace, but should be named language independant.
* VB can have a My keyword that is a shortcut to these classes, like C# has the using keyword to provide a shortcut to the Dispose pattern.
* Refactoring is important for any language, not just C#
* Edit-n-continue is also a platform feature, so why only in VB?

Really, I can see that from a marketing pov, some tools can be more prominent in one language than another, but most tools should be, as the platform itself, language independant.

I do see the point in each language getting its own uniqueness, but I remember the fact that you could move easily between languages as one of the most touted features in .Net.
If that's not the cause anymore, than, sure. It all makes sense, but this is indeed something to consider.
Here's a real-life example: There is not simple "IsNumeric()" function in C#. There is one in VB. A VBer wanting to use that in C# would have a pretty hard time and there are lots of more complicated alternatives (double.TryParse()??).
Sure, its possible to reference the Visual Basic assembly, but not very intuitive and it takes a long time to realize that's the easiest,simplest and fastest way to go.
Now, just imagine how hard a move it would be if you're used to "My" to do lots of your regular work.
Is Importing the VisualBasic namespace your first and only choice to be able to work in the "almost" same speed or knowing the object model as you did as a VBer?
Is that natural?

In all my c# coding, i have often just imported the vb runtime library and used Information.IsNumeric(), etc. all of your goodies are there. I don't see the point in writing my own isnumeric routines in c# just to be a purist if I can use the vb functions.

Stijn,

There is nothing at all preventing you from using the raw API or objects in VB. There will just be an additional way of coding the same functionality that is easier and faster.

Some of it will work, some of it won't.

Roy, this problem already exists today (oops, it was mentioned by someone else already) with some of the things like IsNumeric that already exist in VB, but not C#, but can be referenced, it's just that now it'll be even worse ;)

Also, they've already actually done some of what you're saying (put it in the Framework). The biggest one being strongly typed resources. That was originally just in the My Classes (as far as I knew from seeing it at last year's summit), but has now been moved into the Framework for everyone to use. Things like the cool new IO stuff like reading and writing to a text file in one line of code is in the Framework and C# can access it without any other assemblies. The My Classes just have it wrapped up to fit in its organizational groupings.

Really though, I think that this stuff doesn't really cause a problem because if a user starts on VB and uses that, I think that's where s/he should stay. There really aren't any "good" reasons to switch back and forth unless you're a writer or someone that needs to do both (usually a more advanced developer anyway who will know the ins and outs of both languages). "Most" people shouldn't need to. Find the language that works and use it and don't worry about the other. That's my opinion anyway and I'm sticking to it :P

something really bothers me concerning this argument-
do u know if c# developer is payed more then vb.net developer
(assuming their experience level is equal).

do u have any statistics about any salary differences
or any information about the number of vb.net developers
comparing to c# (worldwide) ?

i used to develop in vb6 and migrated to vb.net, but i feel that
i need to study c# as well, just because i am afraid that some

companies prefer c# as their favorite language.

what do you guys think?

The issue with the "My" framework seems to me more due to the structure of the development teams and internal politics inside Microsoft than due to "design philosophy".

I assime that the idea for the "My" framework came from someone within the VB team. The idea is good and should be available to all languages since it is a framework library feature and not really a language feature.

But to make it a framework feature available to all languages, the guy from the VB team will have to "sell" it to several teams inside Microsoft, and get a wide support for his idea. It is much simpler to convince one product manager in the VB team to include it as a VB feature than go up and convince a group product manager that will have to convince 5 other product managers that of course have tight schedule and each of them would like to participate in the design. So the one who got the idea selected the "Green lane" and get this feature out to the market, however in a little distorted way.

I assume that in the next version this will be amended and the classes will be available as part of the framework in a language neutral fashion. Of course the framework will not be as "clean" as it should be because backward compatability would have to be maintained and this will create a mess.

There is always a chance that somebody smart enought, and with enough political power will understand this early and make the right decisions and fix this now, before it is being comitted by microsoft (in a form of a product release).

There is a say that the difference between wise people and smart people is that wise people do not get into troubles that smart people know how to get out from. So it seems that in this instance Microsoft will be just smart... lets hope that they will be wise!

It was my understanding that namespaces are compiled DLLS, and therefore in MSIL, so they should be language-agnostic. What feature of the MY namespace would prevent it from working in c#?

There are many references to the My 'namespace' being a pseudo-namespace that only the VB.NET compiler knows about. I haven't looked at the details, but I believe some of its functionality is simply aliasing other classes or methods, but some of it has more value adding than that.

As Mike Schinkel makes clear in comments postes here: http://blogs.xtras.net/mikes/CommentView,guid,307fb650-5f41-4aa7-b7e5-bd42aadfed35.aspx
the VB.NET My feature is more than just the My classes.

As far as VB.NET, C# and other .NET languages diverging, as long as no part of the .NET Framework is arbitrarily made unavailable to a programmer, a language should be able to easily have its own features and constructs.

Of course, VB has had a history of arbitrary limitations, mostly removed in VB.NET, except for some silly things like not being allowed to refer to System.Void directly at all. (They didn't want Function x() As Void to be synonymous with Sub x(). OK, but if I'm writing type or method reflection code, why do I have to jump though hoops to reference GetType(System.Void).)

IMHO the situations where you *have* to use another language to implement a framework or operating system feature are bigger issues than when it is simpler in one language than another. That is, if there's too many 'can't do' 'features' a language is avoided and 'looked down on'.

The range of features/constructs that easier in one language than another is *why* there's a multitude of programming languages, and that's a good thing.