Posted by: Peter Donker
11/5/2010 

The origins of .net and DNN

Back in the day … Well, back when .net was conceived, Microsoft had a very forward thinking strategy regarding development languages on Windows. They owned Visual Basic (last version was 6), VBA (i.e. what was embedded in Excel for instance) and VBScript (also used in classic ASP). These dialects of BASIC were targeted at a non-professional audience. I know some of you may raise an eyebrow here, but the fact of the matter is that BASIC is for many the entry point to programming (I was one of those people that came to programming using BASIC on the Commodore PET in the early 80’s) and does not force you to code in a very advanced way. MS also owned Visual C++ etc and other tools of which I knew a lot less at the time. In any case the idea was to create a unified layer underneath any number of programming languages and compile to a so-called intermediate language. And to unify the VB and C strands of languages into a single funnel for coding. So C# was created and VB became VB.NET.

To illustrate the point Microsoft released an ASP.NET project called IBuySpy portal in both C# and VB.NET. So both versions did the same but were written in different languages to prove you could do the same with both. As most of you know the VB version of IBuySpy is the root of DotNetNuke. Shaun (Walker) harvested patches to this rudimentary web portal system and began releasing that as a single product. The fact that it was in VB.NET meant that he tapped into the many semi-professional programmers out there. By and large these are people that (used to) work on their own trying to create a little business for themselves. I am convinced that this is one of the reasons Snowcovered became an overnight success. To this day I view C# as “corporate” and VB as “SME” (yes, I know, there are many C# programmers in SME as well). This is also visible in the VBA domain. The VBA pros that I knew, worked as independent consultants.

To this day DNN has been an outstanding project demonstrating how VB.NET can be used to build complex things. But as those who know the forums here know: one of the FAQs is “why isn’t there a C# version of DotNetNuke?”. The question irritated as keeping 2 code-bases under development would mean pouring resources into something that catered to those who wanted to use other compilers or to read the source code and were not able to read VB.NET. And for the seasoned VB.NET programmer the latter is hard to understand (I’m convinced even my cat can read vb). So until now the official line was “we’re not devoting resources to that”. But then someone in China began to maintain a C# translation of DNN. And a good one at that. DNN rewarded this by bringing this forward into the public view. Inadvertently this again raised the issue: should we maybe move to C#? After all: if this guy went to all those lengths to maintain a C# version there must be a real demand for it.

VB vs C# … sigh

I guess anything that I’ll say about the differences is (1) biased by my VB.NET background and (2) likely to stir up an unproductive debate. But within the context of this post it is impossible to avoid. There are so many resources on the web comparing the two so I’m resisting the temptation of doing my own top 10 reasons why VB.NET is better. It has to be said that in early iterations of .NET there was a larger gap between what you could do with VB and what you could do with C# (with the latter coming out on top). This leads me to believe that MS was driving .NET from the C# front and the VB team was invited to follow. But as those familiar with VB know, this language has been fast catching up (to the point of having anonymous lambda functions in 2010). So in terms of expressive power I’ve not heard a convincing argument to put one over the other. Technically they’re equal but syntactically very different. Which brings me to the other axis on which to compare: legibility. This is where I have a hard time understanding those that claim C# is more legible than VB.NET. I don’t think this post will lay that to rest but to make a long story short: I can get my wife/mother/etc to read my VB code and get a rough idea of what is happening, but not a C# equivalent. With constructs like “For Each node In ParentNode.ChildNodes” or “If ThisNode IsNot Nothing Then” it is hard to see why someone would object to its verbosity. What most irritates me in the debate, though, is a snobbishness on the part of those C# coders that lay into VB as somehow inferior syntactically. It’s like a debate over who was the greatest singer of the last decade. Utterly pointless and unconvincing. This is how to sum up that debate:

Personally I have a bond with DNN in VB.NET because I learned most of the tricks from reading the core code. I’m curious by nature and whenever I didn’t understand something in the code I’d drill down until I understood what was happening. For example: I’d never have known about the “provider pattern” had DNN not implemented this. I think for many of my fellow DNNers it is a similar story. You learn by analogy. If I need to solve a particular coding puzzle I’ll delve into the DNN code to see how they did it. I’ve always felt strongly about the importance of DNN to not only provide a solution but keep the code legible and demonstrate the latest coding standards (refactor, refactor and refactor).

Practical Impact

I don’t know how you code but I never load the full source of DNN into my own projects. Instead the DotNetNuke.dll is in the references and that is enough. I know it well enough to leverage it in my projects. So on a day-to-day basis I don’t actually see DNN’s source code. Just the exposed methods etc. The only time I’d examine the code would be for learning (as described above) or for debugging (in case the core reacts differently to what I expected). So these are the areas where this decision will impact my life as VB.NET  programmer. Reading C# code is just slower for me. But as time goes on this will undoubtedly speed up.

Conclusions

Honestly I’d hate to be in Shaun’s shoes on this one. It’s his call to make and it is one of those decisions where you just know there’s going to be a backlash regardless of what you do. I’ve decided to abstain from a vote in the Twitpoll as the impact on my daily life is minimal and I will respect what DNN Corp thinks is best for the project. I’d be less inclined to debug code as reading C# still takes more time for me. The trade-off is more in the audience we hope to attract to the project. My gut feeling is that the benefit will outweigh the damage. The damage is mitigated in part due to the fact that programmers that came from old VB but have worked in VB.NET for as long as DNN has been around (and have learned to code “neatly”) by now will probably already be familiar with C# and understand it. This is the case with all fellow programmers in the DNN eco-system that I know.

So my instinct tells me the days of DNN in VB.NET are numbered. I’ll stand by with hankies to wave this ship goodbye but I won’t have too much time to reflect on it as there’s too much work to do … mostly in VB.NET.

References

Why do C# developers look down on VB.NET? by Justin James

VB.NET vs C#: The Great .NET Language Debate by Darrell Norton

Choosing between C# and VB.NET by Huw Collingbourne

Trackback Print

Tags:

Categories: Development

Location: Blogs Peter Donker