Starting from the Beginning

I have been a Visual Basic developer for over ten years now. It was not my first language that got me excited about programming. No, that would have been Clipper. I accidentally fell into Clipper much the same way that Visual Basic started as an experiment for me.

It was sometime around 1987 or 1988 when I was working as the accountant and network administrator for my family’s car dealership. I was running into limitations in the current accounting software we were using and I knew that a change would be needed. However, I had great difficulty in finding software that had the functionality and flexibility that was required. I started looking into some source code solutions and found one that was originally written in dBase III and was Clipper ready. This was my start to serious programming as this source code did not work and it took me two months to work through the code learning to work with Clipper as I went along.

Clipper 4 worked well for me, which was a very process level language. There were no surprises. The user could only process data in the exact steps designed in the software. When Clipper 5 was released I upgraded, which exposed me to some new and unfamiliar aspects of programming. Clipper introduced three “built in objects” and soon several “third party vendors” started coming out with add-ons for Clipper that allowed the creation of your own objects and classes. You should realize that by this time I was becoming quite the Clipper programmer. I was designing new features to our accounting software and building complementary add-ons. I was experimenting with Windows but was never able to implement it into the dealership until Windows 3.1 was released. However, we were running our Accounting software in a DOS box through Windows. Nothing special here, but it worked. Nantucket, the company that owned Clipper, made a lot of promises that there would be a Windows version of Clipper coming out soon.

In the mean time, I read an article by a fellow Clipper guru that suggested looking into Visual Basic to get a better handle on working with objects. So I got a copy of Visual Basic 1.0 for exactly that purpose; to get a better understanding about how objects worked and be able to actually write a Window application. I was still thinking that Clipper was going to be my main programming language with Visual Basic as a tool to learn about objects. This was similar to the original purpose of Pascal, which was to learn structured programming. Anyway, I was having a great time with Visual Basic, reading a book or two on it and building some really simple programs.

On a flight to Comdex one year, I was sitting next to two guys from Sequiter Software. They noticed that I was reading one of my Visual Basic books and asked me how I liked Visual Basic? I told them I was enjoying it very much but I was really a Clipper programmer and it would be great if Visual Basic could access a database. Well what followed was some very interesting information that they shared with me: Sequiter makes a product called CodeBase which is a very fast engine that reads and writes to dBase, Fox, and Clipper data. I could use it in Visual Basic by declaring the procedures to the API from within Visual Basic. Well that was it: from then on Visual Basic became a very important tool in what would later become my programming career. Remember I was an accountant that couldn’t find good software that worked the way I needed it to work for me.

So I guess you could say that I have been building database applications in Visual Basic since version 1.0. Just so that you are clear on who I really am, I did not take any short cuts to change careers. I did take a number of correspondence courses where I studied Assembler, Basic, Pascal, C, and COBOL and then went to College where I graduated with distinction. I am constantly learning and doing the best I can to keep up on the latest technology and am always interested in creating better software products.

My Take on C#.net vs. VB.net

C# (sharp) is the language that was designed for dotNet and was used to build much of the Framework. It shares the same first name as its big brother C++, but it doesn’t really feel like any C++ that I have ever taken out for a spin. C# really is a cross between the best of Visual Basic, the best of C++, and some elements of Java which make it the perfect language for Dot Net.

Microsoft made an announcement that the new version of Visual Basic would finally be corrected to match the standards of other languages. There have always been inconsistencies between VB and other languages when it came to the number of elements that were created in an array and the value of true. Hey, somewhere along the way, this now very powerful language got itself all screwed up, but then VB.net is the first version where the forms are not being handled by the Ruby Engine. The operating system will actually be in charge of what we see on the screen. Anyway, at the time of this announcement I was all excited about the future of VB and what the heck was C# anyway, it did not even seem too important to me.

Then sometime in the early part of 2002, Microsoft made the announcement that I think surprised almost every serious VB programmer. They were going to re-tool Visual Basic.net to make it more compatible to Visual Basic 6. Well this was enough for me to consider looking into C# more seriously.

