VB and C# Coevolution

As we are approaching the release of VS 2010, I have seen a number of questions from customers about our language strategy for VB and C#.We made a shift in strategy at the beginning of this release cycle and have been talking about it publicly for some time.A lot of this discussion has been in forums that have a lot of early adopters, for example at PDC and other conferences, so I suppose it’s natural that we continue to see these questions.I thought it would be valuable to share my thoughts on this in blog form.

For starters, I should explain who I am and what my role is in this area.I’m the Product Unit Manager for Visual Studio Languages. In this role, I manage a portfolio of .NET languages (VB, C#, F#, IronPython, IronRuby) and the Dynamic Languages Runtime. I have a long history with VB (I interned on VB 1.0 before working on OLE Automation, VBA, VB4, and VBScript) and C# (I am one of the original C# language designers).

VB and C# both enjoy broad adoption. The most reliable numbers we have on the two languages show roughly equal adoption for the two. Together, these two languages represent the vast majority of .NET usage. As such, they are critical to our long-term developer strategy.

Our strategy for VB and C#, beginning with VS 2010, is a coevolution strategy. This is not the typical strategy for a portfolio of items. The more traditional portfolio strategy is to differentiate them, as P&G does for laundry detergents. For several versions, we tried to do this. We had an explicit strategy of differentiating VB and C#. We wanted VB to appeal to VB6 developers, who tended to build business-oriented, data-focused solutions. We wanted C# to appeal to “curly brace developers”, including C++ and Java developers, where there were more enterprise-class and ISV solutions. In practice, we found that it was quite hard to differentiate the two, due to the presence of several powerful unifying forces, which I describe below.

A modern developer experience for a language is formed through a combination of elements:

·A “horizontal” runtime like .NET that provides runtime services and libraries that are broadly applicable.

·A “horizontal” IDE platform or shell

·A set of “vertical” platforms and tools for building various kinds of software – Windows, Web, Device, Database, and on and on

Three of the four items above are common building blocks for VB and C#. This is a significant departure from pre-.NET products, where all of these were differentiated. “Classic” VB was differentiated across all four bullet points – it had its own runtime, its own shell, its own designers, and its own language. For VB .NET and VC#, the shared elements (the first three bullets) deliver a huge part of the overall developer experience. These common IDE and platform building blocks are the first “powerful unifying force” that I am talking about. For there to be language-based differentiation, it has to come from the fourth bullet point – the language and its associated tooling.

The second “powerful unifying force” is the nature of the languages themselves – they are both object-oriented languages and both have strong static type systems. So at a high-level, they are in the same family of languages. In contrast, some other languages in our .NET portfolio share a lot of the same building blocks but are farther afield from a language perspective – F# (functional), Python (dynamic) and Ruby (dynamic). As a practical matter, I rarely get asked why we have both C# and F# J.

There is a third “powerful unifying force”. As we began to evolve the languages after .NET 1.0, we found that the most significant opportunities were on the border between the languages and API’s. Our languages and runtime provide a set of building blocks, and API developers compose these to produce API’s.One way I think about this is that there are two kinds of language features: “on the outside” language features that grow or improve the set of API building blocks, and “on the inside” language features whose scope of impact is limited to the language itself.“On the outside” features include generics and the LINQ language features.“On the inside” features include changes to statements, expression and control flow.If we invented a new looping construct, that would be an “on the inside” feature – it would not impact API developers except perhaps as an implementation detail.We have done several releases since .NET 1.0, and in practice we have found that the best opportunities for language evolution and innovation have been in “on the outside” language features rather than “on the inside” ones.The most significant advances have been in “on the outside” features.

API designers are of course interested in having their API’s used by the broadest set of languages. To ensure this, we designed a Common Language Specification as part of .NET 1.0, and have evolved it in subsequent versions as we have added significant new building blocks. This approach helps us ensure that .NET API’s from Microsoft and others are accessible to a wide variety of languages. In practice, this also ensures that language evolution “on the outside” of languages cannot be used to differentiate languages. Thus, the third “powerful unifying force” is the Common Language Specification and trends in language innovation toward “on the outside” innovation rather than “on the inside” innovation.

Finally, we found that differentiation of language-specific tooling typically resulted in mixed feedback from customers. When we did a feature for one language but not the other, we received positive feedback from the language audience that got the feature, and negative feedback from the other. We found that the VB and C# customer bases were somewhat different, but not different enough so that they would want language tooling that was different. There might be differences in the priority of a particular feature (for example, edit-and-continue debugging for VB vs. refactoring for C#), but that in the long run, both customer bases would want the union of the features. Thus, the fourth “powerful unifying force” is customer feedback on language tooling.

For these reasons, we have adopted an explicit strategy of coevolution for C# and VB. By doing so, we recognize how strong these unifying forces are. We believe that we will accomplish more, and deliver more value for customers, by understanding and embracing these unifying forces rather than by fighting against them.

Our coevolution strategy has several major elements:

·Language innovation. Headliner language features (e.g., generics, LINQ) will be done for both languages, and done in a style that matches the host language. The languages will always be different – we will not try to make them “the same”. Instead, we will evolve them in the same direction, ensuring that both VB and C# developers can benefit from advances in programming models and API’s.

·Language tooling. Over time, we are evolving the language tooling so that customers of both C# and VB benefit from the same language tooling such as IntelliSense and refactoring features. We began this work in VS 2010. We made a lot of progress in this release, but are not 100% there.

·Samples and content. In general, we pursue parity for Microsoft samples and content. For better or worse, our Microsoft platform efforts are quite broadly distributed, and so there are sometimes shortcomings in this area. My team helps advocate for parity by working across Microsoft teams. We engage the VB community to help prioritize this work, so that we are spending our time and money most effectively.

I hope this is helpful context and background for our VB/C# coevolution strategy.Whether you are using VB, C#, or one of the other languages in our broad .NET portfolio of languages, we want you to understand what we’re doing (and why!) so that you can continue to use your language of choice with confidence.I’d be happy to answer any follow-up questions.Feel free to post questions or comments!

We have found that book sales have low correlation with language usage. A lot of books are really about a platform technology, and use one language or the other for illustration. Most publishers will not choose to do both a VB and C# variant of a platform technology title. This skews the book numbers substantially. We still watch them – we just don’t use them to judge language usage.

We look at a lot of data sources for language adoption, some public and some private. The ones we consider most reliable show roughly equal adoption for VB and C#.

That said, it is not critical to the strategy discussion above that the adoption numbers are near parity. The important thing is that we have a large number of developers using both languages. Whether the split is 50/50, 60/40, or 70/30 doesn’t change our strategic approach. The important thing is that we have a huge number of devs using both.

You’re right that book trends can potentially be skewed. I’m not sure exactly how O’Reilly broke down the figures in their study, but it’s an interesting article. Here’s the O’Reilly link if anyone’s interested:

I can only really go by the public data, but a 70/30 split comes up a lot (at least in professional circles). It would be interesting to see the "private" usage figures you guys have accumulated. I assume these are from sources such as the product usage telemetry in VS? A breakdown of figures by the various VS editions might be revealing (I’m guessing VB usage is going to be heavily weighted in the lower end editions such as the free Express version).

I guess the actual percentage swing between VB and C# is more important at a Microsoft management level when considering how the division’s resources are allocated and taking into account the time and expense incurred by devoting these additional resources to what is perhaps a minority language in decline. It’s got to be costly to expend all these extra resources to develop and maintain all this additional documentation, sample code, IDE tooling etc.

Will you release a language feature only when the implementation is finished in both languages?

I’m asking this because I suppose there will be features that will easily fit in C# but will require some extra work/time to make them work in VB as well (and vice versa). In that case, are you going to postpone the release of a feature for the first language until the implementation is finished for the second one as well?

Anil’s question hits on my only concern on this co-evolution strategy – now both languages have to move at the same speed. If one can implement a new feature reasonably fast, but it held up by the other language, I personally consider that a poor strategy implementation. As long as the respective language teams can make pragmatic decisions on when to diverge from co-evolution, I think this will be a good strategy.

I’m not a big fan of the language enhancements made to VB.NET since it’s first .NET implementation. Things like XML literals, IMO, really impact the long-term viability of a language, just as much a pushing T-SQL into C# (think C-Omega) would have shortened C#’s long-term viability. As you mentioned, the languages will always be different. C# has, to some extent, taken a minimalist approach to adding "on the inside" features, where I would argue VB has not. You could call this the aesthetic or culture of the C# language. Co-evolution of features can work; co-evolution of language aesthetics/cultures would be disastrous.

Re: Anil’s question, our approach is to have "on the outside" language features appear at the same time in both languages. In general, we plan for this outcome and resource the teams to make this happen.

This doesn’t mean that every feature in C# will be in VB, or vice versa. Two prominent examples are C#’s unsafe code feature (which we do not plan to add to VB) and VB’s XML literals (which we do not plan to add to C#). Neither of these features changes the set of building blocks that API developers use.

Personally I believe that the coevolution is a great step in the right direction. Both C# and VB.NET teams are innovative in their own way, and I believe that the effort being done to bring those 2 languages closer means, for me, more opportunities for innovation.

I don’t believe that this will make the things go slower on language evolution as some may think. In fact I believe that both C# and VB.NET can now have new exciting features added faster. As we all know, 2 team thinking on how to solve a problem are better than one. Most of the time  Considering both languages at the very begriming of the process of new implementations means that valuable input can came from both teams.

It’s important to know that independently of language adoption, MS commitment is to continue with this coevolution and in fact to improve it.

At the end of the day I believe that it’s the framework that will benefit from this approach. And that’s what matters. Not if you have to use curly braces or not.

danieldsmith: I’m not sure how the Google results can be interpreted. The proper total for VB is somewhere between the 1.0 score for vb.net and the 5.55 score for all three vb keywords summed. The former gives rough3:1 preference for C#, the latter shows an almost 2:1 preference for vb.net. The problem is that there’s no way to know how much of the VB and Visual Basic results are for VB.net and how much for VB6 and VBA.

The C# is potentially understated as well because google’s autocomplete tries to turn any "C# foo" query into "C foo". When foo is an element of the framework this generally works so there’s no benefit from fixing it.

I was trying to think if there any negative side effects can be expected from the described co-evolution of VB.NET and C# and really can’t think of any. Sooner or later (rather sooner for Microsoft put so much focus on such co-evolution now) two languages will be as different as Coke and Pepsi – some true experts can differentiate between those beverages but overwhelming majority of consumers don’t.

In a longer run I can see that VB.NET will be slowly pushing C# aside if both languages are virtually the same in platform and performance. The reason for that is because VB.NET is much closer to actual spoken language and therefore easier and faster to learn. People are passionate about languages to the point of genuine dislike but if everything you need can be achieved via any of two why would you be spending extra efforts for unclear reason to master curly C# instead of human like VB.NET? This how Darwin evolution works – it just takes shortest route to achieve maximum performance.

Taken into account everything going on in the world currently, I would say that the next step of Microsoft might be to clone VB.NET in some other major world languages, most likely Spanish and Mandarin. And since co-evolution of VB.NET and C# already proved to be moderately successful, there is a good chance that Microsoft would succeed in it as well.

I was interviewing for a position that wanted a VB.NET developer. Never used it before, but got an interview anyway. I purchased VB.NET and was struck how similar it was to C# to begin with. The integration between the two languages was striking. I personally think the co-evolution began with the introduction of VB.NET.

I think this idea of Coevolution of both languages is great. I am a VB developer who moved on the VB.NET some years ago and I am really happy about the way the VB.NET language matured with all the object oriented programming features.

There was a time where I bought some C# books because I thought that sooner or later I had to switch to C#. Some (not all) of my coding colleagues prefer C# and because of the hype of C# I thought that I had to do it.

Even after going through all the books and also after testing a lot of conversion tools for my old code I decided to stay with VB.NET.

I find it more readable and easier to use.

Thanks for adding the Auto-Implemented Properties to VB.NET as well. This will shorten my code and make it more readable if more commands fit on a screen.

you are perfectly right. We use computer languages (instead of machine programming directly) to have a very high abstraction level. And the target once a day is, to note down somthing like :’ Hey computer, please calculate the amount of screws we used the last fife month …’. Ever seen Startrek? And the first step in this direction is a computer language, which is able to write down complex algorithmns in a form that is readably as easy as your morning post. You are not an expert if you ar able to find out which curly bracket is allinged with som e other, you an expert, when you are able to bring complex algorithms to life and produce code as readable as possible.

C and later C++ have horrible syntax issues, C# make things really better and so the invention was a very important step. Now we should try to bring the ‘curly bracket enthusiasts’ to a new level of abstraction and try to help them to use a computer language which is as easy to read as your preferred morning post.

Grettir: I don’t think one or the other will get "pushed aside". Like you say, VB is an excellent language for learning. I started in VB6 and later VB.NET but switched to C# because I find that it’s faster to write and a lot easier to read (not as verbose and more structured). In the end, like most things, it’s about personal preference and I’m happy MS has decided to coevolve both.

On the translating of VB.NET, I think that would be a huge mistake. It would fragment the VB community too much and maybe even lead to it’s demise. Just think of all the code samples you wouldn’t be able to use because they’re in a different "dialect". Applications should be translated, not programming languages.

I’m very happy to see that VB.Net will get all the love it needs to stay ‘in sync’ with C#.

I disagree that developing in C# is faster to write than VB.Net. Curls, point-comma’s, brackets, … These are all things that have to be typed correctly or the program simply won’t run in C#. In VB.Net, the editor solves almost everything you ‘forget’ to write. With plug-ins like DevExpress CodeRush, VB.Net is really unmatched in development speed. As a side note, I’ve written in COBOL, C, C++, Basic (all kinds of variations) and even assembler. This is of course my personal point of view, but based on 20 years of development experience.

This is a great idea and support this step. This will increase the level of applications that VB.NET programmers can create. It will put them on par with C# developers. I program in C# and VB.NET depending on the project. The ultimate benefit here will be that employers can have existing VB.NET programmers expand their abilities to include C# level development. Also, C# developers will benefit by knowing that they can offer customers VB.NET as an optional platform if clients have existing VB.NET programmers on staff. You can say I Love You in many languages, but the output result should be as close as possible regardless in which one you say it and put a smile on a face. Great decision Scott!

I started programming on the TRS-80 Model 3 computer, in assembly. I’ve used many flavors of BASIC, both interpreted and compiled. I’ve also programmed extensively in C and C++. My prefered language was VB6 the majority of the time. When .NET was introduced, I immediately learned the VB.Net since at the time my employer used VB6 almost exclusively. When .NET 2.0 was introduced, the company standardized on C#. Reasons? C#’s development was more suited to enterprise development. VB, it appeared, did not recieve the same level of evolution. At that time, VB.Net simply did not provide the tools for the applications and productivity we needed.

Now, the IDE is what really determines my choice, which is C#. This is where efforts really need to be focused in my opinion. The IDE should not be what influences a developers decision in the .NET framework. Both VB.Net and C++/CLI, in my opinion, fall short of C#’s IDE without using 3rd party tools.

In my opinion, I would think that VB would eventually overtake C# in popularity. VB is almost self documenting. more intuitive and w/out the curly braces, more consise. It leaves the programmer with greater focus on solving the problem, and less focus on the syntax.

I started my professional programming career using Unix/C in 1985, progressing to C++ in the 1990’s.

Having also used a variety of 4GL’s such as Oracle, Informix and Ingres, the release of VB hit just the right spot for me. I have used VB ever since, now VB.Net of course and find that providing ‘best practice’ object oriented programming is followed, that VB.Net applications are easier to write and maintain (more crucial than you think) than my colleagues’ C# efforts.

All our new recruits prefer VB over C#, and our own metrics show that our VB applications are used for longer than their C# counterparts before needing re-writing. This is a factor related to maintainablity.

It strikes me that C# developers tend to try to be too clever and make use of every new language feature just for the sake of it, then they move on to a new job, leaving someone else to clean up their code.

Thanks for considering the VB community. We are very capable and are perhaps a but more street-wise with regards the true cost of software development and maintenance.

1. As long as state-of-the-art books from MS-Press contains samples in C# only, I have no choice but to buy them – even if VB.NET is my preferred language. That’s forpublisher’s statistics.

=> request: all MS-Press books must contain VB.NET and C# samples to make your promise true

2. In the 80s when I tought programming languages on VMS, usually the same test was finished first by Pascal, then Fortran … and at last by COBOL students. Thas is not to say that single students outperformed the others in any language. It’s just the average.

Nowadays I see similarities: given the same test, on the average the majority of my students using VB.NET finish before the average C# students.

Thanks for the info. I am glad to see the tooling getting better attention for equality. 🙂

From my journeys I believe you data on lanuage parity is dead on. I base this on real talk with developers. I think the Telerik and O’Rielly data are evidence of the need for getting the language specific tooling more equal. I recently changed jobs and went from a predominently VB dev environment to a C# environment. I struggled at first because of the lag in language tools in C#. We upgraded to VS 2008 and that helped, but they still need work.

Thus, IMNSHO the reason why C# books outsell VB books at O’Rielly. With the help and language tooling you can get farther in VB without having to buy books. I am looking forward to giving VS 2010 a test drive and seeing the new goods.

Hello, I am electrical engineer and I currently moderate the MSDN C# forums. I agree with the above comments about the C# IDE being better than either VB or C#.

I was out of programming throughout the ’90s. When I wanted to learn .NET I first looked at Visual Basic because that was where 50% of my experience resided. I quickly discovered that the C# IDE was better suited for learning .NET and the VB IDE was better suited for learning programming. Your comments suggest a desire to balance and erase these differences. Good idea.

If your team can figure out how to allow file VB and C# files, compilation units, to co-exist within the same project, that would be ideal. It would end the VB/C# wars.

I teach programming as part of my consulting work and VB.net is a very important part of that training. The students I’m teaching are NOT professional developers (at least not yet) they are re-training later in life, either transitioning out of other carreers or actually learning a career for the first time after a run of low-pay service jobs.

Adding the syntax complexity of C# to their first experience would just make my and their experience so much worse. Add on top of all of that that english may not be their first language…

I’m very happy to see the direction that MS is going in – even if it evolves into a 70/30 pro/jr spit…

Intuitively, I would think that learning VB would be more difficult for those who do not speak English as a first language. All of the VB keywords are in English, while C# makes extensive use of symbols found throughout mathematics.

Having watched (and participated) in the language wars for a long time, I think the lasting peace Microsoft is brokering (enforcing) is benevolence of the highest order. No more trenches, offensives, and embargoes for us. Letting the market decide seems to be working, but the important point is, developers and clients can now avoid having to make a stark, consequential choice.

To offer balance on the comments, I do not like VB. Too wordy. I find C#’s terse syntax to be much more readable. And, for the record, I spent the first several years of my programming life with VB. But when I converted to .NET, I converted to C# as well. I only use VB when I absolutely have to (maintaining existing code, mostly). On that note, I’ll be happy to use auto-implemented properties when the .NET 4 release hits. Now if we could just get some semi-colons into VB so statements could span multiple lines without the ugly underscore…

As I’m from a C/C++ professional background, I prefer C#. (However, I learned to program using BASIC and PAL/8 Assembly Language on a DEC PDP/8. So, I have an appreciation for many computer languages.) I’m definitely glad that C# and VB.NET will evolve together going forward as I’m of the mindset that we should let the developer choose which language they want to develop in and this pretty much guarantees that Microsoft is focused on making them equal in power and feature sets.

I think there is one significant difference between VB and C# that will be difficult to erase, although attempts are being made. That is the differences between their compilers.

The VB compiler is pretty friendly when it comes to variable declarations and other stuff, but can be made less so by declaring stuff like Option Strict On. It is fairly liberal. The more conservative C# compiler forced you to be explicit, very much like turning on the most conservative settings in the VB compiler.

Lately, it seems as if the C# compiler has had features that make it less explicit. For example, I see the misuse of the ‘var’ keyword questions disturbingly too often in the MSDN Forums. I have not noticed a similar shift to the right by the VB compiler, and cannot see room for it to happen.

Relaxing the original explicit requirements in C# would be a mistake. It would be comparable to removing the "plain English" simplicity of VB code. Just my opinion. Thanks for listening.

I started on assembly moved to BASIC, Pascal, Foxpro, back to Vbasic, C++, PHP, and finally to C#. Many of these changes were the result of changes in Microsoft guidance. I’m just glad that there isn’t a policy change away from either of these languages.

If you like C#, enjoy it. If you like VB, enjoy it. Why does there need to be a war? I personally love vb.net. C# seems more difficult, but when I need to translate it, with a little time, I can do so. In the end it is all IL and then machine code. So who cares?

It would be nice if vb source projects and c source could be in the same solution I guess.

In the old days C was preferred for somethings–especially quick low-level stuff, parsers, compilers, etc.

But I’d sure have hated to have written a business application in it.

In the same token. There are times when a C# application would allow pointers and such and perhaps make it much easier to do something that VB cannot. However for the rest of the time, IMO, VB.NET is much easier to use and read. It is much more intuitive to me. If a person has come from the C/C++/Java background, then obviously C# would be their preferred transition language because it is more familiar.

So I say let the both live, and to each his own in terms of the language of choice. Keep both as first class citizens of DotNet and you can actually make everybody happy–well except for those who want to stick with VB6 of course.

Someone (know as guille) who is admired for a lot of programers arround the word said!!

All good things start with two letters "VB".

I am happy to hear that microsoft finally understand that VB is the "NATURAL" evolution for the programing lenguajes for people and also going to give us the tools to still doing the "good things" in our favorite programing lenguage.

Microsoft needs to not have so many langages to begin with. They should keep the ones that most people uses – VB.net C# and VC++ – and get rid of the rest. My guess is that F# and ironruby will end up like J#, remember that thing? The more languages microsoft supports the more language wars like these, aand the smaller the developer pool is for that language and it will eventually drown out, making support harder for them, and finding jobs harder for professionals.

How about allowing the developer to change the limit to how many errors are reported by vbc.exe? This has been a constant pet-peeve, especially when dealing with projects upgraded from VB6.

If we could at least turn it off, we could see all the errors that had to be fixed at once (like C#), instead of seeing 102 errors after we’ve fixed 102 + X errors over two hours. That tends to destroy the determination.

I agree with Vai above. Why do we not have structural highlighting? It took Coderush Xpress to gives us structural matching (that’s all I use it for, at the moment). Why are these features not built into the language? It seems like a natural thing to me. But what do I know? I’ve only been programing for 33+ years. ; )

VB for me as long as it’s equivalent in power and speed. I have been a business developer for over 20 years. In my experience, timeiliness of result has a panache all its own. Sure, use structured, object-oriented, Model/View/Controller framework to the maximum extent possible, but get the question answered, the application done, the results ASAP first and foremost. Most code is baking cookies, not building brick houses. VB is the best for that. Maintenance takes longer? Maybe, but it’s still cheaper to rebuild and get V 2.0 if that’s necessary than to waste too much time trying to "get it perfect" and miss the critical need for completion.

@John – Why is VB the best for business apps? As someone who works in a shop maintaining apps written in VB and C#, I can honestly say that one language does not have any edge over the other. They both run on the same .NET framework. They both can be written easily using Visual Studio. They both have essentially the same language features. How does that make VB "best for that"? Just because you PREFER VB in and of itself does not make it a better language than C#. The whole point of Scott’s article is to point out that VB and C# are being treated as equals by Microsoft and that they are trying to close any functionality gaps that still exist between the two — and at this point, the differences are minor.

Recently, I was rejected in a recruitment process on interview location with a major IT company in India. And the reason for rejection was I am a VB.NET developer and the requirement is on .NET whereas they are looking for C# developers. Technically speaking, as an ardent .NET follower, I always treated both VB and C# equally. Now, I was really disappointed with the market’s perspective on differentiating these two languages which are propagated by MS to be under the .NET hood. It would be really a very bad idea if there are any hidden plans of making VB extinct in future.

Unless the market treats both VB and C# equally, there would be no use of MS strategy treating both these languages equally. So, I am in search of an answer for the future of VB as a .NET programming language in the market and how MS is trying to prevent these kind of myths?

Apparently both languages are "equal" but this equality starts vanishing as your applications get bigger and bigger. Surprising difference is not in language itself, rather it is due to poor support of VB.net in visual studio. Its interpreter starts killing your memory and CPU. So ny advise is , don’t think of this verbose language if your are building some serious stuff.

As someone who works with both languages on an equal footing, I’m very happy to see the coevolution in technical terms, but there is still a huge difference in the presentation of these languages. If you look at the Express edition pages – the only place where the products are separated – you can see that the marketing kicks in: VB is presented as a hobby or learning language for new developers and C# as a more powerful one for real developers. In real world terms that’s a very artificial difference.

If there was a law passed tomorrow that Microsoft must choose between VB and C# and only produce one of the languages, which do you think they would choose, yip, you guessed it, C#. They really need to get rid of VB now. Sorry to say but it’s been a long time coming.

Just imagine – there is no vb… there is no cs… all ms efforts applyed to development of cpp and its libraries and, as result, you need to know only one good language, and one powerfull base library – your time, money and efforts are saved and multiplied… the is no need to know all that garbage collection we have currently… BUT NOT, ms needs "new" languages… more and more and more again… languages with no difference actually, working only on single platform – it is stupid… You, sirs, are making careers on headache of other people… I will shift to java world… they respect developers…

Why would it have to be C++, just because YOU like it? — I’m all for using one base library, one interface, etc. But, just put different syntax front ends on it so each person can use the syntax they are use to using (or like to use) even though it access the same library. Better still, one front end that will accept all the commands and syntax’s from all the languages so you can use whichever you want in any scetion (or block) of code you want. That way it’s only the syntax that’s different, not the library or anything else.

You can argue for one language or the other. They all have their strengths and their flaws.

As I have sid earlier, I prefer C#.

In the end, it really doesn’t matter which language and libraries you use to accomplish a task as long as the objective was accomplished in a satisfactory manner and the user(s) are happy with the results.

The bottom line here is as a software developer, you should be first and foremost versatile. There is always more than one way to skin a cat and you should not be uncomfortable trying to skin the cat in a new way. If that means that part of your requirements are to develop in a language you have no personal experience with, you learn it the best you can and you do it. I realize that there are learning curves and time lines, and sometimes unrealistic expectations which is why communication up front is important. If you are uncomfortable with something, express your concerns right from the get go so that there are no surprises later. Be clear about what you can accomplish in the time frame given and there is no reason to fear a new learning curve, if you have given a realistic assessment of your capabilities within the given time frame and factored into your assessment the learning curve.

Most robust programming languages will give you the ability to craft a masterpiece or to shoot yourself in the foot. What you do with the toolset is up to you.

I do like the idea of Microsoft allowing us to craft mix blocks of code crafted in various languages within the same source modules. Then, again I prefer to manage memory myself and I like inline assembly language. 😉

Please inform Microsoft Press to get the C# 2010 books released. I have various books on order and the release dates keep slipping. It would of be great to have all the books out when .NET 2010 is presented next month.

Personally I think VB should have died years ago, (along with Access – but that’s a completely different story), so I’m kind of baffled as why you want to keep that language alive? But I guess that people that have been coding VB from the beginning, have just the opposite view on that 🙂

One of the things that could use improvement in C# relative to VB is the Switch statement. I think should just do away with the need for the break. By now C# programmers should know that break is not required. I also think that it would be clearer if the case statement was in curly brakets since that is consistent with C#, although C does not requre it. Maybe encourage users to use brackets instead of needing the break. Also would like to see the switch statement have the flexibility of the Visual Basic Select statement. If if provides better clarity (even at the expense of performance) it should be allowed. Also, would be great to have the continue statement like VB with the continue for, foreach, while, case.

C#’s switch is pretty close to VB’s select, except that it [switch] can’t handle floating point values.

For those a bit confused by your reference to continue, VB’s continue allows you breaking out of nested loops, depending on the kinds of loops being used. (This is one time where the "g" keyword can simplify what would otherwise be needlessly overcomplicated code. But we won’t go there, because too many people can’t bear the thought that "the banned one" might actually serve a useful purpose on rare occasion. 😉

OK, you are right. But, let us consider example. Large organization with complex infrastructure. To understand it in details you will need to know as many "front-ends" as it uses. It is not secret, the more possibilities people have, the more they will use. Thus, entropy will win and all "front-ends" will be present. And this means you should to know: vb, cs, fs, cpp, java, verious sciptings etc. corresponding libraries as well, complex libraries… And your knowledge must be good to be practical. It’s OK, but these languages are actually the same in the core. My previous post means that the most important part of software development process is personnel and it is very serious thing – do not spend their time and efforts uselessly.

PS: cpp is good language, I use it, but I am not bellicose fun of it, I meant only minimization of really needed knowledge to work professionally in real environment. I think, that if MS solve this task it will be really great.

Everyone’s brain works a little differently and it seems very clear that some brains find C# easier to read and write and some find VB easier to read and write. But the brain is very complex and we’d be guessing to infer anything from this preference about personality or other abilities. For me the preference is VB but many I know prefer C#. Thus both are likely to stay. And most of us like to brag about our ‘side’ just like supporting a team in sport or politics. Nobody likes it when someone takes the game too seriously however – especially when it’s equivalent to comparing our favourite colour.

Hmm, C#’s switch is by no means as powerful as VB’s Select Case. VB allows cases such as "100 To 200" or "1,3,5,7,9", which the switch simply won’t allow. The latter you can do in five lines, the former is just not an option (101 lines? Surely not!).

VB also has a bit more powerful Do..Loop syntax, allows multiple indexed properties (C# allows just one indexer) and has a more obvious way of Constructor chaining and using Finalize (~ is a bit ugly).

Then again, C# has "yield return", better arrays (without the extra element) and a more powerful for loop.

In the end these are mostly minor details to an experienced programmer. To the less experienced programmer VB is probably more readable (Inherits and Implements are surely more meaningful than ":", which can mean either of those two in C#).

But the one feature that makes VB a much quicker environment to work with in my opinion is the auto-syntax check. In C# I need a build to see the syntax errors – and another build to see whether my fixes worked. In VB these are instantaneous. I am alerted to any typo or syntax error immediately and this speeds up development quite a lot. That is the one feature I would love Microsoft to add to the next C# IDE.

"Switch and select are antiquated concepts; they are relics of non-OOP programming". Uh? they are needed when it makes the logic cleaner & easier to understand. I have a C# friend who does programming at NASA. They use it, so do I in our business systems.

It’s human nature to enjoy being able to exhibit some skill that leaves the others at a disadvantage. Look at me – I’m better than you. And we look on in admiration – oooh that looks so hard. It’s why we gawk at professional sports. But it’s an emotional weakness really. You mostly all miss the issue. You don’t see the forest from all the curly braces. VB will never die. As a corporate developer (15 years) the only logical tool to use is VB. Here’s why.

Look at the adoption of MS Office in the corporate world – all containing VB editor.

Look at the adoption of VB enabled third party applications – all containing VB editor.

Look at the adoption of Scripting to admin your Sevrer farms – all VB isn’t it?

Both are simply shims above the 32 bit API. Both different yes, yet fundamentally the same.

There has been nothing asked of me that I couldn’t do in VB.

Using VB I can get ‘under the hood’ of many third party apps and customise them to provide strategic advantage for my employer. Where’s C# in this scenario? I know, I know. You can write the fastest COM component ever seen this side of Mars, But how will you get ‘under the covers’ to call it?

One big difference between VB.Net and C# that I’ve run into is in recruitment, and the attitudes you get towards the languages. My experience is that (from the point of view of interviewers) if you’re a C# developer, you’re a "serious" programmer; if you’re a VB.Net developer, you’re not, and will only be considered for less skilled positions.

Regarding the "Right to Choose" movement (saying programmers should get to pick, there should be no difference between the two, and so on): that’s fine for very small jobs. Unfortunately, as soon as you get more than one programmer working together, you need to start to standardise. If you don’t choose a direction, your coders will standardise for you.

An anecdote: I worked for a company who didn’t officially "choose", but left their original coders go in whichever direction they wanted. They ended up building a large code-base in VB.Net. When management started hiring more programmers, they found that in our market, good C# coders vastly outnumbered good VB.Net coders. Now, they’re stuck with 3 bad choices:

2. Hiring good VB.Net developers (hard in our market) and struggling every time they need to fill a position.

3. Hiring mediocre VB.Net developers (easy).

They tried 2 but gave up, and started going with 1, just not telling us before they recruited us that we’d be working purely in VB.Net and would have to abandon the C# skillset we’d worked to build up (and then tried to convince us that personal preference doesn’t matter, and we should be happy using any language). When I left, they were discussing resorting to option 3.

So while it’s nice to say things like "developers should get to choose" and "there’s no real difference apart from personal preference", you can do yourself a lot of damage by choosing the "wrong" language. I’m not saying either language is "wrong" in general, but that in a specific market, for a specific project, either language could conceivably be a very bad choice, while the other one could be ideal.

1) The technical question is not VB.NET or C# as they are almost equal now. Any side can read, understand and refactor the other side’s code.

The question is, when should we start to include F# in our apps? Should we abandon WPF and directly go to Silverlight? Can we do this without learning XAML, Javascript and Ajax? When do we get Query Wizards for LINQ, so new hires don’t need to learn SQL any more?

This path to the future is where I need guidance: best practice samples, HowTo videos … The VB and C# product mgmt must interact with the F# team and embrace F# the way it happened with LINQ.

This is what creates the surge in training and maintenance cost over the next years: Teaching experienced coders new paradigms.

2) Management’s decision mostly happen on single, dumb rules. I know a European government which has forbidden VB.NET because "as the name says, it’s basic – not professional". Of course everybody ignores this, as the average VB.NET students code faster than C# students given the same task.

3) When you’re close to 60 like me, with 20+ programming languages on your back, you will agree:

It’s never the language, It’s the tools that make you successful. And this is where Microsoft outperforms Java. Thank you all!

I was particularly struck by this quote: "We wanted VB to appeal to VB6 developers". If this is the case why has the language drifted so far from the "Basic"ness it used to have. I’m not saying the language is bad, and it has responded to the overwhelming requests to be more object oriented. But in doing so you have made VB much less accessible: an accessibility that drew people to VB in the first place. I am still finding that it is much easier to develop in VB6 than it is to wrestle with the inevitable gotyas that I keep stumbling over every time I try to implement in VB.Net. I was overjoyed to see much more implicitness appearing in VB2010 – please, more! I don’t care if it is not good language practice, I want stuff to work without having to claw through pages and pages of inaccisible documentation or have buy an unaffordable book that may or may not include the documentation that is needed.

I certainly percieve a tendency toward over syntaxed languages (C# contains redundant syntax) and hard to grasp languages that are easy for C affectionados (Ie. all microsoft employees) but are incomprehensible to people with other language backgrounds – Cobol, Fortran, Algol, Pl/1 and Visual Basic. Even the new scripting languages are becoming harder to comprehend and I really do feellet down by the drift away from VBScript. Yes, I know it violates all sorts of languag design rules, but I can code stuff at 4 in the morning in an emergency and it works without having to scour half a dozen books to figure out what’s wrong.

One big area of difficulty is the strictness of the Type definitions and the profileration of incompatible collections. The requirement to explicitly Cast everything is very painful – and is probably a big reason that VB.Net is losing ground to Python and other scripting variants. It IS an order of magnitude HARDER TO USE than VB6. THAT NEEDS FIXED URGENTLY.

I am also sad that DDE support is missing from VB.NET. I still use applications that rely on DDE and I keep having to revert to VB6 or VBScript to continue to use them. I think that support should have remaind in VB.NET even if removed from the other platforms.

In short: I agree in principal with the direction you are going buit still fear that you need to do more to make VB.NET more acessible to VB6 and other new part time users. The present language appeals to full time users, but is really no use whatsoever to those who turn to VB to solve simple problems outside the scope of VBScript. VB,NET needs to appeal more to the casual programmer: that is it’s main differentiator to C# (Or should I call it DFlat).

Remember that someone with a typical Microsoft background is NOT the right sort of person who should be The Product Manager for VB.NET or designing the language.

I often find serious programmers get so immersed into their respective languages that they lose sight of what all this programming is for. It is going serve the USER to accomplish a certain task, period. The user wants to know this, does it work? The co-evolution is a great strategy and programmers that involve themselves passionately in the language war is not a professional. Personally I’d be happy with one language and be done with it. Why the hell do I want to able to order a beer in a hundred different languages, the word beer is just fine please. The easiest and fastest way to get the job done is what should matter. I realize the beer analogy is ideal and not real, but MS is on the right track. You should not have to fear about your job or interest if you open the mind. I’m not a heavy programmer, but I do know this, have a good understanding in programming concepts and apply it to the language that gets the job done.

I hate VB.NET !!! I used working with VB1-VB6 for many years and did many nice projects. But when it’s time to "release", I simply release. New C# came out and it’s simply impossible to think Object Oriented with VB writing !! So I left VB for good and start learning C#.

Today I know I did the right thing. When you code in C#/C/C++/Java/Javascript, it’s all gives you the ability to think Object Oriented. VB/VB.NET is for those people that still stuck in BASIC (That old commodore toy – remember?) .

Very good article and I like your VB/C# coevolution strategy. Have you and your team ever thought about taking the best of both languages and merging them into one powerful language? It may create a few headaches up front but would it not be more effective in the long run to break the language barrier for the two?

As I read the arguments for C# and for VB, I believe the bottom line reality in the working world boils down to one question: What is the department policy? If the boss says, "code in XYZ language", you code in XYZ language. If you don’t know that language, you learn it – and fast!

I believe that Microsoft is on the right track in enhancing the interoperability between the different languages. This can allow us to continue to use our "legacy" code base when the next boss says,"We are now a language GHI shop.". Remember, the boss may be a lot of things, but the boss gets what the boss wants.

I was a VB guy (VB5 & 6) but, got tired of C# programmers receiving more money and perceived as being better. Us VB (OK I’m no longer) people love to point out the adjustment to the curly mentality. But, as long as the beginners and the novices always start out in VBA or VB , it will continue to be slighted and those lesser programmers will impact in how the VB community is viewed as a whole. The curly brackets I feared, I now love. I also love it is less of a brain switch to go from VB to Javascript. And if a Java programmer has to work in .Net, he will of course pick up C#, which is syntactically near identical.

Which is the best language, in my book, is moot. But, I don’t see the above perception changing

Firstly, I’d like to extend my personal thanks to you guys at Microsoft for doing such an excellent job on the progression of VB from the VB3 era where I cut my teeth, through to the newest incarnation of VB.NET in VS 2010. In decline or otherwise, my team and I tend to jump around from VB to C# to JavaScript depending on the situation.

I find that new members of my development teams who, like me, have spent many years working with VB find VB.NET an excellent primer to the .NET Framework (where they may not have previously had much experience). Also, even after all this time, we still find VB to be the language of choice for rapid prototyping whereas C# development always seems to be more involved over the lifecycle of a development project. I, for one, would be very upset if VB were to be discontinued or neglected.

Again, our sincerest thanks to all there at MS for their continued fine work. Keep it up guys!

Just add curly braces to VB already, or a checkbox in options that switches from unreadable IF else end If syntax to curly brace syntax. That is the one thing VB really needs. Or add a checkbox in options to allow case insensitivity in C#. (That’s the only thing that keeps VB alive is case insensitivity, and if it was added to C# it would kill VB.)

"but if everything you need can be achieved via any of two why would you be spending extra efforts for unclear reason to master curly C# instead of human like VB.NET?"

are you nuts? how do you line up the beginning and ending of nested if statements and loops with crazy vb syntax? how can anyone find curly braces confusing? they get rid of all the confusion. If you indent your code (and Visual Studio does this AUTOMATICALLY for you) then you can see very easily where an if begins and ends even if you have a billion nested ones because curly braces make sense! You canNOT do that in VB. With an editor like Textpad you can put your cursor on a curly brace and click "match brace" and it will transport you from beginning to end or vice versa. I don’t know if visual studio does this but it should. but you can’t do that in VB, only in C#.

Now back in ancient times when people coded c++ in notepad and were too lazy to indent, then yeah the curly braces could get confusing but that doesn’t fly with Visual Studio’s automatic indention that keeps that from happening.