I'm not considering this - I'm comfortable with C# and VB, but an expert in neither. But, some on my team have expressed an intention to do this since we're moving toward C# as a standard.
views:
330answers:
12
+4
A:
I would get comfortable in C#, which shouldn't take too long. Writing in VB and then converting would just be a waste of time IMO.
Besides, what happens when they need to read some C# code if they're not comfortable in the language?
Corey
2009-01-26 18:09:03
+11
A:
Hell's no. Just an absolute waste of time.
I would use VB over C# (or C# over VB) only if the language enabled functionality that was not available in the other.
For example, making late bound calls to COM interop objects is much easier in VB than it is in C# (although that is going to change in C# 4.0).
That being said, I'd stick with the language that your team is using, or what you prefer (if that is an option).
casperOne
2009-01-26 18:11:40
+2
A:
It is easier to go from programmer's intent to source in either language than it is to go from one to the other.
You should use the language you intend to use.
David B
2009-01-26 18:11:45
+5
A:
Sounds like a recipe for disaster or at least countless WTF-moments with no actual gains.
.net Assemblies are compatible regardless of language (it's all IL at the end anyway), so there is no gain from that.
Michael Stum
2009-01-26 18:12:55
+1
A:
I would be opposed to that approach.
If the intent is to move to C# as a standard why wait to start using it? I also find it far too easy to imagine the conversion never happening. When it comes to crunch time and the choice is between converting and adding/fixing features then conversion is likely the first to go.
In the vein of it being a people problem. Why the move to C# in the first place? Are you sure everyone is on board with that being the standard?
Jeremy Wilde
2009-01-26 18:12:56
A:
If you need two different applications to talk to each other, I suggest using web-services or some open format (XML) for transporting data. That way you can keep both VB and C# apps.
Sheehan Alam
2009-01-26 18:28:16
You don't need any of that. VB and C# interoperate out of the box. Web services and high-level transport protocols are basically only necessary to bridge gaps between incompatible architectures (or physical/logical distances). This is not the case here.
Konrad Rudolph
2009-01-26 18:31:33
+1
A:
As a huge fan of VB I would say that this is essentially a very bad idea. If C# is being used, write in C#.
Actually, .NET makes it quite easy to mix multiple languages in one project as long as it is divided into multiple assemblies. A priori nothing speaks against this practice. However, as soon as one language is established as a standard in the project, all developers should stick to it.
Converting is a waste of time and money since there exist no automatic, error-free conversion tools (that I am aware of) so it would always involve some manual post-processing. This shouldn't be acceptable. Additionally, learning C# when you know VB is pretty straightforward and shouldn't create a barrier that offsets the cost of converting code.
Konrad Rudolph
2009-01-26 18:28:34
+2
A:
There are other considerations not mentioned. Notably, if you're converting your VB code to C# using automated software, you can count on there being numerous conversion issues. Do not let anyone lure you into a false sense of confidence regarding the amount of work that conversion entails: VB.NET and C# are further apart from each other than you may think. Converting from one language to the other will introduce a large amount of work into your schedule, and will possibly rewrite portions of your code in unexpected ways.
Take it from someone who's done it.
If you don't have a truly compelling reason to port your existing code to C#, it's likely far more cost effective to leave it in that language, and simply write newer code in C#. Also, if your developers aren't entirely comfortable with the change to the new language, you may have to deal with the discomfort that some of them may feel. Whether we agree with it or not, some employees may feel so strongly about it that they will leave, which will incur a signficiant cost when you have to replace them.
Just my two cents.
Mike Hofer
2009-01-26 18:31:51
A:
I prefer C# but if the majority of developers are VB.NET guys, why are you moving to C#? That will be a learning curve with no gain in productivity. Also I am assuming the majority are VB.NET people, if not well then you have a huge PR nightmare on your hands.
The approach we have is the VB.NET guys develop in VB.NET and the C# guys in C#, we are lucky enough to have well defined modules which can interact on the IL level without any issues.
A:
No. NO! Just... say... no.
My boss suggested that at one point because many of the engineers (note.. structural engineers, NOT programmers) knew VB6 and were comfortable with VB, but he wanted to use C# as a standard.
I immediately wanted to deck him to knock some sense into him, however I restrained myself and calmly discussed the options with him. I was finally able to convince him that -- while .NET is .NET -- VB.NET with slices of VB6 that the users are sure to squeeze in for "ease of coding" is NOT the same as C#.NET.
There are enough differences that -- at least for us -- the learning curve of C# was worth the time instead of the coding curve of converting from one .NET language to another.
Jerry
2009-01-26 19:19:01