Before we go on I thought I would take a moment to talk about the bad rap that VB (as a language) has been given. VB has been attacked over the years by the programming community for not being a very serious language. The language started off as a very simple tool to build desktop applications for Windows. Over the years VB has become a very powerful programming language and probably its curse has been the ease in which you can build Windows applications. I say a curse, because anyone who has worked with this language has been able to build a working program quickly and easily. On the other hand you would not typically take a language like C++ straight out of the box and start writing a program without at least taking a number of courses and reading a few books on the subject. You might give up and leave that sort of programming to the professionals. But none of that is involved when programming in VB since it is such a forgiving language. However, even with VB’s simplicity there is a lot more to writing a good solid VB program then just a piece of code that works. There is choosing good programming practices and constantly refining your skill so that you write the most efficient and easily maintainable code that you can possibly write. The bad rap really belongs to the VB programmers that have picked up some very bad habits along the way and have failed to refine their skill to build elegant and well managed code. There are bad C++ programmers out there too just not as many.

I have spent a fair amount of time in a variety of C and C++ environments and have found that it was just too much work to build a Windows desktop application. Visual Basic makes a lot of sense since that was how it was designed. C on the other hand has it roots in building drivers and operating systems and I do not typically engage in those kinds of projects.

Making the Change

I am leaning towards programming in C# instead of VB but not just because I am upset with the decisions that were made on the future of VB: I need something much more powerful then that to justify my reasons.

One of the things I really like in C# is the new inline XML style comments. This is not available in VB.net. With this I am able to produce some very clear comments in my code, where they happen and with them produce a technical document. Many times in the past I have had to duplicate some of this effort, and then update my documents when the code went through some changes. Not anymore, it is all in one place and as I make changes my documents are also updated.

Secondly, Dot Net is built around this new concept of Namespaces, which is the way that Microsoft is getting around the DLL hell issues that have plagued us for years. I have some interesting stories to tell on that subject but will need to wait for another time. In C#, the Namespace is exposed right out there directly in your face. You can adjust the Namespace in VB.net but you need to do this through the IDE and is just not in your face. I have done some work with multiple projects that support other projects and I just think it is a lot cleaner when I have total control over the Namespace.

Thirdly, there is the learning curve. VB.net is not just an upgrade from Visual Basic. It is a new life style and you really need to get into that life style if you really want to take advantage of the Frame Work and go beyond what we have coded and designed in the past. This Frame Work is wonderful and I am almost tempted to say that the only limitation is lack of our imagination. Since I started getting into C#, I have had to take each step with a fresh new approach. When I was playing with the early beta’s I found that I was constantly doing a comparison with the previous version of VB. I think my return on investment with C# is a whole lot better then if I had gone the VB.net route. Something to keep in mind, Dot Net programming is for new programs, not to port over a working application. Microsoft has made sure that the Dot Net Framework supports our old code, so why touch something that works fine. Instead it is to create new applications and rebuilds of programs that lacked functionality that was difficult or impossible to implement in the past.

It is true that all languages compile to a common Immediate Language (IL) file that is used by the Common Language Runtime (CLR) but there are some advantages to using C# over VB.

Conclusions

In a survey of 633 development managers conducted by BZ Research during June of 2002 the results show that VB.net is being used in 21.8% of the current projects being developed while C#.net is being used in 18.8%. Over the next 12 months these same development managers are planning future development, where VB.net will be used in 43.4% of the projects and C#.net will rise to 36.7%. Pretty close.

These numbers would support what I have heard through the grape-vine that many of the VB shops are making plans to go the VB.net route: I think in part it is because of the upgrade path that has been followed in the past. They are not taking into consideration that VB.net is not the same VB that they have worked with over the past decade or so. I am sure that many of these shops will eventually start to move towards C#, since this is the language of the Framework and clearly the best way to start over. I think the training could be more cost effective and less expensive then attempts to retrain them with VB.net.

My prediction is that the growth of C#.net will be even greater then what is being portrayed in this survey which shows them pretty close to a draw. As for me and my house, we are going to skip dabbling in VB.net and go straight to the future of good programming, C#.