'''Note: page renamed from I''''''sVisualBasicPreferredOverCsharpAtDotNet''' Is VbDotNet preferred over CsharpLanguage within the MicrosoftDotNet community? Could it be that there are far more users of Visual Basic who seem to be interested in .NET technology? Or does the construction of the newest version of Visual Basic have a greater potential for integration into the philosophy behind .NET? The question has been asked by recent attendees at a conference where all the talk seemed to emphasize VbDotNet. ---- I've spent a fair amount of time with both technologies (and have friends on both teams :-)): * Early adopters prefer CsharpLanguage, but VisualBasicDotNet has a larger installed base. * Up through and including Visual Studio 2008, the feature sets of VisualBasicDotNet and CsharpLanguage have been pretty similar. VisualBasicDotNet has significantly better XML support than CsharpLanguage. CsharpLanguage has iterators. * Both languages have had generics since 2005. * Both languages have identical levels of support for "OO" * Both languages have support for lambda/closures * Both languages have support for LINQ - VisualBasicDotNet query syntax goes a lot further before you need to write closures * VisualBasicDotNet has support for late binding, CsharpLanguage does not. * CsharpLanguage has support for pointer arithmetic (if you turn on /unsafe in the compiler), VisualBasicDotNet does not. * CsharpLanguage is case-sensitive, VisualBasicDotNet is not. * VisualStudio provides refactoring support for CsharpLanguage out of the box, it's a separate download for VisualBasicDotNet. * Intellisense is typically better for VisualBasicDotNet in the face of overloads. * Both languages get a lot of love inside the big house. Neither one is going to go away. * Some find VBnet's KeywordParameterPassing simpler (including C# developers who have already fallen in love with it for attribute constructors). -- ''DonBox'' ---- Microsoft has come out recently saying that VB would not gain all of the future features (such as generics), whereas C# would. All indications, as far as marketing goes, make it seem that Microsoft is pushing C# as the premier language. * See GenericsVsSubtyping for some discussion related to Generics, and comparisons with implementations in JavaPlatform. ''In April 2004, sources close to MicrosoftCorporation is offering a talk on generics and VbDotNet is cited as well. Have they got a change of heart? Or is it in the fine print anywhere that say generics for VbDotNet is more limited, has a longer wait time, etc?'' ---- From Microsoft's own lips: Visual Basic is now a first-class, object-oriented programming language that includes features such as implementation inheritance, structured exception handling, and free threading. In addition, we've created a new language, C#, as the first component-oriented programming language in the C and C++ family to combine the power of these languages with the functional ease of modern, rapid application development tools. Notice the distinction applied to each programming language: VbDotNet - (First Class) ObjectOrientedProgrammingLanguage CsharpLanguage - (First) ComponentOrientedProgrammingLanguage Does that mean the two are headed down separate paths? ''I wouldn't read too much into this emphasis. It has always been simple to create components in VB and continues to be in VB.NET. VB was not, however, strong on all object-oriented features. On the other hand, it has been historically more difficult to create components in C++. But C++ is already object-oriented. The bit of marketing spiel above is just emphasizing what is changing in the two languages.'' ''With that said, however, I do believe that the two are indeed headed down separate paths in some regard. There is no point for a company to maintain two languages that have the exact same feature set and differ only in syntax.'' Are generics, mentioned above, a component-oriented feature? ''No.'' ---- Here's my take. I have spent a lot of time in Redmond with the MicrosoftDotNet group (even turned down a job offer) and I have worked with MicrosoftDotNet now in non-research but production selling apps for two companies. There is no question in my mind on what language MicroSoft favors and promotes in most of the DotNet stuff, and that is CsharpLanguage. That is primarily because CsharpLanguage was designed as a CLR and DotNet language from the start versus the retro-fitting of VB.NET. Also, it makes the best use of the CLR features and is a first rate Component Language. I don't see a lot of attention being paid to VB.NET other than in the VbClassic community, where life will go on as it has. Most of the people on the MicrosoftDotNet mailing list at DevelopMentor and the people I know who are doing MicrosoftDotNet projects are using CsharpLanguage. At the company I worked for before, and the one I work with now, there was no question. Both companies don't do VbClassic period and we went right to CsharpLanguage. There is, in my mind, less and less reason to use VbDotNet. CsharpLanguage in its VS.NET incarnation has the same RAD simplicity of VbClassic and Delphi with the automatic form and the drag and drop controls coupled with a powerful ObjectOriented language and with a much terser and enjoyable syntax. Certainly, VbClassic is popular, arguably the most popular language in the world today, and will never go away. But CsharpLanguage is the current darling of Redmond in my humble opinion. -- sg On the other hand, the vast majority of code samples at TechEd Europe were in VB, not C#. -- PaulHudson Look at the audience. ---- VB.NET is missing a few features that C# has, and C# is missing a few features that VB.NET has, but the differences are minor. There aren't any strong technical reasons for favoring one over the other. The choice depends on your background and existing skill set - if you are a VB developer, use VB.NET; if you are a C/C++/Java developer, use C#. ''There is something that can be considered very strong argument in favor of VbDotNet: named and optional parameters. For example, calling Microsoft Office Automation interfaces without named parameters and default values is literally a nightmare. Lately, I saw that VB also supports varargs (they call it parameter arrays).'' VB.NET also provides easier late-binding behavior. C# does support parameter arrays (see the description of the 'params' keyword). And C# has several things that VB.NET does not, such as specifying a greater variety of data types in attribute contructors, being able to write "unsafe" code, operator overloading, etc. While there certainly may be individual tasks where one language outshines the other, I don't think either is a clear general-purpose winner. ---- What about the OtherDotNetLanguages? Is C# explicitly preferred over them? If so, will this continue? ''It's clear that Microsoft will be favoring C# and VB.NET over the OtherDotNetLanguages, but the others have their place. For example,'' * Managed C++ for integrating legacy C++ code into managed applications * JScript.NET for migrating JScript-based ASP pages to ASP.NET * J#.NET for migrating Java and VJ++ apps to .NET ''Uh. So my choices for .NET development boil down to VB, C++, Java, a thing that's a mixture of C++ and Java (C#) and Java script? Well, that's a great step... round in a circle back to where we already were. Does Haskell have a place? Mercury? Or is it a case of any paradigm you like so long as it's clumsy OO with a heavy procedural accent?'' There are places for everything. The OtherDotNetLanguages page offers several alternatives to Microsoft's favored languages, including both HaskellLanguage, MercuryLanguage, and Microsoft's own implementation of SmlLanguage. There is nothing unreasonable about Microsoft's decision to focus their resources toward the most popular languages among their customers. How big a market would there be for Microsoft Visual Haskell .NET? ''It's certainly not all roses. .NET is heavily geared toward the somewhat limited conceptulization of OO coming from C++ and Java (and now C#). This makes some languages very difficult to implement on top of it. A more general (and powerful) vm would have been nice; this way, it is more momentum for continuation of this programming style. I can understand why MS would do this, but it isn't *technological* reasoning, by any stretch.'' Right. How big a market would there be for "Microsoft Visual Haskell .NET"? A much, much bigger one than for "Haskell". Microsoft have the commercial clout to ''make'' a market for any technology they see fit. We know that there are groups within Microsoft who are interested in these technologies, so... ''Sure. But .NET is a limiting technology in some ways. It will be very difficult to put some languages on top of .NET, at least "properly", so even if a group wants to do it, it may not be possible...'' ---- '''There is no point for a company to maintain two languages that have the exact same feature set and differ only in syntax.''' Actually, there is a point. Some VB developers will resist learning C/Java-style syntax, and some non-VB developers will resist learning VB syntax. You may think that's stupid (and I would agree), but it is true. Providing alternate syntaxes for the same thing encourages acceptance of .NET by everyone. If there was one-and-only-one .NET programming language, the platform would probably suffer. ''Care to name some? I am a VbClassic developer, but do all current programming in C#. VbDotNet is not VisualBasic anymore, and I don't want anything to do with it. -- ThomasEyde'' One of the long-term effects of DotNet's MicrosoftIntermediateLanguage will be many languages that have the exact same feature set and differ only in syntax. Managed C++, C#, J# and VB are all drifting toward MSIL. ''Actually, C# 2.0 takes a number of steps away from MSIL - in the first version, just about everything mapped 1:1 from C# down to MSIL (in a similar way to how C maps down to assembly), but in 2.0, things like anonymous delegates and iterators introduce a fairly large amount of abstraction over the underlying implementation (see: http://www.interact-sw.co.uk/iangblog/2004/02/16/anondelegates).'' This can be seen as a good thing, in that choice of language no longer determines what is possible. It may eliminate the stigma attached to users of each language (VB is for dummies who can't write real software; C++ is for anti-social hackers; etc.). However, it will also lead to HolyWar arguments of the form "Your favorite language is no more powerful than my favorite language, so you should use my favorite language." ---- I suspect that, particularly post-Whidbey and beyond, VbDotNet will start to gain mind- if not immediately market-share as it starts to diverge in capability from C#. To take one aspect, irrespective of one's personal view of the practice, edit-and-continue in VB6 has had a powerful attraction to developers. Adjusting things like off-by-one errors during execution offered a substantial perceived efficiency effect. And VB had got better and better at handling run-time code changes over releases so it presented a perceived major hit when VbDotNet interrupted that flow, whatever the other benefits offered. Whidbey reintroduces e-and-c for VB; AFAIK, it won't appear in C#, because that community isn't missing something it never had. What I understand of the other scheduled language environment changes in the two languages is that C# is being pushed toward increased capability, while VB is seeking to offer greater developer productivity by delivering more high-level constructs. FWIW ;) -- MikeWoodhouse ---- CategoryDotNet CategoryComparisons