« Love the MSDN Product Feedback Center | Main | Catastrophic Success »
February 25, 2005
This is a multiple choice test, choose only one of the following:
From the comments:
> I’m proudly one of them. VB.NET is my favorite language.I agree with you, but unfortunately VB.NET is not *Microsoft's* favorite language, and it shows.
Guess how many lines of Enterprise Library code were written in VB.NET? Zero. If Microsoft doesn't think VB.NET is a worthy Enterprise language, who am I to disagree?
I hear this a lot "Microsoft writes everything in C#", "The framework is written in C#", "Enterprise Library is in C#", etc. Actually, Microsoft (to this day), writes most of it's stuff in C++. Using this logic, one would have to conclude that Microsoft doesn't think C# or VB.NET are worthy languages.
But their choice of language makes perfect sense. In fact, I strongly suggest that other companies emulate it.
1. If you're building operating systems, or 98+% of your code is currently in C++, plan on continuing to do a lot of C++ development.
2. If your developers are mainly C++ or Java developers, and you want to do stuff in .NET, then the most logical language for them to move to is C#. It's syntactically the most similar to C++, and it's conceptually very similar to Java. For the same reasons that VB6 developers are up and running faster in VB.NET, C++ and Java developers are up and running faster in C#.
3. If your developers are mainly VB, then VB.NET is the most logical choice. Microsoft has never been a company of mainly VB developers. However, many of Microsofts own internal IT systems were developed in VB. Guess what? Those developers moved to VB.NET, and many of those systems have been rewritten in VB.NET.
So what does Occam's razor say? (this is a multiple choice test, choose only one of the following:)
1. Microsoft is using .NET as a big, multi-billion dollar hoax, and will one day (likely on April fools) say "Ha ha, we've been using C++ all along. Suckers!"
2. The most logical language for the worlds most hard-core C++ developers to migrate to would have been VB.NET, and the fact that they didn't is proof that Microsoft doesn't believe in the VB.NET language.
3. C++ developers tend to move to C#, VB developers tend to move to VB.NET, and Microsoft had a crap load more C++ developers than VB developers on staff because Microsoft writes things like IIS, Windows, Office, and many other things to which VB6 wasn't well suited at all.
Oh, and what about Enterprise Library? Poll the architects and developers who worked on it. I'm guessing that they are all former C++ developers. You can tell by how it's completely over-engineered and way too hard to use for the functionality it provides. A VB developer would have never built it that way...
Posted on February 25, 2005 at 09:25 PM | Permalink
Comments
Right on Scott!
I posted a response in your Grumpy Grimes post that's relevant to this as well. Some folks just don't get it. Especially all those neo-C#'ers who defected from VB due to an overwhelming inferiority complex...
Keep up the insightful commentaries!
Posted by: Leigh Kendall | Feb 26, 2005 6:37:55 AM
Thank God! I thought I was the only person who found that stuff too hard. Happy to see that I'm not as dumb as I thought. One small thing- you say C++ developers - but my guess is that they were Java developers :)
Posted by: Sriram | Feb 27, 2005 8:49:05 PM
#3, naturally. It does concern me that Microsoft is not "dogfooding" enough internal VB.NET projects. If that continues, there is risk that VB.NET will get second-class treatment. There's ample evidence that already happened in VS.NET 2003, and the trend is disturbing:
http://www.codinghorror.com/blog/archives/000105.html
I also think Leigh is also right on target: I get the distinct impression that there has been a MASSIVE defection of ex-VB developers to C#. I can't say I blame them; VB.NET is such a radical change that they might as well change languages while they're at it. Why not pick the language that seems to get the most internal support from Microsoft?
http://www.developer.com/net/vb/article.php/3484506
> I have published two books on VB.NET. Today, few publishers are that interested in doing any more VB.NET books, because VB.NET isn't selling.
Very disturbing indeed. I observe the same pattern on CodeProject and in blogs. C# is extremely dominant, even amongst developers with a VB background.
Posted by: Jeff Atwood | Feb 27, 2005 9:08:21 PM
VB6 defectors were just waiting for someone to say jump so they could defect. None of them have gained anything from C# that they lost from the VB6 -> VB7 move, they just get to write the letter C more often on their resume and tell their friends how smart they are now that they can think of Public public PUBLIC pUBLIC and PuBlic as seperate words.
VBers do have and have always had an inferiority complex and despite the fact that .NET works hard to resolve the reason for it they still feel that way. Assuming C# gets more support it's because they run their mouths more. VB.NET gets webcast series, VB@ the movies, etc, etc. From what I've seen, Highschools teaching programming classes teach VB.NET more often than C# (why teach C# when they're teaching Java, I guess they figure).
But seriously though, once you learn either language you only need pick one for some petty superficial reason (background compilation and better intellisense for me). Look at the languages over time and see how they keep stealing each others thunder. VB8 gets Edit&Continue, C# wants it too. VB7 has modules, C# decides to call them static classes and claims it's created something original.
It's not about language ability, it's about style. I type my Basic keywords in lowercase, why? because since QUICK Basic I've relied on the editor correcting my casing as an assertion that the line I typed will compile. In QB this was all uppercase, in VB it's Pascal casing keywords and casing my identifiers. This may mean nothing to you but it means a lot to me. When I screw up I want to know about it then, not in half an hour when I decide to build.
Posted by: Anthony D. Green | Feb 27, 2005 10:22:30 PM
Sriram:> It does concern me that Microsoft is not "dogfooding" enough internal VB.NET projects
Yes, we are pretty sure you are losing sleep over this.
Sriram:> If that continues, there is risk that VB.NET will get second-class treatment.
Let me guess, another C#'er hung up over the fact that not only is VB the most popular language, but now its on par with a language in the C family?
Sriram:> I get the distinct impression that there has been a MASSIVE defection of ex-VB developers to C#. I can't say I blame them;
Yes, yes, keep on consoling yourself by spewing forth this ignorant rhetoric. If you say it hard enough, maybe it will magically manifest itself.
Sriram:> VB.NET is such a radical change that they might as well change languages while they're at it.
And this is the logic from one of the supposedly smarter C# developers?
Sriram:> C# is extremely dominant, even amongst developers with a VB background.
I mean honestly, whats the deal with some of these C# people? If the only way you can find to validate your choice of C# as a language involves bashing VB and entertaining fanciful notions, then you really need to see a psychiatrist. Anyone with anything resembling half a brain cell knows that these two languages are virtually identical and they are both here to stay. Get over it.
Posted by: Eric Mutta | Mar 2, 2005 4:15:36 PM
Well said Eric! Perhaps there's a new line of work for psychiatrists these days consulting neo-C#'ers who feel guilty for leaving VB behind and needing to justify their move? I'm sure one of the big drug companies could also come up with a new pill, perhaps called Csharperol, to help alleviate all those guilty feelings so they could actually get some work done... ;-)
Posted by: Leigh Kendall | Mar 3, 2005 4:39:58 AM
Leigh:> Well said Eric! Perhaps there's a new line of work for psychiatrists these days consulting neo-C#'ers who feel guilty for leaving VB behind and needing to justify their move?
Maybe I am one of those psychiatrists :D. I've found that if you exasperate them enough, you can charge a higher consultation fee and change their weekly sessions to daily ones, and they won't even twitch. Does wonders for paying those overdue credit card bills ;-)
Leigh:> I'm sure one of the big drug companies could also come up with a new pill, perhaps called Csharperol...
LOL, I'm working on a business plan even as we speak, because by the look of things the market will be worth megabucks when VB 2005 ships later this year. There's another customer on Paul Vick's blog (www.panopticoncentral.net , see the most recent post). And for coming up with a nifty product name, you'll get free stock options ;-).
Posted by: Eric Mutta | Mar 3, 2005 6:08:14 PM
>> you'll get free stock options ;-)<<
Wow, I *might* be able to retire and exit function this rat race you mean?? The wife will be very happy!
Posted by: Leigh Kendall | Mar 4, 2005 6:29:32 AM
Leigh:> Wow, I *might* be able to retire and exit function this rat race you mean?? The wife will be very happy!
Guaranteed, LOL. There isn't even a fine print :D.
Posted by: Eric Mutta | Mar 4, 2005 9:54:40 AM
If Microsoft had done C++ with .NET right the first time (now C++/CLI) there might not even have been a C#. See http://spaces.msn.com/members/jdanielsmith/Blog/cns!1pRjebUoVh0bNLSJvrecmAEg!147.entry
Posted by: J. Daniel Smith | Mar 8, 2005 12:05:30 PM
Thank god MS does Operating Systems, and Base Systems in C/C++. I'm a VB 6 developer, have worked with C++ in DOS times, even Pascal and Delphi, and litte assembler.
For systems that need to serve other systems I thing you have to go as near as the CPU as you can. C/C++ does that. Even if you can include routines in ASM, better.
For DB-centric applications, you don't need to make it make calculations as fast as C/C++ would do (compared to VB). Your app spends more time instantiating (ADO*) objects. So, its almost the same.
VB.NET is for business applications, c# is in the middle (there are things that can be made easier in VB.NET than in C#, ex. reflection)
C++ and unmanaged C++ for OS/base/engines. I think that's the way you should go.
Posted by: Luis Lobo Borobia | Mar 12, 2005 5:51:58 AM
I almost agree with you Luis, but it always bothers me when people separate .NET's twin langauges.
"VB.NET is for business applications, c# is in the middle"
statements like this perplex me because I can't see what puts them in different locations on whatever spectrum you're using. If you strip away all the synonymous syntax what do you have?
Library:
C#: .NET Framework
VB: .NET Framework + VB runtime library
Events:
C#: Add delegates to handle events
VB: Add delegates to handle events -OR- handles keyword for declaritive event hookup
Method parameter lists:
C#: Overloads achieve optional parameters
VB: Overloads -OR- optional parameter metedata
Interfaces:
C#: Uses member names to bind to interfaces or uses interface-qualified names to bind to interface members. Can't bind a method to members from multiple interfaces. interface-qualified names require cast to interface to use member.
VB: Uses declarative syntax to bind to interfaces, can use same name, can use different name, can bind member to members from multiple interfaces. Declaring a member as private requires clients to cast to interface to use interface member.
Casting/Conversion:
C#: System.Convert class + () casting operator, no distinction between an inheritance cast and a type conversion.
VB: System.Convert class + CType (Conversions or Casts) + DirectCast (Casts only)
Error handling:
C#: try/catch/finally
VB: Try/Catch/Finally + On Error
Function returns:
C#: return keyword
VB: Return keyword + methodname = returnvalue
Type binding:
C#: Variables must be explicitly strongly typed, can use System.Reflection namespace to dynamically (late-bind) variables
VB: Option Strict On, variables must be explicitly strongly typed, can use System.Reflection namespace to dynamically (late-bind) variables. Option Strict Off, variables needn't be strongly typed. variables late bound, could still use Reflection if you're really wierd, can turn this option on and off on a per-code file basis.
Variable declaration:
C#: must declare variables:
Point v = new Point(0, 0);
VB: Option Explicit On, must declare variables, option explicit Off, don't have to (can't be used with option strict on):
Dim v As Point = New Point(0,0) 'OR
Dim v As New Point(0, 0)
Platform Invoke/Unmanaged Interop
C#: DLLImportAttribute
VB: DLLImportAttribute + Declare syntax
Global visibility:
C#: can't do static type imports, must use Shared (static) members. static (Shared) members can only be accessed through type.
VB: Could use static (Shared) members but could also use modules. Can do static imports (meaning I could Import System.Console and not need to qualify its members). Shared (static) members can be accessed through the type AND through instances.
All I see above is a lot of cases where C# does it one way and VB could do it that way and has other additional ways to do it. Now for the real differences:
C# only things:
1. Unsigned integers and signed bytes (neither of which is CLS compliant)
2. Unsafe code (pointers) (also not CLS compliant)
3. odd undocumented keywords related to typed references and whatnot
4. Multiline comments
5. XML comments
#1 and 5 are being resolved in whidbey plus 5 can be done with addins.
#3 is so undocumented you probably didn't know it was an issue until I mentioned it
#2 can be such a marginal necessity if you write your code right. Even when P/Invoking native APIs if you write the method signatures right (it's unmanaged which means it's not type safe, you can fudge the types) you don't need 99.99% of the time. You might be able to do it with the Marshal class and IntPtr. On top of that, if pointers weren't enough to make you use C/C++ before it hasn't just become essential to you this week. There may be times when you need it. You have a couple options:
a. Switch your entire app to C#.
b. Write some helper functions in C# and reference them in a DLL.
c. Write a fullblown managed wrapper using C++ .NET
Note: I didn't bother to speak about the "importance" of 4
Miscellaneous things:
VB has a background compiler that gives compiler feedback as you type. It can cause slowdown if you open up a large solution with numerous project references and 1000 classes. To solve this you have to think a little differently. First step, don't open all the projects of your solution at the same time. Break things up, distribute them to developers and don't use project references. C# is getting Edit & Continue next version. Intellisense is being improved on both sides of the fence but bare in mind that though C# is case-sensitive intellisense is NOT. VB is getting some of those neat but at times irritating compiler warnings (At first glance C# should have smaller file sizes because of its unverbose syntax but a lot of VB constructs are autogenerated for you and some of the above syntax shortcuts + the With block make it even out in the end. For every line of code that doesn't break across multiple lines C# has an extra semicolon and comments take 2 slashes instead of 1 single-quote. Stupid little details like this go on for days. VB doesn't have out parameters we're old fashioned and use ByRef for these kinds of things. Cool technique I just figured I'd mention, you can use both using and Imports to alias types. Imports int = System.Int32 ... Dim i As int. The Using construct is someone convenient but it gets clunky when you have to dispose of a lot of stuff. Try/Finally works just as well.
Lastly, speed tests. There are lots of benchmarks online comparing .NET language speeds. Most of them are poorly written by people who don't know the languages well or were done against .NET 1.0 BETAs. Do not trust a speed test that compares C# using IO.FileStream to VB using FileOpen. The VB runtime and the VB compatability runtime are different - the latter is slower so don't use it. If your upset about an extra wrapper method call just keep thinking "The JIT compiler will probably inline it". Write code in a sickeningly identical way then do a speed test with equivalent compiler options (In VB you have to manually turn integer bounds checks off) IN release mode and call that a benchmark.
So yeah, maybe C# is a 99 when VB is a 100 when it comes to closeness to some underlying ideal but is that really important now? If that's a problem you don't need managed code, you need an assembler. In anycase it's certainly not enough to justify "VB.NET is for business applications, c# is in the middle". Learn both, trust me it's not hard. Once you have the framework down you could pickup either in less that 24 hours.
Posted by: Anthony D. Green | Mar 12, 2005 4:40:07 PM
So while I was off using Generics to solve all the world's problems, I went looking through the Express documentation for both languages. Ran into something I forgot to mention.
Properties:
C#: can't define parameterized properties. Can define and overload ONE indexer.
VB: Can define a default parameterized property (basically an indexer) but can ALSO define an arbitrary number of parameterized properties.
In a lot of cases this can result in more code on the C# side because C# apps usually return some lightweight collection class with its own indexer when an indexed accessor to some internal array might do as well. Advantages to both methods of course but only VB.NET can use both methods.
Posted by: Anthony D. Green | Mar 13, 2005 7:25:43 AM
A free beer for Athony I say, for that most appropriate summary :-)
Posted by: Eric Mutta | Mar 14, 2005 3:23:42 PM
The comments to this entry are closed.