Are C# programmers masochists?

OK, normally I try to be pretty even handed about the whole “VB vs. C#” thing since we’re all one big happy family, but sometimes I just gotta wonder… Scott Wiltamuth (he’s the product unit manager for C#) was talking on his blog about the recent Office System Developer Conference and said:

Given VBA’s long history with Office, one might expect VB .NET to be the primary language among .NET developers using Office as a platform.  But I’ve seen a lot of anecdotal evidence that C# usage of Visual Studio Tools for Office (aka VSTO) is high.  I’ll try to get some solid data on this and share it here.

Which raises the question: are C# programmers just masochists? I’ve always kind of suspected, what with the case sensitivity, the cryptic syntax, the lack of declarative event handling, and so on. But it seems to me that programming against Office is one of those places where VB has got it over C# hands-down. Sitting on my desk are some chapters of a book that I’m doing technical reviews for. The book is about using Office from managed code, and several of the chapters (maybe the whole book, I haven’t gotten that far) are written in C#. So as I’ve read through the chapters, I just keep circling things and writing in the margin things like “this limitation doesn’t appy to VB” and “this code is simpler in VB.”

For example, VB supports optional parameters, named parameters and passing expressions to reference parameters, whereas C# doesn’t. So when printing, code that in VB looks like:

Doc.PrintOut(Copies := 2, Collate := true)

Becomes in C#:

object copies = 2;
object collate = true;
Doc.PrintOut(ref missing, ref missing, ref missing, ref missing,
ref missing, ref missing, ref missing, ref copies,
ref missing, ref missing, ref missing, ref collate,
ref missing, ref missing, ref missing, ref missing,
ref missing, ref missing);

