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
· The language and associated language-specific tooling, e.g., IntelliSense and refactoring
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!
--Scott
Comments
Anonymous
March 09, 2010
I'm not sure about the "roughly equal" language adoption of VB vs C#. There was rough parity around 4 or 5 years ago, but this doesn't appear to be the case any more. For example, take a look at O'Reilly's analysis of programming book trends over a 5 year period, where C# overtook VB back in 2006. Since then, VB has been in steady decline. For a more direct analysis, take a look at this independent Telerik survey for example, where C# usage outnumbers VB by almost 3 to 1! http://telerikwatch.com/2009/06/survey-says-c-still-more-popular-than.html Similar figures can be seen in a recent MSFT poll here too (and this is on a VB proponent's blog so the figures are likely very kind to VB!): http://geekswithblogs.net/iupdateable/articles/msdn-poll-april-8th-2009-what-language-would-you-like.aspxAnonymous
March 09, 2010
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.Anonymous
March 09, 2010
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: http://radar.oreilly.com/2009/02/state-of-the-computer-book-mar-22.html Google trends also has some fascinating insights: http://www.google.com/trends?q=vb.net%2C+vb%2C+visual+basic%2C+c%23&ctab=0&geo=all&date=all&sort=0 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.Anonymous
March 09, 2010
Thanks for the insights Scott! 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? Regards, AnilAnonymous
March 09, 2010
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.Anonymous
March 10, 2010
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.Anonymous
March 10, 2010
Scott, thanks a lot for your insight. 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.Anonymous
March 11, 2010
The comment has been removedAnonymous
March 12, 2010
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.Anonymous
March 12, 2010
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.Anonymous
March 12, 2010
Thank you for the clarification, because I was wondering....Anonymous
March 12, 2010
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.Anonymous
March 12, 2010
The comment has been removedAnonymous
March 12, 2010
Dear Sir plse help me plse give me a project in asp.net i am doing mca in III year sir plse help meAnonymous
March 12, 2010
abe sale maderchode muze mera project dede sale muze kya bhikari samaj rakha hai kya saleAnonymous
March 13, 2010
I hope C# (and VB.NET) will soon evolve to support returning multiple values instead of just one. Think of a construct like: [int result, string name] = myObjInstance.MethodA(); After the method call there would be 2 variables 'result' and 'name' representing the method's returned values. Of course it is possible to return a type that contains these values, however, it is not always convenient as you are required to define such types.Anonymous
March 13, 2010
The comment has been removedAnonymous
March 13, 2010
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.Anonymous
March 14, 2010
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!Anonymous
March 14, 2010
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.Anonymous
March 14, 2010
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.Anonymous
March 14, 2010
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.Anonymous
March 14, 2010
- 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
- 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. F# promises to be even faster, cause shorter.
Anonymous
March 14, 2010
The comment has been removedAnonymous
March 14, 2010
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. Rudy =8^DAnonymous
March 15, 2010
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...Anonymous
March 15, 2010
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.Anonymous
March 15, 2010
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. Big win for the Microsoft developer community. Circle the wagons and remember who/what we're really fighting!Anonymous
March 15, 2010
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...Anonymous
March 15, 2010
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. As to the C# versus VB wars, to me, it kind of boils down to: You say to - mate - oh, I say to - mat - o You say po - tate - oh, I say po - tat - o Let's call the whole thing off! ;)Anonymous
March 15, 2010
The comment has been removedAnonymous
March 15, 2010
Umm, then why the push to have devs migrate from VB to C# early on?Anonymous
March 15, 2010
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. You have the right approach, so please stick with it. Thanks StanAnonymous
March 16, 2010
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.Anonymous
March 16, 2010
To VB or not VB. 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.Anonymous
March 16, 2010
How come it's just VB vs C#? Gotta start keeping score for Python, F# and any other language that can hook the CLR and the VS IDEAnonymous
March 17, 2010
@Ernesb - In no way does Scott's article indicate that VB is the "natural" evolution for Visual Studio languages. RTFA again.Anonymous
March 17, 2010
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.Anonymous
March 17, 2010
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.Anonymous
March 17, 2010
In c# when you position cursor to brace "{" or "}" then closing or opening brace is highlighted. Can this be give attention in VB like "End If" will be highlighted when cursor is positioned to "If" and vice versa.Anonymous
March 17, 2010
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. ; )Anonymous
March 17, 2010
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.Anonymous
March 18, 2010
@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.Anonymous
March 18, 2010
Good Article. 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?Anonymous
March 18, 2010
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.Anonymous
March 18, 2010
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.Anonymous
March 18, 2010
The comment has been removedAnonymous
March 18, 2010
VB.NET should die. It's not a matter of preference, as much as it encourages bad coding habits, too much garbage and alien syntax.Anonymous
March 20, 2010
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.Anonymous
March 20, 2010
The comment has been removedAnonymous
March 20, 2010
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...Anonymous
March 22, 2010
To ms Programmer (hope former soon): 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.Anonymous
March 22, 2010
To Dave:, Your comment: "...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..." Is perfect, that is real evolution and most importantly it makes everyone happy, students, developers and employers. Scott, please read Dave's comment.Anonymous
March 22, 2010
The comment has been removedAnonymous
March 23, 2010
Sir, i am doing BCA it's my final semester and i want to become a expert in .net technology please give me better tips how i become a good programmerAnonymous
March 23, 2010
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. ThanksAnonymous
March 25, 2010
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 :)Anonymous
March 25, 2010
C# and VB became more stupid day by dayAnonymous
March 26, 2010
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.Anonymous
March 26, 2010
@Clifford Nelson: 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. ;)Anonymous
March 27, 2010
To Dave (March 20, 2010 12:13 PM) 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.Anonymous
March 29, 2010
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.Anonymous
March 30, 2010
@Lee 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.Anonymous
April 05, 2010
@switch/select users Who cares? Switch and select are antiquated concepts; they are relics of non-OOP programming. If you are using switch or select statements all over the place then your code needs some re-factoring.Anonymous
April 06, 2010
"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.Anonymous
April 06, 2010
The comment has been removedAnonymous
April 06, 2010
The comment has been removedAnonymous
April 07, 2010
gtrudeau......"Until you open MS Office and find a C# editor VB is the ONLY choice." Thanks for the laugh.Anonymous
April 07, 2010
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:
- Hiring good C# developers (easy) but watching them resign quickly and move to real C# shops.
- Hiring good VB.Net developers (hard in our market) and struggling every time they need to fill a position.
- 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. Just another perspective on the language choice problem.
- Anonymous
April 07, 2010
- 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.
- 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.
- 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!
Anonymous
April 09, 2010
This was a fascinating and very helpful statement. Thank you. 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. ARGAnonymous
April 11, 2010
The comment has been removedAnonymous
April 15, 2010
All this integration blablabla talk... but where is the deal? VB was always a language for hobbyist games. And with .Net we have 4 generations of XNA that don't support VB.Net at all. Looks like not all languages are created equal.Anonymous
April 18, 2010
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?) .Anonymous
April 29, 2010
@CProgrammer "New C# came out and it's simply impossible to think Object Oriented with VB writing !!" That comment says more about the developer than the language....time for a new profession maybe?Anonymous
April 30, 2010
There is not "my" namespace in c#. There is hard to code event for c# then in vb.net Code looks more readable in vb.net then in c# Debugging is more easy in vb.net than in c# I Have tried both language, And VB.NET is my choise We dont need to join with c# (because vb.net is leader) All must learn vb.net. C# is not needed more.Anonymous
May 09, 2010
Hey Scott, 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?Anonymous
May 10, 2010
The comment has been removedAnonymous
May 10, 2010
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 changingAnonymous
May 10, 2010
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!Anonymous
May 11, 2010
Just to make things clear, I love C#, I hate VB and I won't change my mind because there is no rational reason to do so. Let's leave Microsoft pursue its quest to let C# and VB evolve in parallel. This is a very good decision, as so many developers of both languages hope that their language of choice will be kept alive. Imagine that in 2 or 3 years time, Microsoft implements a new button in the toolbar where we will simply be able to switch between C# or VB view? Reflector does that from assemblies already. There are already some online converters between C# and VB. The future is the coexistence of both languages for many many years. But if you are to choose today which language to pick, get the good advice. VB is verbose, a VBer needs to read and scroll much more during the day than a C#er. I simply cannot get the VBers' argument telling that their language becomes clearer because of its verbosity. Question: What is more concise/readable?
int MyFunction(int value) { return value; } (C#) or Function MyFunction(ByVal value As Long) As Long MyFunction = value End Function (VB) 2. int counter; (C#) or Dim counter As Long (VB) 3. counter++; (C#) or counter = counter + 1 (VB) 4. } (C#) or Endif, End Sub, End Function, End Case, Next, End Loop, etc. (VB) I simply don't get why VBers feel sick when seeing curly braces or semi columns. Another point that is painful in VB: case insensitivity. Why on earth?
- Anonymous
May 13, 2010
The comment has been removed - Anonymous
May 13, 2010
The comment has been removed - Anonymous
May 13, 2010
"it's simply impossible to think Object Oriented with VB writing" The syntax to do anything object oriented in VB is so clumsy that there's no point. If VB overtakes anything it may overtake F# as the functional language.