Send mail to the author(s)

November 15, 2004

RANT: People who translate code unnecessarily

Like Daniel, I'm advocate of developers being conversant in both VB.NET and C#. But what I am not an advocate of is people who feel the necessity to translate code between the two languages just because some class they found is not in their preferred language. I get a lot of emails about the camera API proof-of-concept I posted a while back, and most of them are from VBers who have written the same code but in VB.NET.

WHY DO YOU DO FEEL THE NEED TO DO THIS?!??!

Don't you know that you can have both C# and VB.NET projects in the same solution? Are Microsoft doing a bad job at educating users or do you just not know how to use your development environment properly? Don't you understand that whether the ASCII characters you see strung together before you form a C# snippet or VB.NET, it does not matter when you compile the application?

If you follow the advice of Daniel and myself, then you will have no problems with having mixed language projects in your solution. In fact, I'd say that that is the preferred method of making the most of a useful class! Don't waste project budget by needlessly rewriting code just because (a) you can and/or (b) prefer a particular language. You ain't going to gain anything by translating code

I'm fine with people translating snippets, like Daniel does. Heck, I even post some snippets purely in VB. Just don't waste time translating entire class libraries. There's more important things you can be doing with your time.

Monday, November 15, 2004 10:04:22 PM (GMT Standard Time, UTC+00:00)
Nice rant :-) I wish I was optimistic about the multi-language vision. Looking at the support questions I get and the general atmosphere at the newsgroups, we have two camps to blame. One is the C# elitists who still look down on VB, ignoring the progress it has made since the dark ages of VB6 (although with the decisions the VB team is making lately, that group can only increase in numbers). The other is some stubborn VB devs that insist on not even trying to understand any language that uses semicolons (and again the VB team is not helping in that respect by trying to accommodate - if not promote - old bad habits). So, whether we like it or not, for devs supporting the .NET community life is full of translations from VB to C# and vice versa. Unfortunately, this is the reality and we can not ignore it.

>> “I'm fine with people translating snippets, like Daniel does.”
I would actually take issue with someone translating my code for the sake of it. However, you realize that this is not the case. I like to believe my blog entry adds value: besides clarifying that the FileVersion defaults to the assembly version, it also gives a heads up to the InformationalVersion. Furthermore, a straight translation of the C# code to VB (and we both know people would attempt it) does not just work; the VB root namespace does indeed catch out many people.

Now let us ponder on how much the CF newsgroup traffic would be decreased if the openetcf source was also available in VB... Hmm... That is a project against our philosophy, but realistically valuable...
Monday, November 15, 2004 11:57:17 PM (GMT Standard Time, UTC+00:00)
Believe me, we are working hard to accomodate VB devs through the Smart Device Framework. It's just not an easy task when:

(a) we all (dare I say it) prefer C# over VB. For me, I just prefer the format of the code -- I find it a lot easier and quicker to read than VB, mainly because the scoping is easier on the eye -- and I like the case sensitive. It requires a dev to have a certain amount of concentration on the task at hand.

(b) most of our consumers are developing in C#. A survey we did a while ago revealed that only 1 in 8 of survery participants favoured VB over C#. I do concede the survey may not be representative if the VB "lazy"[1] coding style falls over into filling out surveys too.

(c) since we have a significant investment in C#, we're going to stick with it. We now mandate that any samples for new class libraries are provided in both C# and VB. We just not going to rewrite the whole code base in VB. Also, I think the SDF is a good resource for VB devs wanting to break into C#. So VBers can still get some benefit from the code.

---------------
[1] By "lazy" I'm referring to the common reasons for not learning C# -- "Case sensitive languages suck", "Braces and semi-colons? WASH YOUR MOUTH OUT!", etc, etc.
Neil Cowburn
Tuesday, November 16, 2004 2:02:46 PM (GMT Standard Time, UTC+00:00)
Mostly agreed on a and c.
b is hard to accept though. In other words, 1 in 8 sounds too much to me. I could be wrong, but if the SDF was offered in VB I bet there'd be more downloads than the C# one. I have lost bets before (even I didn't think Greece would win the Euro) but I doubt I'd lose this one.

[no comment on the "lazy" bit or we could spark another VB vs C# thread and none of us want that]
Thursday, November 18, 2004 4:46:23 AM (GMT Standard Time, UTC+00:00)
Actually Paul Yao promised at DevCon to try to port some of the OpenNETCF classes directly to VB as a test of a tool he has. Not seen anything out of it yet, but the offer was extended....
ctacke
Friday, November 19, 2004 8:36:15 AM (GMT Standard Time, UTC+00:00)
Supposedly the reason to have libraries in both languages is to allow VB developers to borrow the code instead of using the library.
I daresay that if a VB developer cannot understand what is being done in C# code to the extent that he is able to reproduce it in VB, he has no business mucking around that source and should simply use the prebuilt library.
alex feinman
Friday, November 19, 2004 8:46:46 AM (GMT Standard Time, UTC+00:00)
Alex -- that's exactly my thoughts too. Modifying code you don't understand is just a recipe for disaster.
Neil
Comments are closed.