VB and C#: Some perspective

I just got done writing the editor's note for VSLive! Orlando (I'm the conference chair for VBITS and VSLive!), which helped clarify in my own mind something that I observed last week while doing a couple of INETA user group presentations.

First, for Julia's group in Burlington Vermont where I did a presentation on "Architecture and Design for .NET", I was struck by the modest scale of the applications being built there. No 100-person IT departments: In fact, it seemed that many of the members were the entire IT department in their organization! And these weren't just mom & pop operations, but real industrial / distribution / retailing businesses. Mixed in with were a few CS types, including at least one university CS professor, but the feeling I came away with was of people who needed to get a lot done with very little in the way of resources. They were as excited about SharePoint as they were about VS.NET because it was that much more functionality they could leverage.

And in Boston, where Chris Pels allowed me to present on "Resources and Globalization for .NET", the clear majority of the members - at least at that particular meeting - were working on rich / smart / Windows client development, mostly using VB. Lots of larger enterprises represented in industries like finance and insurance. So, while these guys have a bit more to work with in terms of resources, they too were mostly interested in getting their jobs done. Coming after my talk, Jeff Richter - an acknowledged wizard of .NET's internal workings - reprised a talk he did at TechEd that highlighted a few of his favorite technical topics including code obfuscation, native image generation, and theoretical performance improvements of managed code.Talking to the members afterwards, all I heard was "yeah, that stuff was interesting but it's not anything I can use like your system for automating resource builds". Of course, that's what you expect people to say (you never hear directly that your talk wasn't anything but great) but the point that it illustrated for me is that there are people who like technical stuff for its own sake, and those who are mostly interested in applying the technology to build a solution.

In the past, this was a much clearer distinction. C and C++ developers built the Windows platform and libraries of reusable components, but it wasn't until the VB developer - drawn in many cases from the end-user ranks - built solutions that the Windows platform really took off. These two types of developers were at different ends of a spectrum anchored by the business process on one end, and something close to computer science on the other end.

With .NET, the picture has been substantially clouded. Developers are told to pick whichever language they feel more comfortable with, but then all sorts of caveats - some real, some imagined - pop up. And are debated endlessly. With the launching of .NET, the obvious focus has been on the lower-level platform functionality. And so the developers at the business end of the spectrum - who have seen a substantial shrinking of their world - have geared up to move further down the chain towards the platform developer. It isn't so much the language, but rather what they _do_ with the language that distinguishes platform developers. They would rather write an elegant, reusable class library than do almost anything else, particularly interact with users. But people used to building solutions are perceiving that the only way they'll be able to stay competitive in the IT industry is by becoming more technical. In effect, we are marginalizing out those who would rather talk to users in favor of those who would rather talk to the platform.

What seems clear to me, though, is that any particular developer can't optimize for both ends of the spectrum at the same time. What's has been sacrificed so far is the focus on the end-user's needs. Microsoft has talked about re-enabling RAD - and has indicated that the emphasis will be on VB - yet C# developers seem to believe that they'll get all the RAD stuff as well. Can that really be true? Can Microsoft really optimize a programming language & toolset for both solutions builders and platform builders? In my opinion, VB developers transitioning to C# are betting the answer to that question is "yes". And I don't think that - in the long run - that is going to be a good bet to make, particularly if your strength lies in building end-user solutions.

8 Comments

  • Man, Keith. It's exactly how I feel. You have really hit the nail on the head at least from the VB developer side. I had an interesting discussion with Ted Neward in Montreal saying that I felt that the bar had really been raised with .NET and he insisted that it was just my heightened expectations of myself. Well, kind of ...yeah. I see all this low level stuff there that I don't understand and feel I have to because it's just not satisfying otherwise - and all of these other developers I am meeting now have so little respect for what I do otherwise. Anyway - a great read!

  • While we are speculating...





    I wonder if those VB developers who choose not to make the C# jump, assuming that MS will continue to give them all the elegant features that .NET and the CLI offer, are making a particularly good bet :-). Already, VB does miss a few features that are very important for certain types of projects.

  • My guess has always been that, contrary perhaps to intuition, small MIS departments are among the first to pick up changes to development tools. IMO they have smaller applications with shorter application life cycles. Big corporate IT has a lot invested in the existing platform , so is slow to react to changes, particularly at a time when IT budgets for new systems are so poor. Think turning around small boats vs supertankers.

  • Great comments, great read. Thanks.

  • (Mortamer) "Already, VB does miss a few features that are very important for certain types of projects"





    OK, I'll bite, what features are you referring to? XML comments? <>

  • (Adam Hill) "I hope MS doesn't start differentiating languages based on some arbitrary criteria."





    Really? What would you consider to be NON-arbitrary criteria? Or are you saying they should they not differentiate at all?

  • Try unsafe code and pointers.

  • Because all the languages targeting the .NET Framework have been modified from their non-.NET namesakes, at the moment they do all feel similar, with just a bit of syntactic sugar variations. And while they all attempt to keep offreing all the features of the .NET Framework, this will continue.





    However, look at the VB.NET Option Strict Off mode: assuming you have a need for late bound code (which is, of course, a 'bad' assumption), notice how much more elegant the code is compared to explicitly using reflection and DirectCast...





    This is the sort of distinguishing feature that will appear in individual .NET languages. If it is an important feature, like the many RAD features of VB6, all .NET languages will consider implementing it in future versions. Otherwise it will become a reason to choose a particular language.





    Of course, in 5-10 years, someone may call it baggage and call for it to be dropped from the language...

Comments have been disabled for this content.