Language Wars…..


Chris Sells says:


Let The Language Wars Continue



I think that the CLR languages *should* have different capabilities and that programmers should be proud of their choice of language! The skinning the pretends to separate two nearly identical languages must end!”


I agree. I like the idea that each language has a special niche or reason for using it. Why do VB.NET and C# developers want them to be the same? Is this truly a curly bracket/no curly bracket debate? I hope not.


What do you all think? Should the Visual Basic .NET team be “allowed” to go off and develop super cool VB.NET only features and vice versa for the C# team? Leave a comment.


Nice discussion going on in the comments:


“I hate to say it but God himself could come down and tell all developers that C# and VB.NET are equal and there would STILL be C fill in the blank developers who wouldn’t believe it. “


Join in on the fun!


Comments (9)

  1. James Avery says:

    I think the language teams should be allowed to do anything that will make their language better, as long as it does not interfere with cross-assembly compatibilities. Just like the XML commenting features that C# has now, great language feature and it does not interfere.

  2. Greg Huber says:

    Adding more features to languages is a good idea, but I think for the most part VB.NET and C# should remain "equals" in terms of features.

    If not, you end up getting into the religious type wars where one language is "better" than another. C# is probably more positioned in terms of getting more features added. After all, it does have the advantage of being the language that MS invented for the .NET platform. VB.NET was more or less retrofitted to work with .NET so it may be at a disadvantage in terms of future direction. If C# continues to get "cool features" and VB.NET decides it just wants to be "basic" then I think that will be a bad thing in general.

    Another angle: there are different pressures on C#– it is an ECMA standard so MS isn’t the only one that will drive features for it. Some powerful features may be added to C# that VB.NET will never implement because MS solely drives VB.NET and they may not think VB needs some of those same features. On the other hand, VB.NET can get more non-standard non-ecma compliant stuff. But that isn’t necessarily the stuff I, being interested in standards, would want to deal with.

    So here are the outcomes I see happening:

    Happy Outcome (for me): C# and VB.NET have just about the same exact capabilities. The syntax is different of course, but in terms of power (minus memory pointer stuff), oo features, etc. everything is equal.

    Not so great outcome #1: Ecma pressures C# to "get with the times". Let’s say something like Macro’s, Multiple Inheritance, and templates. MS says heck, why not, C++ and Java people have been whining. VB.NET compiler team says "that isn’t necessary in VB.NET.. VBr’s wouldn’t know what to do with those features" Religious war ensues, VB.NETters are now 2nd class programmers once again :)

    Not so great outcome #2: MS decides to extend the CLR for VB

  3. Alex Lowe says:

    Why do you care if there is a religious war? I agree with regarding C#’s ability to be extended. C# is in a MUCH BETTER position regarding feature additions, etc. This is the main reason that VB.NET did not get XML comments in version 1.

    Does a religious war really hurt developers as long as the cross-assembly/CLR principles remain true? I mean, people can argue all they want but ultimately it comes down to actual technical capabilities, what you (or your team/company) have expertise using as a development tool, and the availability of people with the skills in that particular technology. How does the religious war hurt you? I hate to say it but God himself could come down and tell all developers that C# and VB.NET are equal and there would STILL be C fill in the blank developers who wouldn’t believe it.

    Why is your happy outcome a happy outcome for you?

    I guess I can see why outcome #2 is bad for some people – those "advanced" features would put C# out of reach for many developers. However, does it make much sense to hold one language back from a power/feature standpoint because of the culture/knowledge of the developers from another language? It doesn’t make sense to me.

    I’m very interested to hear people’s thoughts on these matters.

  4. Greg Huber says:

    The religious war stuff wasn’t really the main point I was trying to make. I agree that a developers should simply ignore the religious war type stuff that goes on. But come on, who doesn’t like a good religious war every now and then?? "My sword IS longer than your sword!!" :)

    I suppose my happy outcome as mentioned above is indeed happy because I think equality is one of the key features of the .NET runtime. It gives all languages equal capabilities, at least in theory. If one language chooses to implement the entire set of features while other languages do not, that somehow makes the other ones not quite as useful/powerful. I agree that you must weigh "the right tool for the shop", but I think you could argue just about any feature that could be left out.

    Hypothetic example: Some advanced OO features are added to C#, but not VB.NET. People who like the VB.NET syntax are really excited about these new features, but can’t use them because they are not supported in the VB.NET world. Hence, they either have to switch to C# or "suck it up". Ok- it’s not exactly difficult to switch, but if the majority of your code base is in VB.NET you will be less likely to do so.

  5. Great weblog, thanx to your ideas, and good luck.

  6. I look forward to a day when we can all get along :-). How come we still have C# developers snobbing on VB.NET developers? I do not see the reverse. Ever see a VB.NET developer snob on a C# developer? I will agree C and C++ were more difficult languages then VB; however, in my world, clients want applications developed quickly that solve their business requirement. They do not care, for the most part, about the language.

    I love VB.NET and I respect those that chose to use C#.

  7. Alex Lowe says:

    Greg,

    I would say that the problem with your scenario is that you have to pick a language.

    If the demand for an advanced OO feature is great enough then it will be implemented in both languages. The reality is that the demand will drive the product. If an advanced OO feature is not in VB.NET then that is because probably because the majority of VB.NET developers don’t want it/need it.

  8. Alex Lowe says:

    Seriously, I am absolutely not snobbing. I have done A LOT of VB and VBScript development.

    I am, however, a big proponent of making my development tool, language, and platform of choice as powerful as possible. So, if I choose C# then I want all of the things that I need to build powerful application in that language – the same goes for VB.NET. The catch here is that they are not going to be the same (reality). So, I’m over the idea of true equality (sounded good in the marketing material) and I’m pushing for the most bang for my buck. I think this is a reasonable and expected action that should be taken by developers regardless of language.

    Personally, I don’t worry about what C# can do that VB.NET can’t do or vice versa. Well, let me qualify that statement, I only worry when it is something I NEED. So, if I need a feature then you can bet that I will be asking, begging, pleading with the powers that be to make it happen.

    Also, VB.NET developers don’t have anything to snob about – they languages are equal, remember? 😉

  9. Greg Huber says:

    Alex- I couldn’t have said it better. As long as I can do everything in VB.NET that I need to, I’ll be happy with VB.NET (or vice versa with C#). <P>

    But I think absolutely <b>having</b> to choose a language might be a false dilemma. A lot of that really does depend on your development shop. Right now with C# and VB.NET being so close it makes more sense to choose one, but futher down the road it may make more sense to be "multi-lingual" especially if things really diverge. But getting used to the idea of having multiple languages would probably be a major paradigm shift for many dev shops. <P>

    But the alternative (using one language) is to miss out on some good design patterns/features for the sake of consistency. In my experience, consistency is about all you get– most app architectures / frameworks radically change each new app anyway.