vb.net or C#?

[Cowboy \(Gregory A. Beamer\)]

I don't agree. It's mostly different syntax words for the same. So if you
want to understand syntax, and OOP for example, study OOP in a language
you already know is better then learning different syntax details of
another language. You could better study how compilers work, how OOP
works, independant of the exact language. If you understand that, it's
relative less difficult to work in another language.

You are working with an ideal that is not always present in the world.
Perhaps more now as newer VB devs are coming into the world with no previous
legacy VB experience. But, I found that many, if not most, VBers in the
early .NET days were legacy VBers that switched to .NET. I found tons of
ASP.NET, written like ASP. Things like:

myObject = Object.CreateInstance("")

Yuck. The same was true for the VB syntax. Legacy VB in a .NET app.

I was an ASP/VB COM developer. I switched to C# to make sure I was learning
..NET and not merely trying to code VB into VB.NET. I think this is what
Göran is aiming at. And, if so, I agree with him.

Underneath the hood, it is all IL. And, if someone is truly following OO
practices and using the framework, there are tons of similarities and one
can easily switch, for the most part, from language to language.

But the fact that they compile to the same byte code (have the smae lower
level language) does not mean the higher level language is the same.

 

[Cowboy \(Gregory A. Beamer\)]

Isn't that the purpose of a higher level language: to abstract the details
away ?

Abstract == good;
Hiding == bad;

Please note the semi-colons.

I am actually just toying with you Bill, because I know you are such a good
sport. ;-)

 

[Bill McCarthy]

Abstract == good;
Hiding == bad;

Please note the semi-colons.

I am actually just toying with you Bill, because I know you are such a
good sport. ;-)

<g> Yeh where's my cricket bat when I need it ?

I actually can't think of anything VB hides from you. C# on the other hand
has stuff like :

class Foo : IBar
{
void Baz() {}

void Boo() {}
}

How can I be absolutely sure IBar is an interface other than reliance on a
non enforced naming pattern you hope people follow ? How can I tell whether
Baz or Boo are defiend by IBar or not ?

 

[Marc]

But the fact that they compile to the same byte code (have the smae lower
level language) does not mean the higher level language is the same.

Ah ok, but that's then just because of VB is such a strange language? I have
not done that much in VB, I found it easy to do a little VB programming with
my C++/Java/C# experience. But some things were a bit like 'we don't show
you what really happens since you're to stupid to understand anyway', as far
as I remember. (I only worked a few weeks with it.)

Ok let me refrase then, you can study Delphi, Java, C++ or C# to know how
for example OOP works, it won't matter which of the four advanced languages
you would use.

 

[Jonathan Wood]

Mark,

Please explain how C# and VB.NET are "for the most part exactly the same
language but with slightly different syntax"...

Sorry, but in my view, it's sort of like you occasionally getting hung up
about whether or not someone top posted over what they were actually
writing. The languages are not identical, obviously, but if you look at the
big picture, they really are the same for the most part.

C# and VB.NET use *EXACTLY* the same runtime library, which is running on
the same rich operating system API. For managed code, this means almost
everything. Gone are the days when you write directly to video RAM. Writing
code in a .NET language consists mostly of writing for the frameworks.

Moreover, both compile to the same IL code, which means they are more
similiar than just code that only needs to produce the same machine code.

Yes, one uses semicolons, etc. But that's all just syntax. The big picture
is the frameworks and, with very few exceptions, anyone who understands
VB.NET or C# will be able to understand code written using the other
language.

Jonathan

 

[Jonathan Wood]

Cowboy,

builder.Append("\r\n");

builder.Append(vbCrLf)

These two lines are incredibly similar and produce the exact same result. As
I stated previously, the difference is syntax.

string connString = "";
SqlConnection conn = new SqlConnection(connString);

Dim connString as String = ""
Dim conn As new SqlConnection(connString)

And now C# allows var conn = new SqlConnection(connString). You're
discussing syntax as though it makes these two snippets of code different in
some substantial way. I don't get that. They are accomplishing exactly the
same thing, with the same library, to the same ends. The difference, again,
is syntax.

using(SqlConnection conn = new SqlConnection(connString))
{
conn.Open();
//etc.
}

Dim conn As New SqlConnection(connString)

Try
conn.Open()
Finally
conn.Dispose()
End Try

There are some contructs that could be discribed as more than just syntax.
That's why I said "for the most part" in my original comments on this. But I
still view the above items as exactly the same thing. using provides another
way to do the exact same thing this VB code does but with a different
syntax.

Sure, you can look at the minutia of curly braces and semicolons, and that's
fine if you think that matters. But I've worked extensively with different
languages, and had good reasons to pick one over the other. I used assembler
when my code needs to be as tight as possible. I used VB6 when I need to put
together a Windows application quickly. But I don't have any good reason to
pick C# over VB.NET other than my own personal tastes and issues related to
how many of my potential customers might want to use a particular language.

