The My namespace and C#

Don and Robert ask in comments to my previous entry, “Will C# be able to use the My namespace?” The answer is: yes and no.

Most of the functionality contained in My is implemented by types that will be defined in Microsoft.VisualBasic.DLL. So C# users are welcome to reference the DLL and use types such as System.IO.FileSystem or Microsoft.VisualBasic.MyServices.MyComputer. Besides the cognitive dissonance of having to actually use the name “VisualBasic,” there’s really no difficulty there.

However, the top level “glue” that brings all the My pieces together is something that’s compiler-specific and so C# users won’t see it. The top-level My stuff is compiler-specific for two reasons:

  • The My types exposed in a particular project are dependent on the type of the project. A web service project will have a different My namespace than a WinForms project will. Thus, the top-level definition of My has to be integrated into the actual building of the project.
  • Pieces of the My namespace (such as My.Forms) are dependent on objects that are actually a part of the project itself. Thus, the compiler has to specially generate those pieces of the My namespace at compile time.

Roy raises the question as to whether divergence between the languages like this is a good thing or a bad thing. While I’m sympathetic to his point about increased difficulties moving between two languages, it does raise the question: what’s the point of having two separate languages if they have exactly the same set of features? Case insensitivity vs. case sensitvity, for example, is not reason enough alone for Microsoft to invest all the money that it does building both products.

Ultimately, feature set comparability has to be a balancing act between innovation and knowledge portability. If C# and VB cannot implement a new feature without the other language implementing it, the user ultimately suffers by way of reduced language innovation. It would be hard to argue that VB users should not get Edit and Continue back because C# doesn’t plan to support it in Whidbey. Similarly, should C# users not get anonymous methods because VB doesn’t plan to support them in Whidbey? Inevitably, the best ideas of one language will be cribbed by the other language. If My turns out to be a smashing success, I’d expect C# to come sniffing ’round it the next time around. Certainly we’re watching how iterators and anonymous methods play out as we think about features for the future.

Innovation, however, does come at a cost and that can’t be ignored. But I think, in the end, the cost is worth it to both languages’ users.

