Aug
15
Posted on 15-08-2006
Filed Under (C# , Rants ) by jay

Most articles and posts about the "C# vs VB.NET" argument conclude that the two languages are equal and only differ slightly. Although I agree with this I think the real difference is not the syntax of these languages but the way they are implemented. After 9 months of using VB.NET (on someone eles's app) I have found that old school VB developers cannot let go of classic VB and have not embraced the power of .NET.

I have been using C# since the .NET Beta 1 but I needed a job so I took a VB.NET position. So far I am doing fine with VB.NET, I have been using it for 9 months and I have to agree that there's not very much difference between VB.NET and C#. They share the same Namespace, they are both Object Oriented languages and any thing you can build in C# you can build in VB.NET.

So far I have only 2 problems with VB.NET, one is the inability to use nDoc to generate documentation from XML Comments and the other is that VB.NET is not type-safe. In my current job I came on at ver 2.x of the product. It's stable and people are paying for it so there are no plans to change anything. But the system is huge, it's very difficult to navigate and lacks documentation. My first personal task was going to be adding nDoc to the code as I was learning my way around. Well that little dream was dashed to bits when I found out that VB.NET does not support XMl Comments.
Oh well, I'm a smart guy and I'll figure it out.

Secondly the lack of type-saftey code is a pain in ... if you come from a type-safe language like C# you'll know exactly what I mean.

After a few months of working on the system an old theroy I had abuot VB developers is coming true and that is they can't let go of old ways of writing code.

The product I am working on was developed by VB6 developers who ported the app from VBScript (3 years ago) and they stuck to what they knew. For instance there is a time-span search thet kept grabbing the time-span + 1 extra day and I was asked to fix it. Once I found the line of code I wasn't suprised to see this:

CODE:
  1. DateAdd(DateInterval.Day, 1, Request.Form("EndDate"))

The DateAdd method is from the Microsoft.VisualBasic.DateAndTime Namespace which was Microsofts' way of helping port VB6 apps to .NET. Which is fine because if they didn't provide a way of porting old VB6 code they would have been accused of being a monoply or someting. Anyway a better approach would be to use the .NET System.Date Namespace like this:

CODE:
  1. Dim xdate As Date = Request.Form("Date")
  2.   xdate.Add(New TimeSpan(1))

*note: this is not the code fix it's just an example*

Utilizing the System.Date Namespace can save processing power by not having to load the Microsoft.VisualBasic Namespace and the code will no longer rely on a legacy DLL.

The second thing I need to point out is the use of Request.Form("Date"). This again is an old way of grabbing form variables that is used in VBScript/ClassicASP. To make matters more complated on this they are dynamiclly adding all of the controls to each page. There is nothing wrong with dynamiclly adding controls but instead of using controls from the System.Web.UI.WebControls Namespace they are using the System.Web.UI.HtmlControls Namespace; aka classic HTML controls, with out the Runat parameter. Thus resulting in the required use of Request.Form("Date") to get a value from a form control. Again .NET is not being utilized to it's full potential.
Although you can use the Request.Form to grab values from .NET Form controls I would only recomend doing so as a last resort hack.

The above items are just 2 examples from one company but the point is that the developers have a VB6 background and fail to see problem with using the VB6 methods in a VB.NET app.

Now I'll go back to that theroy I mentioned before about VB developers not being able to let go.
Back when .NET came out I worked for a company that wanted to start using .NET as the primary development platform. At the time there were 4 developers, 2 Web Scripting types (ASP/PHP/ColdFusion) and 2 VB6 developers. When it was decided that we would start moving to .NET the knee-jerk reaction from the VB guys was resistance but on the other hand the scripting guys were all for .NET. It was also decided that to make it an even playing field that we would use C# as the development language which really ticked off the VB guys. With the open resistance to .NET, we knew that the VB guys would try sticking to the old VB6 ways and not truly embrace .NET, which is that's exaclty what they did. Saddly the VB guys quit siting that C# was too difficult to learn and that code-behind, type-safte and the lack of debug-in-place made .NET too difficult use.

Although this is an extreme case the VB guys feared change from what they knew and wanted to stick with the old way do developing.

These are two isolated cases that I have witnessed in the past 6 years. They are not how all VB developers are and are my personal experiences.

What I am interested in learning is if other people have witnessed this type of behaviour both postitve and negative.

    Read More   

Comments

Jonathan Allen on 15 August, 2006 at 9:16 pm #

So far I have only 2 problems with VB.NET, one is the inability to use nDoc to generate documentation from XML Comments and the other is that VB.NET is not type-safe.

Yea, that sucks.

Good news, VB 2005 does have xml comments. Bad news, nDoc is basically dead. Somewhat good news, MS is releasing a tool that replaces nDoc.

Secondly the lack of type-saftey code is a pain in ... if you come from a type-safe language like C# you'll know exactly what I mean.

VB can be every bit as type safe as C#.

Turn on Option Strict for the project. Or if that is too painful, add Option Strict On at the top of each file as you fix the type safty issues.

This reminds me of one of my biggest complaints about C# projects. By default it doesn't check for integer overflows, allowing for subtle bugs.

Utilizing the System.Date Namespace can save processing power by not having to load the Microsoft.VisualBasic Namespace and the code will no longer rely on a legacy DLL.

Not true, all VB code needs the VB runtime DLL. Besides the legacy code, it has a lot of functions essential for the language.

Some VB specific functions are actually better than the BCL version. Others are there just for backwards compatability. Knowing which are which really helps, but I don't have a good list to offer.


Jonathan Allen on 15 August, 2006 at 9:24 pm #

P.S. Do me a favor and slap the any "professional" VB programmers you encounter that are not using option strict. Like not using Option Explicit in old VB, it leads to sloppy code and just makes us look bad.


admin on 15 August, 2006 at 9:48 pm #

Thanks for the tip on Option Strict I'll give it a shot.

As for moving to VB 2005 there are no plans ever. In it's current state it would require a major re-write.


dennis on 16 August, 2006 at 10:12 am #

Why is VB without Option Strict so much worse than, say, using Python?


Post a Comment
Name:
Email:
Website:
Comments: