.NET Language Wars? Nah, we need Language Detente!

March 12, 2005 @ 10:20 pm

With the recent flurry of comments in the community - the letter from Richard Grimes, the VB6 petition and the usual VB vs. C# debate - there’s been renewed insecurity from the VB camp about VB.NET not being a first rate citizen in the .NET world. This really points at the problem, which is the VB community itself which is hurting itself by acting like a supposedly neglected child. There are a lot of people in the VB community who are so insecure they take any shot at VB as a personal slight and go for a personal vendetta. For the most part this is a minority 'opinion' but it belongs to a small and very vocal group. One look at the defensive responses to Richard Grimes article and the result BLOG exchanges show a good bit of this behavior. The sad part is that the VB community ought to be plenty happy with their first rate status in the .NET world.

Trust me, as a VB.NET developer you have no idea what it’s like to be a second or event third rate development tool on the Microsoft scale. I come from a Visual FoxPro background originally and Microsoft truly has buried that product years ago behind a non-marketing scheme. The funny thing is that those same VB people whining about exposure, were probably the same ones that were talking shit about Visual FoxPro and pointing out that VB was so much more powerful and marginalized Visual FoxPro as a ‘toy’, when they literrally had no clue what could be done with it.

I can relate because the same sort of thing was happening in the FoxPro community: Everytime there was something good that happened - a positive article, a product comparision - heck lately any mentioned of the product - people would excitedly point at these articles like something new and great was discovered. And if something bad was posted or published it was dissected and pulled apart and the author crucified as a blasphemer. This narrow mindedness and insecurity seems so pathetically childish, but it happens all the time.

Development tools are tools that we use and while we do depend on Microsoft to improve the products and push them into the public's eye, if you have chosen a tool as your tool of choice it should stand on its own based on the merits of the language/environment or whatever criteria you made to arrive at this choice. Whether Microsoft publishes or says something positive has absolutely no bearing on the work that you create.

When we're talking about .NET especially language seems a pretty silly thing to argue about. For .NET at least, let’s all remember it’s about the Framework not about the languages.

Personally I prefer C#. I’ve never liked VB. I worked on several VB projects many years back and I always had problems with the idiosyncrasies of the language that seems to have a mind of its own, with language constructs and naming conventions. I got over it once I got busy with my work, but it was always nagging at me. Be that as it may, this is a personal preference, and not a really well grounded technical decision. It's a purely subjective choice. VB.NET is a capable language and the difference in true functionality beyond the obvious syntactical differences between C# and VB.NET are minor. Certainly VB.NET is as powerful as C# and even does a few things you can’t do with C# (and visa versa) and it’s good that there is choice in languages. I know there are plenty of people who are not comfortable looking at braces and case sensitivity although those are merely syntactical elements.

I’m glad I can use C# and wasn’t forced in VB.NET at the time, but this is a personal preference and obviously some folks find the reverse to be true. To each his own! There’s no need to get all worked up – there’s plenty of VB and C# to go around. I think it would suck if there only was C# or VB.NET and people were forced to work one way or another.

Most of the concern seems to come from the fact that Microsoft is using C# internally much more frequently than VB, but I think this is pretty obvious choice as much of the developer culture inside of Microsoft is coming from a C++ background who will obviously find C# a much better fit to the way they work. In addition, I think the C# only background is changing as there are significant pieces in Whidbey that are using VB.NET code ( I don't know this for sure, but I've heard this mentioned from a number of Microsoft developers ).

Variety is good for us as developers because we get choice. At the same time though I think that having two languages is potentially a distraction for Microsoft to re-invent the wheel on several fronts instead of focusing their energy where it really matters which is the framework. I’ve spent a fair amount of time lobbying various people at Microsoft to try and put any enhancements either into the framework or into separately installable assemblies rather than trying to further bloat languages and diverge. If there’s any way to enhance functionality by getting the code into a reusable format rather than as a language feature it should be done that way.