18 thoughts on “The My namespace and C#

  1. Daniel O'Connell

    I’m personally pretty enthusiastic about the My namespace…I think its a pretty good idea, although I’d rather not see it in C#(it just seems to really be against the philosophy of the language…I would feel similarly if someone suggested adding unsafe code to VB as vb and pointers just seems wrong). I don’t use VB often, but I do like the feature and it may give me reason to use VB more commonly.

    Of course, I like that the languages are diverging and would rather see more divergence. More tools and tools better suited to a particular problem doesn’t seem like a bad thing to me.

    However, I am curious about how the compiler decides waht to expose in the My namespaces. Say you are writing a project that could be either a console application or a windows service(perhaps depending on a commandline switch)…would the compiler reconize that some of your code is related to a service and provide the particular My namespaces that relate to services or does it rely entirely on project type?

    Reply
  2. Mike Schinkel

    The problem with language divergence is you get "haves" vs. "have nots." IOW, I want to be able to pick a tool that doesn’t constrict me; if they diverge I’ll always be missing something whether I choose VB or C#.

    BTW, *PLEASE* *PLEASE* *PLEASE* add anonymous methods to VB 2005. I *had* anonymous methods back in 1990 when I programmed in CA-Clipper 5.0 and *loved* them; I’m having to wait 15 years and maybe more to get them in VB? Please…

    Reply
  3. Daniel O'Connell

    It is the point of divergence that not everything with be in one language. Do you have any idea how complicated a language would be if it tried to do everything? Look at C++ as it is, it was an attempt to be "everything" in a fairly small sphere and turned into one of the most complicated langauges you’ll ever see. Don’t be fooled into thinking that VB is immune from that, if you decide to implement every possible feature the language will become the second most worthless thing on the planet(right next to the equally bloated resultant C#). Both languages can do everything…syntax that makes one thing easier or another doesn’t mean that the langauges can’t achieve what you want, it just means you do it differently, which is the point of different languages isn’t it?

    Non-divergence eventually means *no* innovation. It removes flexibility and ties you into a "this is it, this is all it can ever be" mentality and I really think does you a great deal of a disservice. Eventually you will reach a point where the language can’t grow because it is so bloated with every idea in existance.

    There will always be haves and have nots…thats part of learning and choosing a language(spoken *or* computer, at that), platform, framework version, etc. IMHO, if you don’t want divergence I think VB should be dropped completely and let C# be the only language and let it compete directly with java and C++(same base syntax…if you wanna be identical to the "big" boys, you damn well should have the same syntax too, don’t you think?). I also think there is no reason to divide the talent so much by writing the seperate compilers. This idea that every language should be identical is a very bad one, IMHO, perhaps even a naive, foolish one. Imagine the world if everyoen decided that, in the interest of non-divergence, that no language but C++ would *ever* be used. No more vb, no more C#, no perl,php, python or tcl. Just C++ cause that way you don’t have to give up anything ever. Do you think that is a good idea? If not, why do you believe VB.NET and C# remaining the same is? Its the same principal, it would have the same result, and no, syntax is not a valid argument.

    Please, diverge, give us two different tools or just give us one tool. Right now its as bad as building two billion dollar factories and setting up two different support and testing departments, to produce hammers that differ only in color.

    Reply
  4. paulvick

    Daniel: The shape of My is determined by the main "type" of the project: web application, windows application, console application, class library. Distinctions above and beyond those have to appear in all the types, or not at all.

    Mike: Anonymous methods won’t be in VB 2005. We’ll definitely consider them in the future, though. Sorry!

    Reply
  5. Mike Schinkel

    Daniel: I respect your points, yet respectfully disagree with your premise. I don’t think VB and C# should diverge. As a matter of fact, I’d prefer to see them implemented as the same, with only a layer on top that changes the syntax from line oriented (VB) to statement oriented (C#). FWIW.

    Paul: (no anon methods in 2005): <sob>!

    Reply
  6. Daniel O'Connell

    Mike: What I wanna know is why. Every argument I get is that "Its easier to not have to learn new stuff" or "I don’t want to have to choose anything over anything". Are there any other reasons or is it strictly a matter of not really wanting to know two languages? I think the different syntax over the same representation is a bad idea. This viewpoint really bothers me, its *not* the point of .NET. .NET was designed so that you could get the benifits of multiple languages using the same type system and runtime representation. Some pieces of the community want to turn it into java(One language to rule them all, one syntax-tree to bind them, to paraphrase). It just seems hideous, wasteful, and, no offense intended, rather lazy on the part of developers.

    Reply
  7. Mark Hurd

    It is a shame that we’re not getting anonymous methods in VB straight away. I’m all for language divergence, but with things like My, not features of the platform.

    That was what we hoped to get away from with VB.NET compared with VB "classic". I only hope the reasoning is truly priorities and not "VB programmers won’t use them".

    Reply
  8. paulvick

    Well, since GoSub was a kind of primitive anonymous method, it’s not like there isn’t precedent in the language! It was priorities for this time around, especially given some of the other major things that we were doing this time (generics, operator overloading, etc.). We’ll definitely be considering the feature in the future!

    Reply
  9. Adam Tatusko

    Instead of the following using statement:

    using Microsoft.VisualBasic.MyServices

    in Visual Studio 2005 Beta 2, you now must all of the following to get the same capability:

    using Microsoft.VisualBasic.ApplicationServices;

    using Microsoft.VisualBasic.CompilerServices;

    using Microsoft.VisualBasic.Devices;

    using Microsoft.VisualBasic.FileIO;

    using Microsoft.VisualBasic.Logging;

    Reply
  10. Arek

    what about VS 2005 RTM……there is no :

    using Microsoft.VisualBasic.ApplicationServices;

    using Microsoft.VisualBasic.CompilerServices;

    using Microsoft.VisualBasic.Devices;

    using Microsoft.VisualBasic.FileIO;

    using Microsoft.VisualBasic.Logging;

    Reply
  11. Mario

    I don’t think that incluiding refactoring in C# and not in VB and My namespace in VB an not in C# be a good idea, the Java Developers don’t be forced to choise between Languajes, and have more time to dedicate to learn other things, like Architecture, instead to learn how to write the same code with other syntax, hope in a future Microsoft adopt the same decision with VB or C#.

    Reply
  12. A former VB developer

    I agree with the last post – there is no longer any need for having both VB and C#. Mulitple languages only cause a lot of confusion and wasted effort. Take the best features which are currently exclusive to VB (i.e. ‘with’, ‘optional params’, ‘my’ ), add them to C# and then put VB out of it’s misery. It’s time for VB developers to move on.

    Reply
  13. Ashwin

    I think the assumption that Daniel is making is based on an inaccurate theory. If you have one company developing two languages/environments that are supposed to boil down to the same lowest-common-denominator, and provide more functionality in one language as opposed to another, it is not innovation that can be either a goal or outcome of it. Innovation occurs when you have *competing* technologies.

    Think .NET vs. J2EE. One camp develops something (think: Generics). Then the other implements it. And add a little more.

    Microsoft providing a slightly different functionality set in one language vs. another is not likely to encourage innovation, since I don’t think that the VB camp in MS and the C# camp there are in "competition".

    This post comes three years too late to Daniel’s original response, so this may be too late. However, it seemed that the implication made by the original point somehow got missed, so I thought posting a response here at least now might be relevant to someone out there.

    Kind Regards,

    Ashwin

    Reply
  14. John

    "I agree with the last post – there is no longer any need for having both VB and C#. Mulitple languages only cause a lot of confusion and wasted effort. Take the best features which are currently exclusive to VB (i.e. ‘with’, ‘optional params’, ‘my’ ), add them to C# and then put VB out of it’s misery. It’s time for VB developers to move on. "

    VB is an easier language to learn and use, not having to worry about needless syntax issues like semi-colons and case sensitivity. You may find bracket & case sensitive languages "elagant" but I find them as overhead during development.

    I personally don’t want to move on and elistist attitudes like the above post don’t really make me want to move on either.

    Reply
  15. Paul

    Right. None of this is about a language. VB was first, and the developers were always a helpful tight-knit group. Now I have to sit in Microsoft seminars and hear the jeers and nasty attitudes of these snotty C# developers (which we all laugh and ask "why" do they think they’re so elite?). VB6 was certainly a limited OO language, not even fully OO, but VB.net is as real as the tired Java-look of C#. So the argument that VB isn’t a real language is innaccurate and shows the ignorance of the person sayinbg it. So, axe C#, and let’s get back together. Microsoft has split the camp with C# and created an ugly Civil War, to this day I still don’t understand.

    VB may not be a real language, but it has earned me a real living for 9 years that has provided a comfortable life for my family.

    Reply
  16. Pingback: Anonymous

Leave a Reply