Recently Scott Belware was taken to task by Scott Greenberger about using the term "Visual Babytalk". This particular conversation has peaked my interest, since I'm a C# developer surrounded by VB developer's who don't understand why I use C#. Mr. Belware does this conversation more justice than I ever could. I've excerpted some juicy points here, starting with Mr. Belware's caveat (which I must echo as well).
So let me just be clear before I get all kinds of, "There are bad C# programmers, too" email, and "I have too read a patterns book" messages. I'm not talking about the segment of VB culture that lives in the far right hand side of the VB developer competency curve. I'm talking about the fat part of the bell curve, and areas leftward. I'm not speaking to authors, speakers, industry leaders, etc, who have an affinity to VB syntax yet still do extraordinary and inspiring work - people like Rocky Lhotka for instance (if I'm ever half the programmer he is, I'll have certainly far over-reached my expectations of professional development in this life). My comments go to what Microsoft refers to as the "Mort persona" for VB developer cultural generalizations.
And neither am I speaking of the best developer I know... who happens to be a VB developer. His name is Check. Yeah, you buddy.
The VB versus C# question isn't a question of language, it's a question of culture - it always has been. Anyone who approaches this question from a language syntax angle does a very important issue quite an extraordinary disservice. It's true, there's not a whole lot of difference between C# and VB when you look at the IL their respective compilers produce. If you really wanna see the difference between VB and C#, have a look at VB and C# programmers' bookshelves, or listen in on their conversations. Give a team of C# developers and a team of VB developers the same application to build, and the conversation about the solution will be likely be as different as the implementation approach.
When the VB6 community saw VB .NET, there was a lot of panic. .NET thinking wasn't a whole lot like VB thinking. That stands to reason - .NET is object-oriented and strongly-typed through and through. Object thinking is non-linear and prescriptive at its best. When the line was drawn in the sand between Visual Basic development and C and C++ development for line of business apps, the intension was to drive business app development out of the hands of the OO, strong-typed thinkers, and into the hands of folks with a more constrained skill set. At that time, all the great computing things that would ultimately form the foundation of .NET was seen as overkill for the kinds of apps that VB developers were geared for. And then complexity took another huge leap and the justification for VB6-oriented approaches began to loose its relevance.
I remember deciding on learning C# when I switched to .NET. I had heard that both languages were strongly typed, and I was ready to face OO head-on (even though VBScript supported OO - I had only recently discovered this - 9/11 in fact). But I had always wanted to become a "real" developer (ala C++), and had even flirted with switching to JavaScript as the language in ASP. I had tried to get VB jobs at local companies to begin my trek towards building cool software (in C++)... to no avail. Hence I was stuck with web-page development (and to some extent still am). So when C# became an option, I jumped on it. It was C++ for the web in my mind.
C# developers don’t frag VB culture because of "EndIf" and "EndCase", they do it because VB culture hasn't learned anything in over a decade about the responsible use of RAD. My personal disapproval for the state of VB culture is largely a defensive stance. I see a culture that is stagnating in a set of cultural values that have outlived their time.
Today's applications demand greater amenability to change which in turn drives layering, separation of concerns, and a few key structural and behavioral patterns, as well as testability. The push towards reuse through services is also driving the need for testability which in turn drives the need for factoring and component design. These are all things that RAD has absolutely nothing to say about. These are all issues of application design and code design. These are all issues that are much more simple to work with when they are approached from an ontological angle and served by objects rather than by RAD-oriented containers like the DataSet. Yet the VB culture seems simply unwilling to wean itself from its crack-like addiction to the DataSet, the inside-out disorganization of logic that its use leads to, and the morbid fascination with seeing how quickly a system can achieve entropy by completely ignoring the notion of "model".
I learned everything of significance I know about contemporary programming from hanging out with Java developers. I don't expect anything of VB culture that I didn’t expect of myself when I leaped from FoxPro to JBuilder. The view from mid-air is terrifying, but thrilling too (then again, I'm a hang glider pilot so my tolerance might be a little skewed).
Doh! I remember some long nights when I switched from writing ASP applications in VBScript to ASP.NET in C#.NET. Oh, you better believe the view from mid-air is more than a little terrifying.
Visual Basic developers and C# developers aren’t made of the same stuff. Am I saying that C# developers on average are better than VB developers on average? Yes, absolutely, without a doubt that's exactly what I'm saying - but only because the VB .NET bell curve is skewed by that massive cast of characters who are still doing VB6 on the runtime. I agree that in the .NET world that it's all about the runtime, and that whatever I can do in C# I can also do in VB .NET. But, I don’t believe for a minute that the average VB developer who lives by doing VB6 on the CLR can come close to doing what the average C# developer can do with test-driven development, refactoring, domain objects, patterns, and a an approach to data access that isn’t muddling about in a low-level API like ADO .NET.
I couldn't have said it better myself. I work with a developer, and though he can code in both C# and VB... his code has the distinct feel of VBScript. Everything is a string. Everything. I'm not kidding. Everything is a string... from beginning (form) to end (sql). It stunned me at first. I couldn't believe that his code was so weakly-typed. But he said to me repeatedly - "It works." I have to admit, it did. But why would you do that? That's a culture I have difficulty wrapping my head around.
Where is the love you ask? It's right here stamping out this blog entry today rather than doing for-fee project work. It's right here telling you straight up and clear what insiders are willing to talk about off the record but not in public within earshot of the Babytalkers. It's beating in my heart when I spend my free time tutoring Microsoft developers who are interested in leaving their crutches behind and reinforcing their relevance as time and complexity march on.
I'll tell you where the love is not… It's not coming from certain fearful cadres within Microsoft that believe that VB developers can't hack it, who handle VB developers with kid gloves, tell them what they want to hear, and feed them soothing RAD baby food rather than suggest that maybe it's time they did some of the reading and experimenting that wasn't required of them when VB6 approaches were relevant.
Love is C#... and it beats in my chest everyday, even when the IDE crashes, or Intellisense curiously dies for me - but not my VB counterparts... I code in C#, because I love technology. If I coded in VB - it would be just for the paycheck (and I would feel like I had stepped back in time).
posted @ Thursday, February 10, 2005 6:23 PM