Microsoft has said frequently that VB and C# will be diverging with C# focused on providing a lean, system oriented language, and VB gaining more high level features. While that sounds reasonable, the examples that have been sited by Microsoft – easier data integration and even features like the My. functionality in Whidbey – are not features that require language differentiation. The My. functionality could have been easily implemented via external assemblies and a little help from the VS.NET IDE generically. If there’s ever a chance to enhance functionality the foremost choice should be to do it in the framework. Language preference should always be the last possible place where enhancements are made. While there may be situations where the language level is truly the only way something can be implemented I would wager with a little extra thought these features can be implemented on a grander scale and benefit all users of the .NET framework.

Sadly though the term I’ve heard is differentiation of the languages – and having it mentioned as a feature. The VB and C# teams work on completely different levels and even the interfaces into Visual Studio are completely separate. If you look at the editors and editor models for VS.NET you’ll see that these interfaces are basically double designed. It’s a price that Microsoft has to to pay to support these two camps separately and basically re-inventing the wheel.

One good thing that comes out of this side by side development of compilers and compiler integration is that there is a sort of competition between the two teams. By god Microsoft doesn’t have much competition in this space, and maybe this at least drives a little bit of innovation and competiveness which is important to moving forward and enhancing the products. Cross pollination between the two certainly seems to be happening as developers ask for features that get implemented for one language in the other. Diversity, good.

So if you hear the term language wars or VB.NET people feeling neglected you should remember that behind it all there are more things that the languages have in common than there are differences. We're all in this together and I can't tell you how many times I've been saved by some kind VB programmer who's posted his code that helped me fix or find a solution to a problem. At that point does it really matter whether the code is in C# or VB when we're looking for concepts?

Yet I see this sort of thing in my BLOG comments all the time - can you post the code in VB? It's really not that hard to read code either way and as a .NET developer you probably need to be able to at least read 'the other' language.

We can all get along! I swear we can...

Feedback for this Weblog Entry

They're just tools
by Tim Farley March 13, 2005 @ 8:07 pm

Early in my career I used to engage in these sorts of arguments over which technology/OS/language/class library/linker/etc was better. But after a while, I came to the realization that these arguments are not about technical merit, they are about religious fervor.

Now when I encounter someone who is fervently pro-this or anti-that in technology, I ask them this:

Have you ever in your live encountered two workmen on a construction site, arguing vehemently over whether a hammer or a screwdriver is a better tool? No, you haven't. They're just tools, use the ones you prefer and get on with your work.

re: .NET Language Wars? Nah, we need Language Detente!
by Jeff Atwood March 13, 2005 @ 9:54 pm

> I know there are plenty of people who are not comfortable looking at braces and case sensitivity although those are merely syntactical elements.

Well, case sensitivity isn't just a syntactical element: it's the source of a lot of lost developer productivity, too. But don't take my word for it:

http://www.hanselman.com/blog/CommentView,guid,a393244f-bd14-49d3-b76e-ac94753e00d8.aspx

> If I had a nickel for everytime Case-Sensitivity or Case-Insensitivity bit me, I'd have like seven or eight bucks. Seriously.

There are a lot of items which fall into the "To-may-to, to-mah-to" category, but this isn't one of them. It's a serious productivity LOSS. The other biggie is background compilation: you have to buy JetBrains Resharper to add that to C#, which is why it's so popular (and mentioned as the first item in their promotional material).

re: .NET Language Wars? Nah, we need Language Detente!
by Rick Strahl March 13, 2005 @ 11:29 pm

I'll go along that case sensitivity in a language is not terribly useful - but I can't say that this is a distraction. I come from a Visual Foxpro background which like VB doesn't care about case (in fact most commands only need be 4 characters of the command), and it never occurred to me as a problem that I lost that going to C#. I do notice that my VFP code doesn't always play consistent with names and it looks messy as hell (the main reason for that is because VFP's Intellisense tends to shred source casing).

The only thing in VS that you type by hand tends to be stuff that you declare on your own. And I don't care if you're using VB or not, if you're not using the same case for your variables and constructs you're just writing sloppy code...

Strings are a whole other issue and the behavior there is the same in VB and C# so that's no argument.

Again, I think it's all about what you're used to. For example, I don't need to see what's wrong with my code the second I type it - I test frequently enough that I see soon enough what's wrong with my code <g>...