There are other various little gotchas sprinkled throughout Office (like the fact that C# can’t bind to Word’s Close event and VB can, although I think VSTO finesses this a bit), which raises the question: why would you use C# instead of VB to automate Office unless you were a bit of a masochist?

OK, OK, OK, I’ll admit it – I’m only half serious here. I don’t really think that C# programmers are masochists who whip themselves on the back every night chanting “I will initialize all of my variables, I will initialize all of my variables” and wear their “I Am Strongly Typed” hairshirts under their clothes during the day. In fact, I have it on good authority that many C# programmers are normal, well-adjusted members of society. But that doesn’t mean I can’t razz them a bit every once in a while…

52 thoughts on “Are C# programmers masochists?

  1. Pingback: Richard Clark

  2. Pingback: Richard Clark

  3. Scott

    Is that C#’s fault or the MS Office teams fault?

    Maybe if they quit using interop and wrote a true managed interface for Office it would be easier in C#?

    The "no optional parameters" thing is wonky, but I usually handle it using overloads. Could you do the same thing in this case?

    Reply
    1. paulvick

      Scott: You’re absolutely right that the best of all possible worlds is that Office writes a true managed interface that removes the COM legacy (thus erasing VB’s temporary advantage in writing against Office). My questioning was solely within the bounds of "given the status quo at the moment…" and not intended to say that I think the status quo is an ideal situation.

      Reply
  4. Jeff Atwood

    Case sensitivity is wrong in every imaginable way– even Scott Hanselman was complaining about this recently– but I think the odds of that ever changing are nil.

    Thanks K&R you bastards!

    C# *wishes* they had the Ain’t keyword like we do. But seriously, it is actually kind of depressing how prevalent C# is and how strong that bias runs in every corner of the .NET developer community.

    My biggest gripes with C# are lack of background compilation and case sensitivity. In VB.NET if I want to find out where a variable or function (or SUBROUTINE!) is used– I rename it. Poof. Instant task list full of every place that item was referenced in the code.

    I would consider using C# more in 2005, if I get a tool that provides the missing background compilation support.

    Reply
  5. Jeff Atwood

    > and how strong that bias runs in every corner of the .NET developer community.

    I should have emphasized– NOWHERE will you observe this bias more strongly than at Microsoft. I guess it’s because most MS devs come from a C background, but zero MS Enterprise Library source code in VB.NET? Ouch. That’s gonna leave a mark.. on our credibility.

    Reply
  6. Pingback: Webmatrix e asp.net

  7. Michael Giagnocavo

    So, C# users are bad because some one elses API sucks? ok….

    "My biggest gripes with C# are lack of background compilation and case sensitivity. In VB.NET if I want to find out where a variable or function (or SUBROUTINE!) is used– I rename it. Poof. Instant task list full of every place that item was referenced in the code. "

    Was that in jest? First, this has nothing to do with the language, only the IDE. Second, did you know VS has a little feature called "Find Refernces"? Thirdly, C# compiles so damn fast, that if for some absurd reason I wanted to mess up my code to try and find references, I can just hit…. Build.

    I don’t think you can blame MS for lack of credibility πŸ™‚ πŸ™‚

    (Full disclosure: I was extremely pro-VB back when .NET came out. I even wrote an encrypted loader compiler for .NET in VB.NET. Then I woke up one morning and just felt C# was the correct way to go, and haven’t looked back since.)

    Reply
  8. Jeff Atwood

    > Then I woke up one morning and just felt C# was the correct way to go, and haven’t looked back since.

    That’s an inspiring story. Have you considered optioning the movie rights?

    Reply
  9. Pingback: Code/Tea/Etc.

  10. Pingback: Code/Tea/Etc.

  11. Leigh Kendall

    >>(Full disclosure: I was extremely pro-VB back when .NET came out. I even wrote an encrypted loader compiler for .NET in VB.NET. Then I woke up one morning and just felt C# was the correct way to go, and haven’t looked back since.) <<

    What, did it come to you in a dream or something? Or did some big bully yell at you and claim you weren’t a real developer?

    Reply
  12. Michael Giagnocavo

    VB started feeling too verbose. I mean, come on "CType(foo, Bar)"? VB is verbose, yet still not explicit. (OK Option Explicit helps some.) It just peaked one day. Go dig up my old newsgroup posts and you’ll see I was quite pro-VB. Just got tired of it I guess.

    Reply
  13. mike brady

    I do prefer using C# for most things. But after reading this post I might consider trying VB.NET for my Office automation tasks.

    I have done a bit of Powerpoint programming using C#. It is like programming in butthole.

    Reply
  14. haha

    poof, why are you even having the "discussion" here? Use the tool that’s best for the job. Mike has the right attitude!

    Besides depending on what you’re doing, you could get away with creating a few wrappers in VB and doing your main stuff in C# – better yet, you could delegate this job for a VB guy πŸ˜‰

    Reply
  15. Brian

    Dear me, I must be from the ice age then! I love coding in C/C++/Perl. I actually find case-sensitivity useful and I don’t even mind managing my own memory, coz, you know, I already need to manage the other resources like CPU, bandwidth etc.

    And yes, I’m a weakling, I will never be seen dead around VB or Java. MS (and Sun) are doing a great job of dumbing down programming. What is comforting to know is that this dumbing down is driven by management; most internal MS developers love C/C++.

    Reply
  16. Avner Kashtan

    Let’s just put it this way – I’m glad digital camera manufacturers have dumbed down their products so I can just use them to take pictures – which is what they’re FOR. I’m glad automobile manufacturers have dumbed down cars to the point I can drive them, which is their intended purpose. Remember – managing memory is not a goal, it’s just a means to an end.

    Reply
  17. Avner Kashtan

    And just to stay vaguely on topic: I’m a former VB6 coder who switched to C# because the syntax simply /works/ for me. I wouldn’t mind giving up case sensitivity, but after a few years with C# VB simply feels too verbose and… chunky? Something like that.

    However, I will be the first to advocate, loudly and strongly, the use of VB.NET for Office interop. If I never see another ref missing, it’ll be too soon. πŸ™‚

    Reply
  18. Mono

    I’ve been using vb6 for years, and recently switched to c#. At first I was annoyed by the case sensitivity, but then I realized how powerful it was. myVar and MyVar are different things, and in c# you can actually use them both, rather than having to think up some cryptic variation.

    I spent some time with vb.net before c# too, and I refuse to ever go back to vb hell. c# forces good programming habits on you, and I have been greatly rewarded by much more readable code, and far fewer bugs.

    So while using c# may require a little more up front effort, debugging vb apps and maintaining them is where the true masochism lies πŸ˜‰

    Reply
  19. Kevin Welsh

    >>myVar and MyVar are different things, and in c# you can actually use them both, rather than having to think up some cryptic variation<<

    So I could define/dimension a variable north as type DirectionOnACompass and North (capital N) as type SectionOfTheUS? Cool Beans!

    How is changing the case of a letter(s) in a variable name less cryptic than using a name that describes what your modeling?

    Reply
  20. Mono

    A better example would be a public member of a class, and a parameter in a method within the same class.

    public string Filename;

    and

    public void SomeMethod(string filename);

    for example.

    Reply
  21. Larry Asher

    A better example would be a public member of a class, and a parameter in a method within the same class.

    public string Filename;

    and

    public void SomeMethod(string filename);

    I don’t think this is a better example at all. It may be time to leave hungarian notation behind. But, I still think some naming convention could be of benefit. If I am reading some code and I see variables named filename and Filename what does that tell me?

    I would at least like to know the scope of the variable. Consider the following variables FileName, mFileName, and gFileName. Where FileName is a local variable, mFileName is limited to the module/class/etc. and gFileName is a global variable. Using this convention I know what a bit more about the code and avoid a ambiguity. To me Filename and filename are just too ambigious. It shows a lack of proper definition and is really not explicit and reflects more a lack of proper definition.

    Thats my two cents.

    Reply
  22. csj

    You can use this.fileName instead of m_fileName for attributes, this.FileName for methods, FileName for class and fileName for local variable. This is the new Microsoft standard. You have to conform to it.

    Reply
  23. csj

    I think the case sensitivity is good for keeping you to write all instances of the identifiers conforming to the same standard: beginning each word in an identifier with a capital letter. It coud have been done with underscore too: file_name.add instead of fileName.add, but that underscore makes the dots less visible.

    Reply
  24. csj

    And if you think that it is good with all lowercase, why do you think that in the ordinary writing there is a word separating space? If it wouldn’t be, it would be hard to separate the words of a sentence. OOP is a good enough model of the written natural language.

    Reply
  25. Pingback: Panopticon Central

  26. abstractsagacity

    I guess MS was just assuming that C# developers knew what they were doing and didn’t need red squiggly lines to correct them every 3 seconds πŸ™‚

    Reply
  27. SpookyET

    This article is one big troll. Expressive events syntax?

    C# (same as Boo):

    boo.SomeEvent += SomeMethod Plus tells you that it adds a method

    boo.SomeEvent -= SomeMethod Minus tells you that it removes a method

    SomeEvent() The parenthesis tell you that it raises it.

    Do you really need full words?

    VB:

    AddHandler boo.SomeEvent, AddressOf SomeMethod

    RemoveHandler boo.SomeEvent, AddressOf SomeMethod

    RaiseEvent SomeEvent

    Now, the above is the short syntax.

    C#: boo.SomeEvent += new SomeEventHandler(SomeMethod)

    VB: AddHandler boo.SomeEvent, New SomeEventHandler(AddressOf

    SomeMethod)

    C# has its C syntax just like VB.NET key some of its VB6 syntax.

    Word’s close stuff is probably COM, and VB has something like duck typing that

    binds to COM directly. C# needs work, but I’m sure you can actually

    bind to it.

    C#’s syntax is not cryptic. VB’s syntax is almost Enlish.

    ———————————————————————–

    The most useful way to use case sensitivity is with variables and properties.

    class Foo

    {

    private int number;

    public int Number

    {

    get

    {

    return number;

    }

    }

    }

    Reply
      1. SpookyET

        Paul: Oh. Yes, but there are issues with WithEvents/Handles when you do dynamic addition/removal on that object. Yet, it’s a cool feature. If MS gave you access to C#’s AST, you could add that with an attribute. I’m doing that for Boo (boo.codehaus.org) right now.

        class Greeter:

        event HelloSaid as EventHandler

        def SayHello():

        print "Hello World"

        HelloSaid(self, EventArgs.Empty)

        class GreeterUser:

        greeter = Greeter()

        def Use():

        greeter.SayHello()

        [Handles(greeter.HelloSaid)]

        def OnHelloSaid(sender, e as EventArgs):

        print "OnHelloSaid() called."

        PS: There is no need for an [WithEventsAttribute]. It’s not even needed in VB, they just brought it from VB6 and forced you to use it.

        Reply
        1. paulvick

          Spooky,

          WithEvents is needed because it’s not entirely semantically inert. When you put WithEvents on a field, it converts it into a property under the covers, which subtly modifies its semantics (for example, fields are passed by reference to a reference parameter; properties are passed copy-in/copy-out). Having the insertion or a deletion of an event handler cause the semantics of a field to change seemed obscure at best. (The modifier also makes the IDE a little better because it means we know which fields source events you care about.)

          I believe we allow you to handle events on shared withevents fields, or am I misunderstanding?

          Reply
          1. SpookyET

            Have a look at this screenshot http://img23.imagevenue.com/img.php?loc=loc77&image=d9c_CleanBoo.JPG

            I wanted to create a WithEventsAttribute that would mimic Visual Basic, but people complained. So, my implementation takes care of the property in HandlesAttribute. It looks for the property. If the property is missing, it creates the property and renames the field. So, in reality, it is not really needed.

            There is one problem with the Visual Basic implementation. It allows you to define:

            Public Dim WithEvents foo As Foo = Foo()

            It should complain if an accessor other than Private is used because the field/property will have a Private accessibility (Beta 2).

            According to the documentation, "You cannot use WithEvents to declaratively handle shared events, since they are not tied to an instance that can be assigned to a WithEvents variable."

          2. paulvick

            I misspoke slightly: what I meant was that while WithEvents isn’t absolutely needed, from the perspective of the language, we feel it is needed. Having a Handles change the semantics of a field into a property seems to obscure. However, reasonable people can disagree on this point. πŸ™‚

            The generated property should always have the same accessibility as the original field and the field’s accessibility should be changed to Private. Are you seeing something different in Beta2?

            And, yes, that last point is correct. IIRC, the issue is around lifetime. If an instance member handles a shared event, then the instance will never be released because the shared event will hold on to a reference to the instance for the lifetime of the application. I think we were worried this would be too obscure. I guess, in theory, it would be OK for a shared method to handle a shared event, maybe something for us to think about…

          3. SpookyET

            What I’m seeing is that it allows one to use other acessors than Private. The field and the property will be Private regardless of what accessors were orginally there.

            So, someone might try to access the field and get and error saying that it is inaccessible. They won’t understand how it is inaccessible since they declared it public/protected/internal.

          4. paulvick

            Spooky: I’m not seeing this. If I have a Public WithEvents field, the underlying field is private but the property is Public. Why don’t you use the contact form to send me a repro and we can discuss in email to see if we can track the problem you’re seeing down?

      2. SpookyET

        Also, my [Handles] attribute works on static (shared) object that have events. Should I limit it to instance only? I don’t understand why the choose to limit to instance only in VB.

        Reply
  28. Pingback: KawaiiAT Journal

  29. Poliglota

    Sad but most of the complains about C# posted in this forum shows that the programmer spent so much time learning VB6 that never gave himself time to REALLY learn POO (and I mean REALLY, not just reading a couple of books)… If you really know what you are doing (and not just typing statements on a "notepad"W

    as they come to your mind) you’ll be able to notice that you can build the same program in C# in a more flexible, reliable and clever way…

    If you need things to complain about I’ll give you some clues: No "Throws" definition for methods, Assemblies Hell, Problems with Visual inheritance, Typed Dataset inheritance… But anyway you will find that those are .Net probles and not C#…

    If you feel fine coding in VB, go ahead, you’ll be able to use the framework and get the work done… But if you really like to do it right, I suggest you start looking other horizonts…

    I’m not saying C# is the best, but I really thing MS did a great work… I’m someone who knows more than 10 different programming lang and at least 4 different development "religions", and yet can’t decide which one is the worlds number one… After several years I just learned that the right tool depends not in the tecnology but in the problem….

    Reply
  30. Scott Holodak

    As far as improving your skills as a programmer, the C sytax will get you a lot farther. Getting over the case sensitivity, adjusting to {}s, etc. gets you one step closer to learning C++, Java, PHP, Javascript, etc. I feel like that’s a pretty good justification for the industry favoring C# over VB. There aren’t [m]any VB similar languages out there that aren’t Microsoft’s. Another thing is that once you’ve made the switch, you’ll prefer to read code samples in C#, but you’ll be able to read VB.NET code just fine. The same generally doesn’t apply in the other direction.

    Also, I think there are advantages to case sensitivity. The thought of having to take over a VB.NET project written in caps lock makes me shudder. In a company with hundreds of developers with their own different styles, it’s nice to know that the compiler, not the IDE, enforces the case of the keywords and functions. Typically, the only major style difference you’ll find between two C# developers (even if they’re using a text editor) are the positioning of the {braces}.

    Reply
  31. Pingback: Panopticon Central

  32. Holly Johnson

    C# programmers are programmers. VB programmers are cry babies who need built-in functions because they’re either too dumb or too lazy to make their own. And yes, VBers take every little opportunity to make C# look bad. VB sucks. VB programmers can’t even write readable CLS compliant code because they come from Visual Babytalk to a real language. Sit down, stand up, go home.

    Reply
  33. Josh

    I used to program in QBASIC, VB6, and VB.NET. Then I switched to C# because I love the C style syntax because of the flexablity and elegance it offers. C#, Java, and C/C++ are just better than VB and thats all there is to it. VB is for begginers and it is usefull for prototyping apps and mabe a few other things. Basic stands for Beginner’s All-purpose Symbolic Instruction Code. Thats all there is to know.

    Reply
  34. matt

    I am not a programmer; I mostly use PHP, actionscript (flash) and MySQL to build web stuff. However, I have played around with C# a little bit to make personal tools etc.

    Having said this, I was shocked to come here and find out that some "real" programmers whine about case sensitivity. Even to me, the difference between thisIsAFunction, thisisafunction, tHisafUnctiOn etc. is so huge that I wouldn’t dream of thinking they were the same thing. I can see why VB has a bit of a preschool reputation now. Amazing.

    Reply
  35. Tom

    I’ve been programming for about 6 years (since I was 11) and I started in VB6, I moved to VB.Net about 2 years ago. I finally switched to C# about a month ago and already I’m nearly as efficient as I was in VB. I can honestly say it was the best decision I ever made.

    There’s just something of an elegance in the way that C# flows. I used to love VB but looking back on it now it just seems so… big and chunky. VB is like playing with Duplo and C# is like playing with proper Lego. The ironic thing is I used to slag off C# all the time saying that it was overly complicated but now I see that VB is just overly simplified.

    We can’t expect to maintain the programmers way of life if we make things so simple that anyone can do it. We’re supposed to be an elite community at which the mind of others’ boggles. If programming gets too easy then we’ll all be out of a job, and besides it’s fun staying up till gone 3 in the morning trying to unravel some seamingly sourceless error that suddenly jumped out of nowhere πŸ˜€

    Reply
  36. Ed

    I have been writing software professionly since 1987. I have used many different languages over the years: RPG, COBOL/Z, FORTRAN, ASM/MASM, PASCAL/Turbo Pascal/Delphi, CML, BASIC/GBASIC/VB/VB.NET, C/C++/C#, LISP, and Smalltalk. Don’t even mention all the data languages. Over the years, there have always been heated discussions over the languages. What holds true is that as the systems evolve so must the languages. I would hope that the developers do too.

    Reply
  37. Jens Hykkelbjerg

    Okay so C# can’t use optional parameters

    Okay so C# can’t use "Resume Next" in error handling

    Okay so case sensitivity in C# makes the code harder to read (only if it’s used)

    Okay so a beginners will have trouble understanding for loops

    (for(i=0;i<10;i++) {…} is a bit cryptic unless you already know C)

    Okay so C# can use inline assignments making code harder to read

    if (isOpen == true && isReady=readyTest()) { … }

    Who notices that the variable isReady is not compared to ReadyTest, but is in fact assigned to the result of readyTest?

    But none of the above makes C# a bad language.

    My experience is that what’s important is that code should be easy to read and understand (That makes code maintainable).

    Some of the differences between C# and VB makes it possible to write C# code that’s more difficult to read than the same written in VB. (case sensitivity is a good example…)

    However a good C programmer will usually avoid doing that, so C# code can easily be as readable as VB.

    However that being said, I still like VB more than C#.

    Oh and by the way I’ve stopped coding in VB and currently use only C#. But not because I dislike VB, only because everyone else seem to use C# for some strange reason…

    Reply
  38. Geoffles

    I tried learning programming with VB6. It didnt make much sense to me. I tried learning programming in Delphi. That made much more sense. My favourite language is actually C++. Languages like C, C++,C#, java and pascal tend to have a far more consistant approach the language stucture.

    In VB, the syntax for calling a object methods and functions is different to the syntax for calling a subroutine, why?

    Fact is, anyone who actually knows how a computer works should understand that useful "tools" for avoiding logic errors would include strict (consistant) structure as little ambiguity as possible.

    Case sensitivity, explicit expressions and strong typing are useful for that. Forcing you to intialise your variables is a smart move too. Uninitialised data could be anything.

    I often hear about VB "Coders" who know absolutely nothing about real programming and who write abominable software. I interpret that as VB damages the image of the software development profession and not only allows but encourages poor practices.

    VB sucks. Sure it has its uses, but I also think that the fact that MS office automation seems to be designed such that it works best with some language specific features is poor design. What kind of real programmer uses 18 function parameters? Sounds like poor design skills to me…

    As for scripting, well I find javascript far more useable.

    With the supposedly "cryptic" syntax of C#/C/C++/Java I believe the code is more compact, and just as, if not more, readable than other syntax styles. If someone can’t take the minor intellectual knock of the at first obscure syntax then maybe that person should look at another profession?

    Reply
  39. Pingback: Anonymous

Leave a Reply