July 2004 Archives

Another update to SharpTerminal: this one fixes the large blank spaces on the bottom and right sides of the GUI, as well as a minor startup bug where if you hadn't saved any default settings, and hit Connect without going to the Config tab, you'd get an error. Going to the Config tab and back fixed the problem, but now it shouldn't appear at all.

The GUI bug was an interesting one for me. The computer I write SharpTerminal on had the DPI setting (Display Properties, Settings, Advanced) set to Large (90DPI). So the GUI looked fine on that computer, but it turns out that .Net is smart enough to perform Automatic Control Scaling according to the difference between the developer's settings and the runtime settings. This works great when the developer's settings are Normal and the runtime settings are whatever; Windows Forms scales the GUI appropriately. Things get a little weird when the developer's settings are Large (or possible any non-Normal setting)--as you can see in the screenshot below, on a system set to Normal, the scaling doesn't quite work:

The solution turns out to be fairly convoluted. First, set the developer's computer to use Normal DPI settings and restart the PC. Next, open the solution in VS.Net and go to the code for the form with the issue. Look for a line that says this.AutoScaleBaseSize = new System.Drawing.Size(6, 15); in the Windows Form Designer generated code region, and change the values to 5, 13 (the default values for a Normal system). Open the form in designer mode. Things will likely be very screwed up (controls will run off the bottom and right sides). Fix them. Note that some controls--for instance, the Microsoft ActiveX Web Browser Control--will probably have to be removed and readded in order to work properly. Recompile and the app should look right.

Of course, probably the best idea is for developers to not use strange DPI sizes to develop UIs in the first place. :-P

New version of SharpTerminal available. Here's the changelog:

• Fixed issues with COM ports not being consistently named between systems. Seems like the name of the COM port varies from system to system -> Mobo related?
• Added ability to disable local echoing.
• Added ability to automatically append a string (incl. hex chars) to every message.

So today Erik Porter linked to a very silly list of reasons to switch from VB.Net to C#. I say very silly because most--nearly all--of the "reasons" are either nonsense, irrelevant, or outright wrong. As someone who recently switched from working primarily in VB.Net to primarily in C# (not on my own initiative, and having no axe to grind), I feel I can shed a little light on this foolishness. In order, my comments in italics:

For the Developer:

1. Developers who program primarily in C# earn 26 percent more than those who develop primarily in Visual Basic .NET.
   This is about the only one I have no issue with, as long as the survey data is good. I'm not 100% sure I buy it, but at least it's not completely obviously off-base.
2. C# just looks more elegant because it was consistently designed. VB.Net was evolved over many years and has inconsistencies.
   You can write C# code that looks like a mishmash of styles (and even languages) because--surprise!--there's more than one way to write programs! Similarly, it is entirely possible to write a completely .Net, FxCop-compliant application in pure VB.Net.
3. C# is closer to Java which means it is easier for you to move to or from Java. This is good for your career.
   Poppycock. The real differences are not in the syntax--they're in the class library. Going from C# to Java will entail just as much of a learning curve as going from VB.Net to Java (since the BCL is identical for both VB and C#). Any developer worth the crud in their keyboard can learn a new syntax very easily; it's the BCLs that are difficult.
4. C# is perceived as a ?real? language where VB.Net is still perceived as a ?toy? language.
   Maybe. And I say maybe. But perceptions change.
5. Microsoft does all of its internal .Net development in C#. Even MS thinks C# is the better language.
   That's a lie. Microsoft internal teams do work in VB.Net. It's true that the majority of them work in C#, but they're coming from a C++ background--C# is more natural. VB.Net is in no way inferior to C# because of this.
6. C# has the following features which VB.Net doesn?t have:
   • Operator overloading
     Will be added to VB.Net in 2005--and I've never missed it, anyway. How much real development involves overloading the + operator?
   • XML code documentation
     Has been available via a free plugin forever, and will be in 2005. Yee-haw.
   • Ability to write ?unsafe? code for better interoperability.
     In the (extremely rare IME) situation where you need unsafe code, it's trivial to drop down into C# or even C++ for it.
7. Microsoft is actively adding new useful features to C# including generics, interators, anonymous methods, and partial types.
   Whereas VB.Net is stagnant? Hardly. Generics and partial types are coming to VB.Net at the same time, interators (sic) already exist, and some VB.Net features--Edit and Continue and the My classes, for instance--won't be in C# at all.

For the Manager:

1. Your code quality will improve because C# catches potential errors (example: variable use allowed before initialization and dead code) that are permitted in VB.Net.
   Am I the only one who's ever heard of Option Strict? As for dead code, yeah, it's nice that the C# compiler catches it, but I bet the VB.Net 2005 compiler will too.
2. Your developers will be more productive because they will work in a language that they like.
   I really need a "confused" emoticon here. I don't know anyone (at least anyone who's ever actually used it) that doesn't like VB.Net.
3. If your project is a mix of VB.Net and C# code, your developers will be more productive because they won?t have to switch between languages.
   That doesn't make any fucking sense at all. If the project is a mix, then choosing either language is about as effective.
4. C# is more portable than VB.Net. It is closer to Java which makes it easier to port code to Java later. It also can run on other operating systems (including Linux) by using the Mono and DotGNU open source projects.
   Again with the portable-to-Java canard. Say it with me: Base Class Library. And Mono should be adding support for VB.Net towards the end of this year.
5. C# has been submitted as a standard language (ECMA) which makes its syntax more stable. Microsoft could make drastic changes to VB.Net at any time.
   They could make drastic changes to the Office object model, too, but they're not retarded. If they were going to make drastic changes, they'd have done it between VB6 and VB.Net (*cough*AndAlso/OrElse*cough*), not between VB.Net 2003 and 2005.
6. Microsoft does all of its internal development in C#.
   Repeating it doesn't make it any less wrong.
7. C# is better because the following features make it easier to write better code faster.
   Yeah, see #6 on the Developer side. Repeating it doesn't make it any less wrong.

Don't get me wrong... I like C# a lot (some days better than VB.Net, some days not). But choosing between VB.Net and C# has nothing to do with the above list (excepting perhaps #1 on the developer side) and everything to do with your background and comfort level. If you know VB6, go with VB.Net. If you know C++ or Java, go with C#. If you know two or more, go hog wild. :)