I've been doing some thinking, and one question that has been nagging at me is whether or not the world really need another blog that harps about the importance of understanding how to implement generics in .NET? I'm not so sure it does. Fortunately, there is an abundance of information available in very intricate detail for the programmers out there who are grappling with such things.
So then, if I acknowledge that there is plenty of technical information about the nitty-gritty of programming, the question then becomes one of how I might be able to add value to the community with this blog? I think the answer is simple.
A few months ago, I accepted a position as the Director of Software Development for a company that is a rising star providing sorely-needed technology to the legal industry. This places me in the unique position of being able to provide valuable insight into the trials and tribulations of successful software development -- not only for the techies out there, but also for the "business folks". It is with that in mind, that I proceed on a slightly altered course for this blog.
Sunday, June 25, 2006
Saturday, March 04, 2006
Microsoft Confirms My VB Assertions
Tom Archer, the MSDN Program Manager and Content Strategist for Windows Vista, the Windows SDK and Visual C++, seems to have confirmed my thoughts about VB programmers in a recent blog post in which he explains why so much of the example .NET code is written in VB. He first notes that there are many more VB programmers than C# or C++, but then goes into a more dubiuos explaination:
Translation: The C#/C++ programmers have no trouble with VB, but the VB programmers can't hack the C#/C++ examples.
"These statistics show that the majority of C++ and C# developers are more
apt to read an article that contains Visual Basic.NET material than the reverse.
In other words, a very high percentage of Visual Basic developers will not read
an article if it contains C++ or C#. "
Translation: The C#/C++ programmers have no trouble with VB, but the VB programmers can't hack the C#/C++ examples.
Tuesday, January 31, 2006
The Great Debate
The Visual Basic versus C# debate has raged since Microsoft released the very first version of .NET. Is one language better than the other? Does one offer superior processing performance? What about development time?
The short answer (and the answer Microsoft is carefully conveying) is that the languages are functionally equivalent. So what does that mean? Basically, you can do the same things in each language with relatively the same performance.
I read an interesting article a while back that pointed out something beyond the functional nuts-and-bolts of the languages; namely, the type of developer each language attracts. In this case, I tend to agree that there is a difference.
Speaking as someone who came up through the Visual Basic ranks, I can now say that I have a bit of a bad taste in my mouth for VB. I think it encourages sloppy programming practices, bad habits, and poor coding in general. Sadly, for these very reasons, VB tends to be a magnet for sub-par programmers.
By contrast, C# is a more elegant language, and in many cases, forces the developer to take an object-oriented approach. Since both languages are billeted as "Object Oriented", I see this as a plus. On the whole, I find that most C# code is less bloated and more streamlined than most of the VB code I come across.
It's been said that 80% of C# programmers are good, whereas 80% of VB programmers are bad, but because there are so many VB programmers, there are roughly the same number of good VB developers as good C# developers. Of course, that's not to say that all VB programmers are bad. Quiet the contrary, I've met several amazing developers who sling VB code.
I was extremely disappointed to find out that Microsoft has further soiled the .NET implementation of VB by, among other things, taking a step backward and allowing form references without instantiation. For example, assuming you have a form named "Form1". In VB 8 (Visual Studio 2005) you no longer have to create an instance of that form in order to interact with it. All forms are effectively static (or in VB terms, Shared).
Furthermore, some of the language enhancements in VB 8 are just plain silly. For example, Microsoft introduced the IsNot operator. The reasoning is to improve the readability. For example, the old way of testing the value of an object looked something like this:
The list goes on and on, but at the end of the day, I'm afraid I have to cast my vote in favor of C#.
The short answer (and the answer Microsoft is carefully conveying) is that the languages are functionally equivalent. So what does that mean? Basically, you can do the same things in each language with relatively the same performance.
I read an interesting article a while back that pointed out something beyond the functional nuts-and-bolts of the languages; namely, the type of developer each language attracts. In this case, I tend to agree that there is a difference.
Speaking as someone who came up through the Visual Basic ranks, I can now say that I have a bit of a bad taste in my mouth for VB. I think it encourages sloppy programming practices, bad habits, and poor coding in general. Sadly, for these very reasons, VB tends to be a magnet for sub-par programmers.
By contrast, C# is a more elegant language, and in many cases, forces the developer to take an object-oriented approach. Since both languages are billeted as "Object Oriented", I see this as a plus. On the whole, I find that most C# code is less bloated and more streamlined than most of the VB code I come across.
It's been said that 80% of C# programmers are good, whereas 80% of VB programmers are bad, but because there are so many VB programmers, there are roughly the same number of good VB developers as good C# developers. Of course, that's not to say that all VB programmers are bad. Quiet the contrary, I've met several amazing developers who sling VB code.
I was extremely disappointed to find out that Microsoft has further soiled the .NET implementation of VB by, among other things, taking a step backward and allowing form references without instantiation. For example, assuming you have a form named "Form1". In VB 8 (Visual Studio 2005) you no longer have to create an instance of that form in order to interact with it. All forms are effectively static (or in VB terms, Shared).
Furthermore, some of the language enhancements in VB 8 are just plain silly. For example, Microsoft introduced the IsNot operator. The reasoning is to improve the readability. For example, the old way of testing the value of an object looked something like this:
If Not someObject Is Nothing Then ....With the IsNot operator, that same line of code would look like this:
If someObject IsNot Nothing Then ...If you ask me, neither approach is as elegant or intuitive as the C# equivalent:
if (someObject != null) ...
The list goes on and on, but at the end of the day, I'm afraid I have to cast my vote in favor of C#.
Subscribe to:
Posts (Atom)
