11 Comments

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

  • 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.



  • 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.



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

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

Comments have been disabled for this content.