I mean, do you think I'm going to choose one language over the other because
one lets me use using instead of try/catch? I don't understand why that even
matters.

Jonathan

 

[Jonathan Wood]

Cowboy,

As long as the developer uses the Framework, it is largely true. A lot of
VB developers use the training wheels (VB Compatibility namespace), so all
bets are off. I listed some other differences in response to Marc. ;->

BTW, I haven't tried this, but is there any reason why you couldn't use the
VB Compatibility namespace from C#?

Jonathan

 

[Bill McCarthy]

Mark,


Sorry, but in my view, it's sort of like you occasionally getting hung up
about whether or not someone top posted over what they were actually
writing. The languages are not identical, obviously, but if you look at
the big picture, they really are the same for the most part.

C# and VB.NET use *EXACTLY* the same runtime library, which is running on
the same rich operating system API. For managed code, this means almost
everything. Gone are the days when you write directly to video RAM.
Writing code in a .NET language consists mostly of writing for the
frameworks.

Moreover, both compile to the same IL code, which means they are more
similiar than just code that only needs to produce the same machine code.

Yes, one uses semicolons, etc. But that's all just syntax. The big picture
is the frameworks and, with very few exceptions, anyone who understands
VB.NET or C# will be able to understand code written using the other
language.

Yep. VB has some features C# doesn't when it comes to working with COM
interop, and also with XML. C# on the other hand has unsafe code and
multi-statement lambdas.

 

[Bill McCarthy]

I mean, do you think I'm going to choose one language over the other
because one lets me use using instead of try/catch? I don't understand why
that even matters.

For the record VB does have Using blocks, has since 2005 The only time
there is a significant functional difference between the two is unsafe code
and COM interop. For example, this is real code I saw someone doing in c# :

if(xlApp.Dialogs[Excel.XlBuiltInDialog.xlDialogOpen].Show(sTextName,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing)


In VB, that code is:


If xlApp.Dialogs(Excel.XlBuiltInDialog.xlDialogOpen).Show(sTextName) Then


And inversly I bet we could dig up examples of unsafe code in C#, and lots
of Marshal.Readxxx and Write calls in VB.

 

[Jonathan Wood]

Bill,

For the record VB does have Using blocks, has since 2005 The only
time there is a significant functional difference between the two is
unsafe code and COM interop.

Right. I haven't messed with anything like that using a .NET language, but
my main point is that when you are writing to the frameworks using managed
code, I really don't think it matters which language you choose. If one
language allows more unsafe and COM interop stuff, then that could
potentially be a reason to pick one over the other. That said, however, I
think things like COM interop primarily bridge the gap with older
technologies, and while I don't think that many people are doing stuff like
that now from .NET, I suspect far less will be doing it in the future.

Jonathan

 

[Bill McCarthy]

Bill,


Right. I haven't messed with anything like that using a .NET language, but
my main point is that when you are writing to the frameworks using managed
code, I really don't think it matters which language you choose. If one
language allows more unsafe and COM interop stuff, then that could
potentially be a reason to pick one over the other. That said, however, I
think things like COM interop primarily bridge the gap with older
technologies, and while I don't think that many people are doing stuff
like that now from .NET, I suspect far less will be doing it in the
future.

Yep. I think COM interop will be around for a long time, at least on the
desktop computer, but as far as ASP.NET goes, I'd try to avoid it and also
avoid unsafe code as well. If I was doing a lot of XML, I'd definitely
favour VB, and if I was doing a lot of iterators such as writing a LINQ
provider, I'd probably favour C#. Other than that, the differences are
mainly a matter of taste. One might prefer one of the other, but there
aren't going to be any significant technical hurdles or limitations in one
against the other.

 

[Anthony Jones]

<g> Yeh where's my cricket bat when I need it ?

I actually can't think of anything VB hides from you. C# on the other hand
has stuff like :

class Foo : IBar
{
void Baz() {}

void Boo() {}
}

How can I be absolutely sure IBar is an interface other than reliance on a
non enforced naming pattern you hope people follow ? How can I tell whether
Baz or Boo are defiend by IBar or not ?

It this sort of thing that creates an ambivalance in me.

On the one hand I like VBs explicit style. Because it had no implementation
inheritance before becoming VB.NET the language designers have made good
choices in this area especially in relation to overrides and shadows
(hiding). However C# had to attempt to please the C++ people and this
brought some baggage with it in this area.

On the other hand I like the convienience and brevity of the C# syntax.

IOW, the Jedi in me wants to walk the more verbose explicit path of VB but
the Sith wants the easy and conveniant path of C#.

There you go, encouraging someone to use C# over VB is now tantamount to
inviting them to the dark side <snigger>

 

[Anthony Jones]

But some things were a bit like 'we don't show
you what really happens since you're to stupid to understand anyway',

Or alternatively 'we don't show you what really happens since you're to
intelligent to want to know you just what us to get on and do was we're told
and not bother you with the details since you have more important things to
do'

There are two sides to most coins.