Beating a dead Horse: Which Language

[doug00]

I dont doubt it in the manner you posted. But teh manner that the first person posted either was not
posted well, or the poster seems to think that {} ; and case senstivity are the hallmarks of a
professional language and the deciding factor. I was trying to determine if thats what he meant, or it
was simply a miscommunication in his post.

It was clearly a misinterpretation and a misreading on your part.

 

[doug00]

It keeps the declaration separate from the assignment, and they
logically are two different concepts. The VB also introduces two extra
keywords for no particular purpose, as far as I can see. From the C#,
it's obvious that it's a declaration because it starts with a type
name. Why include extra text which carries no information?

That begs the question, how is it obvious (to a beginner especially)
that something refers to a type name? In fact, the concept of "type"
itself is very difficult to explain:
http://lambda-the-ultimate.org/node/view/412
I'll just say that VB.NET for its part did find one solution to make
type declarations easy to recognize.
For others who somehow take what I say as some insult to their favorite
language, note I wasn't referring to C# or any other language, so I
hope you won't somehow interpret what I say as a sting against C#. I
like C# a great deal. Especially for people with familiarity with
java/C/C++, I'd recommend that over VB.NET in a heart beat. Does that
mean it is bad for beginners without that experience, too? No.

 

[Jon Skeet [C# MVP]]

That begs the question, how is it obvious (to a beginner especially)
that something refers to a type name? In fact, the concept of "type"
itself is very difficult to explain:
http://lambda-the-ultimate.org/node/view/412

If someone isn't interested in learning the fundamentals of a language
(like what a type is) before diving into the language, I think they're
making a big mistake. Maybe VB.NET makes it easier to dive into the
language, giving it an advantage for a couple of days - but as I don't
think that's a terribly appropriate way to learn a language/platform
anyway, I don't think it's a very important advantage.

A lot of people are far too impatient to get straight into GUI
programming, without taking the trouble to learn either the language
they're using or the basics of the platform it's running on. I always
urge people to start with very simple console apps that don't need to
use any library calls other than printing out values and possibly a bit
of string manipulation. Move onto collections, then IO, then you may be
ready for some GUI work - although it would frankly be better to learn
a bit about threading before starting on GUI work, as it's so important
there.

I'll just say that VB.NET for its part did find one solution to make
type declarations easy to recognize.

But you still need to use the redundant keywords all the time, even
after you've got over the slight learning curve in terms of recognising
what constitutes a declaration.

For others who somehow take what I say as some insult to their favorite
language, note I wasn't referring to C# or any other language, so I
hope you won't somehow interpret what I say as a sting against C#. I
like C# a great deal. Especially for people with familiarity with
java/C/C++, I'd recommend that over VB.NET in a heart beat. Does that
mean it is bad for beginners without that experience, too? No.

I wouldn't say that it's bad for beginners, but I *would* say that some
of the verbosity and non-standard terminology which supposedly makes it
better for beginners becomes a pain when you actually know what you're
doing.

Of course, you've got to add to that the fact that it's a much bigger
language in itself than C# - far more in the way of keywords, built-in
functions etc.

 

[Steve Walker]

In message <[email protected]>, Jon Skeet

I'll certainly accept that C# has a bit of a steeper learning curve
than VB.NET, but I don't think that's the be all and end all.

I used to work for a company which was a VB6 shop. I got the job of
evaluating .NET. My recommendation was that we abandon VB and go the C#
route, which we did. None of the developers (who ranged in experience
from very little to lots) had any trouble learning C#.

One of my former colleagues came with me on a fishing trip last night,
and mentioned that he was glad I went for C#; he's recently left that
company to become a contractor, and he says the rates of pay for C# are
much better.

That might be because C# is (wrongly, IMO) perceived as being harder,
but I suspect it's actually because the kind of talentless,
cut-and-paste, whole-program-in-an-event-procedure spaghetti-code
merchants who gave good VB6 developers an undeserved bad name are
unlikely to have bothered learning C#. I'm sure that those people don't
post to advocacy threads on *.languages.* newsgroups, so I don't mean to
insult anyone by saying that, and I dare say there are some crusty
former C programmers writing entire C# programs in Main(), but I fear
that perception may still be out there.

For what it's worth, I side with another friend of mine who has been
paid to program in more languages than I can name; if you're any good,
you'll be able to teach yourself whatever language the job requires. I
really don't see that anyone competent in VB.NET should take more than a
couple of days to become proficient in C#, and vice-versa. The learning
curve is all in the framework and the understanding of OO.

 

[ChrisN]

I always fancied doing a contract in Italy, on the basis that it may be
the only place where I am not told "Don't bother spending time making
the interface look nice".

Even a drain cover in Italy is beautifully designed.

Chris

 

[Chad Z. Hower aka Kudzu]

It was clearly a misinterpretation and a misreading on your part.

While it certainly was a misreading - a lot of it was how you worded it. I think that most users will
read it the way that I did in the manner you worded it.

 

[Herfried K. Wagner [MVP]]

How long do you really think it takes to get used to the syntax that
doesn't include redundant text?

It doesn't take long, but the code is still not as self-documenting and
self-explanatory as the VB.NET code is.

Have a look at the casting syntax in C#
compared with VB.NET - do you really think that the CType syntax is
more elegant than the casting syntax?

Yes, I actually think that VB.NET's casting syntax is better because it
doesn't suffer from the "lots of brackets" problem:

\\\
((SampleForm)foo.MdiParent).Bla();
///

versus

\\\
DirectCast(foo.MdiParent, SampleForm).Bla()
///

However, I don't think that VB.NET's solution is the best possible solution.

(Admittedly I wish that the
unboxing and conversion syntax in C# were distinct from casting, but
that's another issue. There are various things I'd like to see done
differently in C#...)

I'd like to see something like shown below as casting syntax:

\\\
(e-mail address removed)()
Dim x As IFooBar = goo.Bar.@IFooBar
///

In terms of a language itself, of course, it's significantly smaller
than VB.NET - what there is may be slightly harder to learn, but there
are far fewer keywords - 78 in C# compared with 151 in VB.NET.

There are many specialized keywords a beginner doesn't need to be aware of
('Declare', 'Auto', 'Unicode', 'Ansi', 'Alias', etc.). Some other keywords
increase readability of the code and are thus worth learning ('Overloads',
'AddressOf', 'RaiseEvent', 'Implements', 'Inherits', 'MyBase', ...). Other
keywords listed for VB.NET are not keywords at all ('Variant', 'Wend',
'GoSub', 'Let', 'EndIf', ...). Keywords like 'REM' and 'Stop' are rarely
used. The list of C# keywords doesn't include operators, but VB operators
are listed as keywords ('Or', 'And', 'OrElse', 'AndAlso', 'Xor', 'Not',
'Mod', ...). Another class of keywords are keywords for features only
supported by one of the programming languages ('Like', 'With', 'My',
'WithEvents', 'Handles', 'Where', 'On', 'Error', 'Resume', ...).

That's also not including all the VB built
in functions, many of which have been carried over from previous
versions of VB despite perfectly reasonable versions of many (most? I
don't have enough experience in VB to know) being available in the
framework.

Use of these functions is optional, it's not crucial to know how these
functions work.

In short, being a new language, C# doesn't have nearly as much baggage
as VB.NET does. (There are one or two places where C syntax has
unnecessarily been carried over, and that's a shame, but it's far from
the same situation as in VB.NET.)

I think that both languages, C# and VB.NET, carry over a lot of legacy
syntax. I believe that the ability to reuse knowledge is very important for
the success of a new programming language. Additionally I prefer
code-compatibility to a language's predecessor over revolutionary change.

Only where you're comparing two boolean values directly, which I find
to be pretty rare. I'll certainly accept that there's potential for a
bug there though. How often have you actually seen that bug, out of
interest?

I have seen it several times when working together with C++ beginners who
come from various backgrounds, and the bug made them ask "Why doesn't the
code work as expected?"...

Consider the following then, where "thread" is a variable of type
Thread:

thread.Sleep(5000);

If you were a beginner, what would you think that would do? In C# it's
not valid because Thread.Sleep is a static method. In VB.NET (2003) it
compiles without a warning, even in Option Strict mode. In 2005 it's an
optional warning/error, fortuantely.

It's a matter of semantics. The 'Shared' keyword in VB.NET means that the
member is shared between all instances of a class, which is different from
the semantic of 'static' in C#.

Another example - C# doesn't let you use a local variable unless it's
been definitely initialised. VB.NET (2003) does - again, a new
warning/error in 2005.

VB.NET automatically initializes variables, which is IMO a good thing in
addition to the warning.

Another example - VB.NET lets you pass properties by reference, even
though the semantics are significantly different in terms of timing and
what happens if an exception is thrown. I wonder what proportion of
VB.NET developers really know what happens when a property is passed by
reference?

I don't see a big problem here...

And as I say, you don't need to in C# if you write readable code to
start with.

Yeah, you could still scan the code for the blocks' heads with your eyes,
but this is a costly process.

 

[Bill Butler]

That's funny. There are more "professional" developers today coding in VB
and its derivatives than all other languages combined.

But, are they doing by choice???
Anytime I had to work with VB, it was out of my hands.
The language for the project had been chosen before my time.

Bill

 

[Chad Z. Hower aka Kudzu]

Yes, I actually think that VB.NET's casting syntax is better because
it doesn't suffer from the "lots of brackets" problem:

\\\
((SampleForm)foo.MdiParent).Bla();

This is one thing that I really really dont like about C#. I much prefer Delphi's casting which I thikn
is similar to VB.NET.

SampleForm(foo.MdiParent).Bla();

DirectCast(foo.MdiParent, SampleForm).Bla()

Ack, Im not to fond of that either. I'll stick to preferring Delphi's semantics on this one.

 

[Chad Z. Hower aka Kudzu]

You seem to be regarding C# as equivalent to C. While the syntax is
similar in many ways, they're very different languages. For one thing,

They are significantly different. C# is much closer to C++, and even then quite different.

 

[Herfried K. Wagner [MVP]]

Chad,

This is one thing that I really really dont like about C#. I much prefer
Delphi's casting which I thikn
is similar to VB.NET.

SampleForm(foo.MdiParent).Bla();


Ack, Im not to fond of that either. I'll stick to preferring Delphi's
semantics on this one.

I don't think that the approaches taken in C#, Delphi, and VB.NET are
optimal. However, I prefer the way Delphi and VB.NET handle casts.

 

[Jon Skeet [C# MVP]]

It doesn't take long, but the code is still not as self-documenting and
self-explanatory as the VB.NET code is.

I think we'll have to agree to disagree.

Yes, I actually think that VB.NET's casting syntax is better because it
doesn't suffer from the "lots of brackets" problem:

And again, we'll have to disagree.

I'd like to see something like shown below as casting syntax:

\\\
(e-mail address removed)()
Dim x As IFooBar = goo.Bar.@IFooBar
///

Eek - I find that as bad as anything else I've seen, personally.

There are many specialized keywords a beginner doesn't need to be aware of
('Declare', 'Auto', 'Unicode', 'Ansi', 'Alias', etc.). Some other keywords
increase readability of the code and are thus worth learning ('Overloads',
'AddressOf', 'RaiseEvent', 'Implements', 'Inherits', 'MyBase', ...). Other
keywords listed for VB.NET are not keywords at all ('Variant', 'Wend',
'GoSub', 'Let', 'EndIf', ...). Keywords like 'REM' and 'Stop' are rarely
used. The list of C# keywords doesn't include operators, but VB operators
are listed as keywords ('Or', 'And', 'OrElse', 'AndAlso', 'Xor', 'Not',
'Mod', ...). Another class of keywords are keywords for features only
supported by one of the programming languages ('Like', 'With', 'My',
'WithEvents', 'Handles', 'Where', 'On', 'Error', 'Resume', ...).

But you need to know those keywords if you're going to read code which
uses them, and presumably you're prevented from declaring identifiers
with those names (which is where it's not a problem with C# in terms of
the operators being symbols rather than names).

Use of these functions is optional, it's not crucial to know how these
functions work.

But it's a cause of confusion to someone who's familiar with .NET, but
not as familiar with VB functions.

I think that both languages, C# and VB.NET, carry over a lot of legacy
syntax. I believe that the ability to reuse knowledge is very important for
the success of a new programming language. Additionally I prefer
code-compatibility to a language's predecessor over revolutionary change.

Whereas I prefer the *language* to be small, and the *library* to be
where functionality lies.

I have seen it several times when working together with C++ beginners who
come from various backgrounds, and the bug made them ask "Why doesn't the
code work as expected?"...

Ah, but in C/C++ it's different - in C/C++ you can get the error with
types other than a boolean. How often have you seen it *with booleans*?

It's a matter of semantics. The 'Shared' keyword in VB.NET means that the
member is shared between all instances of a class, which is different from
the semantic of 'static' in C#.

I don't believe it's different at all - and I don't believe it means
it's shared between all instances. Just as in C#, it really means that
the member belongs to the type rather than any particular member. Even
the VB.NET documentation says that:

<quote>
Shared elements are not associated with a specific instance of a class
or structure.
</quote>

The implication from your statement is that the member effectively
doesn't exist if there are no instances (because the set of instances
it is shared between would be empty) whereas that's not true.

Could you give an example where something being static in C# and Shared
in VB.NET would produce semantically different code?

I *do* understand the difference between VB.NET's Static and C#'s
static though.

You still haven't addressed the actual issue though - if someone writes

thread.Sleep(1000)

in VB.NET, it compiles (in VS.NET 2003) without error, but doesn't do
what is expected.

Put it this way - if it's not a bad thing to do, why is there a warning
for it in VS 2005?

VB.NET automatically initializes variables, which is IMO a good thing in
addition to the warning.

It's good to initialize *member* variables, but why would you *want* to
use a local variable which hadn't been definitely assigned? It seems
like a bad idea to me.

I don't see a big problem here...


Yeah, you could still scan the code for the blocks' heads with your eyes,
but this is a costly process.

Not if the method is well written and indented. I certainly don't spend
a lot of time doing it.

 

[Chad Z. Hower aka Kudzu]

I don't think that the approaches taken in C#, Delphi, and VB.NET are
optimal. However, I prefer the way Delphi and VB.NET handle casts.

The syntax? Or other? I dont like the way C# handles it simply because you often have to add more
() to tell it what to cast, and if you dont it can cast something other than you might expect.

 

[Herfried K. Wagner [MVP]]

The syntax? Or other?

I don't like the syntax for type casts in C#, I consider it a bad design and
legacy syntax because of the "lots of braces" issue that could have been
solved easily.

On the other hand, I like the syntax for casts in VB.NET and Delphi more.
However, I think that the VB casting syntax is too verbose and thus
increasing the line length of the code without adding much value to the
code. The Delphi casting syntax IMO suffers from the problem that it is
similar to a constructor call, especially when being incorporated into
VB.NET or C#, and thus maybe misleading.

I dont like the way C# handles it simply because you often have to add
more
() to tell it what to cast, and if you dont it can cast something other
than you might expect.

ACK.

 

[Jon Skeet [C# MVP]]

The syntax? Or other? I dont like the way C# handles it simply
because you often have to add more () to tell it what to cast, and if
you dont it can cast something other than you might expect.

I agree it can be a pain sometimes, but I find that usually it's a good
indication that things can be made more readable by using a local
variable - the cast in one statement and the use in another.

It's one of those situations where I think there's no really good
solution - in some cases you *do* want to cast the result of a method
(eg (Foo) x.Something()) and sometimes you want to cast the "starting"
value. I dare say C#'s way isn't the best possible, but I still
personally prefer it to the VB.NET way.

 

[Tom Shelton]

I agree it can be a pain sometimes, but I find that usually it's a good
indication that things can be made more readable by using a local
variable - the cast in one statement and the use in another.

It's one of those situations where I think there's no really good
solution - in some cases you *do* want to cast the result of a method
(eg (Foo) x.Something()) and sometimes you want to cast the "starting"
value. I dare say C#'s way isn't the best possible, but I still
personally prefer it to the VB.NET way.

I so totally agree... VB.NET's way is very cumbersome, especially when
dealing with mutliple casts in the same expression. Besides, for a lot
of simple casts, C# does provide as.

The most confusing cases, IMHO, is when you do something like:

int y = ((Foo) x).CallSomeMethod ();

 

[Jon Skeet [C# MVP]]

I so totally agree... VB.NET's way is very cumbersome, especially when
dealing with mutliple casts in the same expression. Besides, for a lot
of simple casts, C# does provide as.

The most confusing cases, IMHO, is when you do something like:

int y = ((Foo) x).CallSomeMethod ();

Exactly - and those are the cases where I'd suggest breaking it up:

Foo whatever = (Foo)x;
int y = whatever.CallSomeMethod();

 

[Willy Denoyette [MVP]]

I so totally agree... VB.NET's way is very cumbersome, especially when
dealing with mutliple casts in the same expression. Besides, for a lot
of simple casts, C# does provide as.

The most confusing cases, IMHO, is when you do something like:

int y = ((Foo) x).CallSomeMethod ();

If this is confusing you might try the "clean" way:

...
Foo x = someFooRef as Foo;
int y = x.Dummy();


Willy.

 

[Jon Skeet [C# MVP]]

If this is confusing you might try the "clean" way:

..
Foo x = someFooRef as Foo;
int y = x.Dummy();

Or if you'd prefer to get a ClassCastException rather than a
NullReferenceException (as I certainly would - it gives a much better
idea of what's actually happened):

Foo x = (Foo) someFooRef;
int y = x.Dummy();

 

[Chad Z. Hower aka Kudzu]

I agree it can be a pain sometimes, but I find that usually it's a good
indication that things can be made more readable by using a local
variable - the cast in one statement and the use in another.

In some cases, but its just another roach point. It allows bugs to creep in, and fairly frequently.

value. I dare say C#'s way isn't the best possible, but I still
personally prefer it to the VB.NET way.

I absolutely do not like the VB.NET way either.