Microsoft: make VB like C#

Posted Thu, Mar 19 2009 22:48 by bill

I was reading yet another VB versus C# rant: I don’t want to get sucked into wading into that, but I will say that anyone who thinks folks that use VB can’t use C# has really got things back the front.  Most people who use VB can read and write C# quite well; they choose VB knowing both.  Whereas so many C# developers I’ve met have absolutely no idea about VB or concepts such as declarative event handling etc, etc.  For them they don’t have the basis of choice. 

The reason VB folk have to read and write in C# is because a lot of SDK’s etc are all in C# originally.  Even things like the enterprise library provide source code only in C#; this even after Soma promised to do better in regard to that.  So for VB folks there is a real need to learn C#.

The big problem though is if you want to use C# source code in your VB project: you often have to re-write it or separate into different assemblies.  That’s not productive.  What I want is for VB to like C# and vice versa.  I don’t mean make them the same, I mean for them to like each other; to get along well inside the same project.  I’d like to be able to add a C# class to my VB project and happily compile it.  And I bet some C# folk would love to have some concurrent basic or XML literals in their C# projects without all the current barriers.

Maybe the talk of compilers as a service type thing will give us that true cross language project, where VB and C# like each other so much that they then are free to diverge again :)

Filed under: , , , ,

Comments

# re: Microsoft: make VB like C#

Thursday, March 19, 2009 10:46 PM by deostroll

For me its just the editor environment. I work with vs 2005. For a project which involved a lot of threading and event callbacks to the main thread I found using the c# editor was more productive. More specifically the editor supported auto-code generation for wiring events. When you try to register an event, it automatically creates the event sink function for you. If I had to use AddHandlers like in vb, I'd kill my self.

But it is not that I hate vb. I know when to use vb or c#.

# re: Microsoft: make VB like C#

Saturday, March 21, 2009 5:46 PM by Taiwo

Deostroll:

With your statement "If I had to use AddHandlers like in vb, I'd kill my self", you just made Bill's point.

Events are wired automatically for controls or class/module-level variables declared with WithEvents when you select the control/variable in the Class Name dropdown at the top of the code window and select the variable, and then select the event you need to sink in the Method Name dropdown. These autowired events use the "Handles" clause and, of course, you can also sink events yourself by using the Handles clause next to a method name as long as the delegate matches. This presents an alternative to AddHandler/RemoveHandler in VB.

Unfortunately, unlike in VB, when you delete an event method in C#, you have issues at compile-time because the C# event-wiring statements are not automatically deleted; you need to chase these down in C#. With VB, intellisense lets you know if the event method doesn't exist if you use AddHandler. If you use the Handles clause deleting the event method doesn't have any additional dependency on some statement in the InitializeComponent method.

- Taiwo

# re: Microsoft: make VB like C#

Saturday, March 21, 2009 9:05 PM by deostroll

@Taiwo:

"WithEvents" according to my understanding exposes an object's events in a class/module.

Approach 1 is you can write your own sub that handles the event with "Handles" clause. Whether you type it or use the vb code editor to do this is not my concern. Hence when you delete the sub entirely, it so happens that you delete the Handles clause with it. I agree its easier to de-link events this way.

Approach 2, which is more dynamic, is whats adopted in C#. This same thing materializes in vb via a concept of AddHandlers. Here you'd still face the problem you've mentioned above. Here is where I would have committed a metaphorical suicide if I had used add handlers :)

And again I repeat, this is nothing that the language has to offer. Its how intelligent your editor is...?

But now, that I wrote all this, I am curious about withevents: I wonder if there is a performance hit encountered whenever an object is created?

# re: Microsoft: make VB like C#

Sunday, March 22, 2009 10:26 AM by JaredPar

Have you seen Jomo Fisher's post about integrating ILMerge into the VS Build process?  This allows you to take multiple source projects and turn them into a single DLL

blogs.msdn.com/.../544144.aspx

It doesn't really provide a seem less multilanguage IDE experience but make multi-language solutions slightly easier to deal with.

# re: Microsoft: make VB like C#

Sunday, March 22, 2009 10:38 AM by FremyCompany

I don't think making C# and VB more similar would change the problem from all to all. It can help, sure, but it's not sufficient.

The biggest problem is that Visual Studio don't provide a compiler that can call a different compiler for each file. If it was possible to have a '%sdk%\multi-lang-compiler.exe xx.vb xx.cs ....', it will be good too.

# re: Microsoft: make VB like C#

Sunday, March 22, 2009 2:29 PM by Paul

Would this not simply make MS even more lazy (If that's possible) in providing VB examples and conversions.

# re: Microsoft: make VB like C#

Wednesday, March 25, 2009 11:36 AM by Charles Poston

Quite frankly I don't understand why Rexx didn't win.  Compared to Rexx VB has always sucked.  I think the sad truth for VB is that many of us only went to it because it was higher level that the C we were used to writing when Windows first appeared (and before.)  When an alternative appeared that was C-like the future was already foretold.  I'm not a big fan of what they are doing to C# these days (adding functional features) because I think they will just achieve an unwieldy bloated language that will have tons of code hanging off of it that will be incomprehensible.  I would rather see a truly functional language (F# maybe?) So I actually think VB programmers should be grateful to stay behind that curve.  In 6 years your VB skills will still be useful.