Hey Jim,
We've been battling a problem here where two programmers are writing
solutions in different languages. Neither can effectively use the other's
stuff because neither knows the other's language of choice, which leads us
to often reinventing the wheel in our own apps. .NET gets somewhat around
this scenario with the CLR-compliance, but that still assumes that everyone
is "playing nice" and there's an overall architecture being kept in mind so
one can run the other's code. If not, programmer 1 has to borrow
programmer's 2 code then translate it to his own language and tweak it.
While VB's and C#'s usage of the same libraries makes it viable for one to
read the other's code it's still easier to have it translated before
tweaking.
More philosophically, IMHO, having each department or programmer write in
"whatever feels good" puts up barriers to having an overall understanding
between groups and who's doing--or perhaps more importantly, who has already
done--what.
Also, there are currently minor discrepancies in the capabilities of C# and
VB. As .NET continues, there will be more opportunities for these to
diverge.
Just one guy's take!
- John
"Jim Lincoln" <so*******@yahoo.com> wrote in message
news:21**************************@posting.google.c om...
There are various utilities that you can buy to convert VB.Net to C#
(C-Sharpener For Vb, Instant C#, etc.). I'm sure there are others that
convert C# to VB.Net. I don't understand the point of these tools. MS
designed .Net so that I can create assemblies in one language (VB for
instance) and call the assembly from a different language (C# for
instance).
Why bother to convert code from one language to another then? Are some
of you on projects that require everything to be in either C# or
VB.Net? Aren't the languages pretty much the same, so that it is easy
to move between the two?
Thanks for any insight.
Jim Lincoln
