Sunday, December 15, 2013

VB.NET in a Year

I've been working with VB.NET for a little over a year now. When I first started my job, I didn't know or care what language they used. I was quite surprised to see a software shop use VB. I thought that stuff had died a long time ago. Well, after a year, I think I've learned most of the language itself. There's still much to learn about the surrounding systems, but I'm pretty comfortable with the core of the language.

What have I learned about VB.NET? It's not really that bad. Let me go over a few pain points and then explain what I like about it.

Pain #1: No extension methods on objects of type Object. This is very annoying. We use ADO.NET extensively, and those things are not typed. If I request an INT NULL from the database, I want it back as a Nullable(Of Integer). However, it comes back as an Object which might be DBNull.

That's not a major problem. I can write an extension method that will do the conversion for me. Well, it turns out I can't. VB.NET just won't apply extension methods to Object. C# will do it just fine, but VB.NET won't. As a result, I can't use an extension method. I have to call the function on this thing instead of treating it as a function of object.

Pain #2: Really long closure syntax. I use the method form of LINQ extensively, so it's really annoying when 1/10 of my code is "Function (...)". C# makes it nice and easy. Who decided that VB.NET has to be wordy?

Pain #3: Tuple support. One of my favorite languages is Python. If I want to pass back two objects, I can pass it back as a tuple and assign it to a tuple. In VB.NET, I need to create a class or modify my parameters. I really don't like modifying parameters, and I am too lazy to create types for everything.

Anonymous types work pretty well for closures, but they don't work across function boundaries. If I return it, it becomes an Object in the caller. What happened? The compiler knew it had two fields before, how come it forgot it?

Say I do manage to get it back. How do I assign the fields to my local variables? I miss "(a, b) = (b, a)".

Pain #4: Generic Constructors. Say I have a generic class where the type is determined by the value passed into the constructor. In the new statement, I have to specify the type of the class even though the compiler can infer it from my argument. This is all good until I have to pass in an IDictionary(Of String, IDictionary(Of Integer, Integer)). That's way too much typing for something the compiler should do for me.

Pain #5: No dedicated dictionary syntax. I really want x = {a: 3, b: 4}.

Pain #6: (New Foo).Bar doesn't work. The compiler forces me to assign New Foo to a variable before I can call Bar on it. very annoying. I don't need to keep it. I don't want to assign it to a variable.

Pain #7: No macros. I want at least C style macros if I can't have Lisp style macros. I get neither. Awesome.

After a year, certainly there are things I like about VB.NET. What do I like about VB.NET?

Plus #1: IntelliSense. This is more about Visual Studio than VB.NET, but Visual Studio is one of the best parts about VB.NET. Not having to remember property/method names is awesome. Not having to remember the methods of types is also amazing. What can I do with this thing? Type '.' and IntelliSense will tell you right there. And it's always right. It never gives extra suggestions nor misses anything you haven't used before.

Plus #2: Edit and Continue. Even though I can't edit and continue anonymous methods, it's still magic.

Plus #3: Optional parentheses. I used to think this was really weird, but now I like it. This makes me type AddressOf often, but I think the parentheses I've saved makes up for the AddressOf that I have to type once in a long while.

Plus #4: CLR library. There's a lot of good stuff built in already. No need to reinvent the wheel.

That's about it. In conclusion, the only thing that VB.NET has over C# is Plus #3. But as I look back over this list, most of the stuff I don't like only cost me a few seconds more of typing. Seeing as how I don't spend that much time coding anyway, it's actually not that bad. If I had a choice, would I choose to use VB.NET? Probably not, but it's not as bad as I had first thought.

No comments:

Post a Comment