For almost a decade I wrote applications using nothing but VB 3, 4, 5, and 6, or VBA (in Access), or VBScript (in old ASP), along with HTML a smattering of javascript, and quite a bit of SQL (T-SQL and Access SQL) for every application. But it was largely some form of VB, all day long, that I used to create my bread and butter apps. Before that was Paradox (PAL), Basic, and some macro languages for business apps. VB, though, became my career.
When .Net came out of beta in late 2001, I began a project writing a source code repository with content in both VB.Net and C#. I had to not only learn the .Net framework but also a fair bit that I was able to avoid in VB about object oriented design and programming (two different but very related things). For me, the new framework and OOD/P paradigm were the most effort, but learning two new languages thrown on top added to the effort.
Yes, two new languages. VB and VB.Net, while similar in syntax, are very different beasts.
So, as a long time VB/VBA/VBScript programmer learning both VB.NET and C#, it seems a no-brainer which one I took up and looked to as the better language...
It is C#. Why?
- It is more concise, I would even say more elegant than VB.Net. The verbosity of VB.Net becomes stressful. The scannability of well-contructed C# is very good in comparison. I can, in short, read well-done C# code much more easily than well-done VB.Net.
- The amount of crappy VB.Net code due to VB developers diving into .Net is astounding, and VB.Net unfortunately lets you get away with a lot of sloppiness. I may get to explaining that in another post, I have a lot to say about it...
- Developer tools tend to be done for C# more than VB.Net. In fact, many only support C#. Though that is changing, VB.Net support is often an afterthought.
- The background compiler in VB.Net can sometimes be nice when you're making quick changes, but it is more often intrusive and stressful while coding. For example, if I want move off an incomplete line to copy and paste something else, I don't need the squiggles or the closing parens added when VB.Net doesn't know what I mean; tools like CodeRush are interfered with by the background VB.Net compile thread, especially in Visual Studio 2003; moreover, try VB.Net on a large solution (I have) and you will run into serious frustration and the need to restart Visual Studio regularly during your day to clear the futzed state the IDE gets in.
- C# has always caught things like unused variables, unreachable code, and non-void methods that don't return a value as warnings or errors. VB.Net may have solved one or two of these in the 2005 release, though.
- Option Strict and Option Explicit. These legacy VB-isms should have been thrown out. Other than the need for this in some Office Automation code, I can't see why you would ever want to not have these both ON. And way too many classic VB developers who come to .Net don't turn them on at both the project and source file level.
- I hate the line continuation character, and you think I would have gotten used to it from VB, but I just never have liked it. Especially in .Net when you're working with attributes, the C# syntax is much less confusing, more writable and just easy to do.
- Array syntax in VB and VB.Net, they just should never have used parens instead of square brackets when VB.Net came along. The thing that ticks me off most is when I go back to a C# project after working on a VB.Net project and keep smacking myself when I use parens for an array and hit compile errors. I hate that.
- Sometimes I actually like the background compile! But not usually, and I wish it could be simply turned off.
- Delegates and using WithEvents to simplify event handling. In VB.Net, that is a real boon to developer efficiency.
A more important point is that if you work with .Net, you need to know BOTH of these languages, no excuses.
No comments:
Post a Comment