Beating a dead Horse: Which Language

[cfmortgagepro]

Hi,

I know that I'm an extreme newb by asking this overly beaten question,
but I am leaning toward C#, becuase the perception is that it is better
to learn than VB.Net. I guess it makes you cooler.:-)

Anyhow, I am a novice programmer, and I will remain one as well...I have
no plans to make programming my life ambition, but I think that it would
be fun to make my databases do some cool tricks and maybe write a
simplistic client to access the database over the LAN, and by internet
as well. My programing will be centered around Data manipulation, i.e.
collecting, sorting, and reporting on this data to myself.....

I want to know which language you find most compelling to accomplish my
mission. It may be that it doesn't have anything at all to do with the
language, from my understanding they are close to equal, but everyone I
come in contact with prefer C# over VB.net
Please, NO FLAMES; just logic
Thank you in advance!

[Herfried K. Wagner [MVP]]

Jon,

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:

What about VB makes it "okay" in your view to have such deeply nested
functionality that would be abhorrent in C#? If it's that you have "End
If" "End For" etc then there's absolutely nothing to stop you from
It's actually 'Next', not 'End For' :-).
for (...)
{
if (...)
{
...
} // If
} // For

Personally I don't like it or feel any need for it, but there's nothing
stopping you from doing it if you feel it adds readability.

The main problem with these comments (which are mandatory in some companies)
is maintainability. It's hard to keep those comments in sync with the
actual block types. VB.NET will automatically check the end statements.

Just my 2 Euro cents...

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Wilbur Slice]

On Thu, 30 Jun 2005 07:30:24 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

Cor Ligthert <no************@planet.nl> wrote:

"Massimo"

> I'm not talking about aesthetics here, but about docing; when you've a
> procedure with *so much* code and flow control inside, probably it's time
> to split it into more smaller ones.
>

Did you try VBNet. I agree completly with you when it are C derived
languages.

As I said, try it, and than tell your expirience after that. Now your answer
looks for me like somebody who tells that he/she never played footbal (there
was something else before), however talks about if he/she is an expert in
it.

What about VB makes it "okay" in your view to have such deeply nested
functionality that would be abhorrent in C#? If it's that you have "End
If" "End For" etc then there's absolutely nothing to stop you from
commenting your C# in the same way:

for (...)
{
if (...)
{
...
} // If
} // For

Personally I don't like it or feel any need for it, but there's nothing
stopping you from doing it if you feel it adds readability.

I think he's talking about VB.NET's automatic formatting (indentation
of code blocks, etc.). And I agree with him - it's something that
VB.NET does better than C#. I still prefer to program in C#, but I
wish it would do the formatting more comprehensively like VB.NET does.
As a C++ programmer from way back (and a C programmer from even
further back), I understand and even sympathize somewhat with C's (and
C++'s and C#'s ) general philosophy of allowing you to format your
code any way you want. I used to think it was Tyranny if an
environment auto-indented code and so forth. And if it doesn't do it
WELL, then it IS very annoying. But the fact is, that formatting
(whether the opening { comes on the same line as the function
declaration or on the next line - aligned with the closing } - on the
same column as the first char of the declaration or indented, etc.) is
trivial and totally unimportant. That someone made that decision
(VB.NET) and enforces the indentations and so forth just frees you
from having to worry about it. Your (and more importantly, other
people's) code is ALWAYS left in a neat and orderly readable state and
all the programmers' code adheres to the standards. That's a good
thing.

I think it's good to let go of the insistance on formatting as we like
it and assimilate. They way VB.NET does it is not objectionable, and
it makes for readable and maintainable code.

I just wish they'd do it in C# too.

[groinker]

It sounds like you want to get something done. Or do you want to be cool?

Either language will accomplish your goal, but for my money, go the VB.Net
route. It actually is the cooler of the two languages because it permits you
to get on with what you want to accomplish without having to overcome some of
the geek "difficulties" entailed with allegedly "the programmers" language
"c#". In short, VB.Net will have your back for what you have suggested,
which is getting a job done, not being Mr. Programmer.

Oh, if you really want to get the lowdown, read just a couple of
introductory chapters of almost any book on VB.Net to see that we VB.Net guys
no longer play second fiddle to the C# crowd. As a progammer surrounded by
nothing but C# adherents, I've yet to see them do something I can't do, but
in fact have done some things which they cannot without great effort. The
whole approach such that you, wanting to do something useful not necessarily
cool which ultimately rules the day, could do so in the language of your
choice.

Ultimately it's your choice, but for someone directly stipulating they don't
want to become a geek, don't choose the alleged de facto geek's language.
Choose a tool and get on with your business, VB.Net. Remember the language
is the tool, not the result.
"cf***********@yahoo.com" wrote:

Hi,

I know that I'm an extreme newb by asking this overly beaten question,
but I am leaning toward C#, becuase the perception is that it is better
to learn than VB.Net. I guess it makes you cooler.:-)

Anyhow, I am a novice programmer, and I will remain one as well...I have
no plans to make programming my life ambition, but I think that it would
be fun to make my databases do some cool tricks and maybe write a
simplistic client to access the database over the LAN, and by internet
as well. My programing will be centered around Data manipulation, i.e.
collecting, sorting, and reporting on this data to myself.....

I want to know which language you find most compelling to accomplish my
mission. It may be that it doesn't have anything at all to do with the
language, from my understanding they are close to equal, but everyone I
come in contact with prefer C# over VB.net


Please, NO FLAMES; just logic
Thank you in advance!

[Jon Skeet [C# MVP]]

Wilbur Slice <[e-mail]> wrote:

I think it's good to let go of the insistance on formatting as we like
it and assimilate. They way VB.NET does it is not objectionable, and
it makes for readable and maintainable code.

I just wish they'd do it in C# too.

But Visual Studio already does.

For instance, suppose I type in:

for (int i=0; i < 5; i++)
{
DoSomething();

When I hit the close brace, it reformats it to:

for (int i=0; i < 5; i++)
{
DoSomething();
}

automatically.

What does VB.NET do in addition to that?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Cor Ligthert]

Jon,

What does VB.NET do in addition to that?

At least VB.Net set the close brace automatic and ident and alligns it
direct in the right place and therefore makes it easy when I am busy.

Before you misunderstand me, I find the braces nicer when I look at a
program.

However when I have to read it I prefer the way from VBNet.

(It is just from my expirience with both, not an accademical idea, braces
are not only used in C# you know. I have forever found the way from VB awful
however changed my mind.)

Cor

[Jon Skeet [C# MVP]]

Cor Ligthert <no************@planet.nl> wrote:

What does VB.NET do in addition to that?

At least VB.Net set the close brace automatic and ident and alligns it
direct in the right place and therefore makes it easy when I am busy.
But Visual C# does exactly that too, as I said in my previous post. It
basically formats the whole block that the brace ends.
Before you misunderstand me, I find the braces nicer when I look at a
program.

However when I have to read it I prefer the way from VBNet.

(It is just from my expirience with both, not an accademical idea, braces
are not only used in C# you know. I have forever found the way from VB awful
however changed my mind.)

I find that when methods are appropriately short, it should be obvious
what braces are lining up with anyway.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Herfried K. Wagner [MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:

I think it's good to let go of the insistance on formatting as we like
it and assimilate. They way VB.NET does it is not objectionable, and
it makes for readable and maintainable code.

I just wish they'd do it in C# too.

But Visual Studio already does.

For instance, suppose I type in:

for (int i=0; i < 5; i++)
{
DoSomething();

When I hit the close brace, it reformats it to:

for (int i=0; i < 5; i++)
{
DoSomething();
}

automatically.

What does VB.NET do in addition to that?

VB will insert the 'Next' automatically when pressing return:

\\\
For i As Integer = 0 To 4<Press return>
///

=>

\\\
For i As Integer = 0 To 4
|
Next
///

"|" indicates the caret position after pressing the return key.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Jon Skeet [C# MVP]]

Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

What does VB.NET do in addition to that?

VB will insert the 'Next' automatically when pressing return:

\\\
For i As Integer = 0 To 4<Press return>
///

=>

\\\
For i As Integer = 0 To 4
|
Next
///

"|" indicates the caret position after pressing the return key.

Given that it's only one extra character to type in C# ("}") I don't
see that as a particularly compelling advantage, to be honest. In fact,
Eclipse has an option to do that kind of thing when I'm writing Java,
and I usually turn it off - I find it breaks the flow if I'm typing in
code, as I type all of it, only to find that the IDE has already filled
some of it in...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Wilbur Slice]

On Thu, 30 Jun 2005 17:50:27 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

Wilbur Slice <[e-mail]> wrote:

I think it's good to let go of the insistance on formatting as we like
it and assimilate. They way VB.NET does it is not objectionable, and
it makes for readable and maintainable code.

I just wish they'd do it in C# too.

But Visual Studio already does.

For instance, suppose I type in:

for (int i=0; i < 5; i++)
{
DoSomething();

When I hit the close brace, it reformats it to:

for (int i=0; i < 5; i++)
{
DoSomething();
}

automatically.

What does VB.NET do in addition to that?

In C# it does sometimes create the correct indentation for you, but
it's easy to type things in in such a way that it doesn't indent
properly, and it's easy to override the indentation scheme. If you go
back to some code that's already in the program and un-indent it, it
will stay that way.

In VB, it is pretty strict about enforcing the formatting, and it
won't even let you change it - if you try, it just pops it back to the
way it thinks it should be. And the way it thinks it should be is not
objectionable (to me, anyway - it's pretty much the way I would format
things anyway) and so it basically always puts your code into standard
formatting no matter what.

Just try it and see.
But I still prefer C# as a language...

[Jon Skeet [C# MVP]]

Wilbur Slice <[e-mail]> wrote:

In C# it does sometimes create the correct indentation for you, but
it's easy to type things in in such a way that it doesn't indent
properly, and it's easy to override the indentation scheme. If you go
back to some code that's already in the program and un-indent it, it
will stay that way.
Yes, thankfully. Sometimes (for whatever reason) I don't want to use
the normal formatting.

If you *accidentally* unindent though, just taking out a closing brace
and reinserting it will reformat the block though.
In VB, it is pretty strict about enforcing the formatting, and it
won't even let you change it - if you try, it just pops it back to the
way it thinks it should be. And the way it thinks it should be is not
objectionable (to me, anyway - it's pretty much the way I would format
things anyway) and so it basically always puts your code into standard
formatting no matter what.

Just try it and see.

Hmm... I'd rather not use an editor which absolutely refuses to let me
reformat when I want to! Fortunately, it looks like you can turn that
off.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Wilbur Slice]

On Thu, 30 Jun 2005 20:58:10 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

Wilbur Slice <[e-mail]> wrote:

In C# it does sometimes create the correct indentation for you, but
it's easy to type things in in such a way that it doesn't indent
properly, and it's easy to override the indentation scheme. If you go
back to some code that's already in the program and un-indent it, it
will stay that way.

Yes, thankfully. Sometimes (for whatever reason) I don't want to use
the normal formatting.

If you *accidentally* unindent though, just taking out a closing brace
and reinserting it will reformat the block though.

In VB, it is pretty strict about enforcing the formatting, and it
won't even let you change it - if you try, it just pops it back to the
way it thinks it should be. And the way it thinks it should be is not
objectionable (to me, anyway - it's pretty much the way I would format
things anyway) and so it basically always puts your code into standard
formatting no matter what.

Just try it and see.

Hmm... I'd rather not use an editor which absolutely refuses to let me
reformat when I want to! Fortunately, it looks like you can turn that
off.

I know what you mean. And I used to feel that way, too. But I got
assimilated. I used VB.NET for a year or so and got used to that
feature - even came to appreciate it. When I switched over to C#, I
found it annoying that I had to waste my attention fretting over
trivial nonsense like formatting.

[Jon Skeet [C# MVP]]

Wilbur Slice <[e-mail]> wrote:

Hmm... I'd rather not use an editor which absolutely refuses to let me
reformat when I want to! Fortunately, it looks like you can turn that
off.

I know what you mean. And I used to feel that way, too. But I got
assimilated. I used VB.NET for a year or so and got used to that
feature - even came to appreciate it. When I switched over to C#, I
found it annoying that I had to waste my attention fretting over
trivial nonsense like formatting.

How much attention does it take to hit '}'? That's all it takes to
reformat a block. Alternatively, Ctrl+K, Ctrl+F will format the
selection.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Wilbur Slice]

On Fri, 1 Jul 2005 17:24:48 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

Wilbur Slice <[e-mail]> wrote:

>Hmm... I'd rather not use an editor which absolutely refuses to let me
>reformat when I want to! Fortunately, it looks like you can turn that
>off.

I know what you mean. And I used to feel that way, too. But I got
assimilated. I used VB.NET for a year or so and got used to that
feature - even came to appreciate it. When I switched over to C#, I
found it annoying that I had to waste my attention fretting over
trivial nonsense like formatting.

How much attention does it take to hit '}'? That's all it takes to
reformat a block. Alternatively, Ctrl+K, Ctrl+F will format the
selection.

Well, like I said. I used to feel the way you do. I made all the
same arguments you're making. But then I used VB.NET for a year or so
and I find that I like it better in this regard.

But it's just a matter of opinion, and you're certainly entitled to
yours. I'm not trying to convert you, I merely stated my personal
opinion.

[thanks]

Depends... read-on... like someone else said it is only a thin layer on top,
best techical summary found is the win script 5.6 help documentation. Note:
a summary to me is a bunch of simple try me examples, and that's what that
is, not some writer, like me's, bs.

1st ask what are your needs; let me summarize then explain. if you are
doing web then i would definately go with vb.net and if you are doing lower
level stuff such as writting hardware drivers then go with vc++. Somewhere
in the middle is c#. I wasted the last several months 16+ hrs a day trying
to get one simple answer, and really concluded it is a far larger battle to
change an os' language, which is really where your question begs to ask...

I think vb for your needs is by far the way to go, yes and no it is easier.
It has the most uses and examples i will say, but any are easy if you spend
the time. Here are some points I 1st overlooked:
1) VB is the LANGUAGE for the ms OFFICE suite, which you will find the key
to any development.
2) its the most WIDELY USED langauage as well.
3) IIS's debug and other key peices to web interaction are made for vb
* Ever language has flaws, vb has a little more history than c# and a larger
library, which will always be true for it has a larger programs base than any
other ms language.
** I don't use it currently, but wish i could at times... so go figure.

--
_____________________________
ian laurin
"cf***********@yahoo.com" wrote:

Hi,

I know that I'm an extreme newb by asking this overly beaten question,
but I am leaning toward C#, becuase the perception is that it is better
to learn than VB.Net. I guess it makes you cooler.:-)

Anyhow, I am a novice programmer, and I will remain one as well...I have
no plans to make programming my life ambition, but I think that it would
be fun to make my databases do some cool tricks and maybe write a
simplistic client to access the database over the LAN, and by internet
as well. My programing will be centered around Data manipulation, i.e.
collecting, sorting, and reporting on this data to myself.....

I want to know which language you find most compelling to accomplish my
mission. It may be that it doesn't have anything at all to do with the
language, from my understanding they are close to equal, but everyone I
come in contact with prefer C# over VB.net
Please, NO FLAMES; just logic
Thank you in advance!

[Lloyd Sparkes]

When i started programing i tried to learn java (about 5 years ago) but gave
up and learnt basic which then progressed into vb4 and then 2 years ago i
got vs.net 2003 and have mainly worked with vb.net up untill christmas but
then i tried to do some programming in c++ and found it impossible to take
what i had learnt in vb to c++. So to try and get into c++ i rewrote a game i
had written in vb to c# and since then i have been able ot write fluently in
c# and have found it 10x easier learning c++ and other c++ like languages
like php, j#, vc++. Personally i would recomend c# as it is simiular to many
other languages, and will help you change to other languages in the future,
although knowing vb is also a good idea, as some big projects are written in
vb.net e.g. DotNetNuke.

another big reason to learn c# is because you are not then tied to microsoft.

borland c# builder and many others also the mono (.net platform for linux
and windows) platform supports c# fully and i have heard that vb.net code
does not compile very well on mono.

also i believe that subconsicenly c# is looked as a better language as it is
more c++ which is known for being a professionals language and respected and
visual basic a basic language for newbies

Lloyd

"cf***********@yahoo.com" wrote:

Hi,

I know that I'm an extreme newb by asking this overly beaten question,
but I am leaning toward C#, becuase the perception is that it is better
to learn than VB.Net. I guess it makes you cooler.:-)

Anyhow, I am a novice programmer, and I will remain one as well...I have
no plans to make programming my life ambition, but I think that it would
be fun to make my databases do some cool tricks and maybe write a
simplistic client to access the database over the LAN, and by internet
as well. My programing will be centered around Data manipulation, i.e.
collecting, sorting, and reporting on this data to myself.....

I want to know which language you find most compelling to accomplish my
mission. It may be that it doesn't have anything at all to do with the
language, from my understanding they are close to equal, but everyone I
come in contact with prefer C# over VB.net
Please, NO FLAMES; just logic
Thank you in advance!

[Gary Hoffer]

Try C Omega from the Microsoft Research site.

"cf***********@yahoo.com" wrote:

Hi,

I know that I'm an extreme newb by asking this overly beaten question,
but I am leaning toward C#, becuase the perception is that it is better
to learn than VB.Net. I guess it makes you cooler.:-)

Anyhow, I am a novice programmer, and I will remain one as well...I have
no plans to make programming my life ambition, but I think that it would
be fun to make my databases do some cool tricks and maybe write a
simplistic client to access the database over the LAN, and by internet
as well. My programing will be centered around Data manipulation, i.e.
collecting, sorting, and reporting on this data to myself.....

I want to know which language you find most compelling to accomplish my
mission. It may be that it doesn't have anything at all to do with the
language, from my understanding they are close to equal, but everyone I
come in contact with prefer C# over VB.net
Please, NO FLAMES; just logic
Thank you in advance!

[stax]

>

How much attention does it take to hit '}'? That's all it takes to
reformat a block. Alternatively, Ctrl+K, Ctrl+F will format the
selection.

on a german keyboard this is 19 keys
including 4 modifiers and two unconvient
finger twists:

if (true)
{
|
}

In VS 2005 code snippets might ease
the pain, I'll try hard to gain from it.

In VB it's 8 keys, no modifiers, no finger twist:

If True Then
|
End If

Curly braces forces me to spend more time
typing and formatting code.

curly braces forces me to read unreadable
formatting by other people.

Curly braces are not verbose enough to improve
editor features like auto formatting and
background compiling.

Curly braces make nested code harder
to read and write, naturally all code
is more or less nested. In VB the IDE
does not only know what type of block
is not closed and shows more meaningful
errors but it also closes the block
automatically, no need for modifier keys
and finger twists.

I understand there are advantages but for the
way my brain and fingers work there are clearly
more disadvantages.

I must admit, if Basic wasn't my first and most
used language I probably would think the opposite.
People get used to doing something one way and
can never get used to doing it another way
even if their method is inferior, people can not
get rid of their habits. I wrote a good amount of
C# and C++ but I don't expect getting used to it
anytime soon.

People have problems understanding differences
of other languages in particular if they didn't
even bother to learn another language. I have tons
of issues with VB as well. I think both languages
are extremes in opposite directions, one is way to
compact and one way to verbose, I wish there would
be something between. I hope someday there will
be a language that fits better to my sense, I've
even considered doing my own language. It would
look pretty much like C# without curly braces,
no parenthesis used after "if", "foreach" etc.,
no semicolons, a couple of keywords added like
"Property" and "Function", better casting syntax
and other small things like "And" instead of &&,
no case sensitiveness. That are the things that
bother me more or less in C#. Lot's of things can
be shortened like "Use" instead of "using" or "Space"
instead of "Namespace" though that keywords aren't
used often anyway.

Regards,
stax

[Primera]

So....if you should learn the .NET Framework, and then learn the various
languages....could you please recommend some books to start with on this
journey?

Thanks

"Carlos J. Quintero [.NET MVP]" wrote:

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> escribió en el mensaje
news:%2****************@TK2MSFTNGP14.phx.gbl...

Consider VB's intrinsic functions -- some of these functions exist (with
slight adaptions) since early versions of BASIC and can still be used. I
see these functions as meta-framework which abstracts from the framework
currently used, and thus prefer these functions over corresponding
functionality which is part of the .NET Framework Class Library.

Interesting, although my view is the opposite: I prefer to use the functions
of the .NET Framework instead of the ones of the early Basic, since the code
is very tied to the .NET Framework anyway. Using the functions of the
framework makes it more easy to migrate to, say C#, or even Java (which uses
a different framework), IMHO.

--
Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio .NET, VB6, VB5 and VBA
You can code, design and document much faster.
Free resources for add-in developers:
http://www.mztools.com

[Jon Skeet [C# MVP]]

Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:

a.. C# code is also harder to "read". "Dim X as New SqlConnection()"
is easier to read than "SqlConnection x = new SqlConnection();"
You may find the C# harder to read, but personally I find it easier. It
keeps the declaration separate from the

In VB.NET you can write 'Dim x As SqlConnection = New SqlConnection()' too.
'Dim x As Y' is more self-describing than "Y x;" and thus less confusing,
especially for beginners.

How long do you really think it takes to get used to the syntax that
doesn't include redundant text? 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? (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'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.

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. That's
from the VS 2005 beta 2 docs, not including unreserved keywords in VB
or those beginning with #. 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.

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.)

b.. C# is anal. VB is forgiving.

I like compilers to be picky. It means I can find more potential
problems at compile time rather than hoping I'll hit all of them in
testing.

C# doesn't have advantages with 'Option Strict' and 'Option Explicit' turned
on. In fact VB.NET is even more strict than C# with these settings applied.

In a very few cases - but not in many others.
Consider the following piece of code:

\\\
bool a = ..., b = ...;
if (a = b)
...;
///

A beginner wants to compare the values of 'a' and 'b' and forgets to type
'==' as comparison operator. The code will compile and it's very hard to
find the logical bug. This gets even worse when dealing with more complex
expressions.
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?
In VB.NET, potential problems like this do not occur as often.

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.

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.

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?

d.. VB.NET can automatically deal with type coercion. C# cannot.
Sure, this "feature" can hide potential problems, but for beginners
it makes learning the BASICs easier.

Again, I like to see problems early.

The great thing is that you can turn the feature off and work with strict
semantics, without loosing the benefits of a BASIC-type programming
language.

Even "strict" isn't strict enough for me though - see above.

As for the benefits of a BASIC-type language - they remain to be shown
to my satisfaction.

Double click on the brace and you'll find the matching one. If your
methods are short for readability purposes anyway, it shouldn't be a
problem IME.

I don't think that it's a big problem either, but in VB.NET you don't even
need to doubleclick anywhere or watch at tooltips, depending on the IDE you
are using.

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

C# is a significantly cleaner language than Managed C++, IMO. Unlessyou
need the ease of calling unmanaged code directly, I'd strongly urge
"native" C++ developers who are moving to .NET to at least give C# a
good try.

I don't see much need for C#. On the one hand, C++/CLI will strongly
improve developing managed/mixed solutions using C++, on the other hand the
VB.NET programming language is IMO more suitable for general .NET
development (libraries, database development, web development) than C#
because it encourages developers to write CLS-compliant code.

You can force C# to be CLS-compliant too very easily - just add the
CLSCompliantAttribute to the assembly.

You might want to consider this similar to the fact that VB.NET doesn't
even have Option Strict on by default - which is *far* more dangerous
than non-CLS-compliance, in my view.

C# is *much, much* easier to develop in than C++, even managed C++, and
I still find it a significantly better language than VB.NET for pure
..NET development.

Are you able to show that VB.NET developers are more productive than C#
developers, by the way?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[SpikeTool]

If you have no intention of making programming your life's ambition, go with
VB. Database development is fast, clean, and powerful in VB without the
learning curve of C (# or otherwise). VB.NET has some awesome database tools
built-in. Regardless of what anyone says, VB is as powerful (if not more so)
as C in database application development. Dont take my word for it, ask
Microsoft.

C gets its power from its intrinsic design and vast library collection. VB
is not portable (like to Linux or Mac), C is. C is almost holy to the memory,
interrupt, and environment control freaks, VB could care less (unless it has
something to do with the functionality of the application you are building).
Ten years ago I would have said "at least KNOW C". For Windows development
here and now, its six of one, half a dozen of the other.

As far as the cool factor goes, cool is subjective. I think its cool when my
app does what I want without bugs or a BSOD (blue screen of death),
regardless of how I built it. The end user wont see your code, he will see
the crash.

--
-SpikeTool

"cf***********@yahoo.com" wrote:

Hi,

I know that I'm an extreme newb by asking this overly beaten question,
but I am leaning toward C#, becuase the perception is that it is better
to learn than VB.Net. I guess it makes you cooler.:-)

Anyhow, I am a novice programmer, and I will remain one as well...I have
no plans to make programming my life ambition, but I think that it would
be fun to make my databases do some cool tricks and maybe write a
simplistic client to access the database over the LAN, and by internet
as well. My programing will be centered around Data manipulation, i.e.
collecting, sorting, and reporting on this data to myself.....

I want to know which language you find most compelling to accomplish my
mission. It may be that it doesn't have anything at all to do with the
language, from my understanding they are close to equal, but everyone I
come in contact with prefer C# over VB.net
Please, NO FLAMES; just logic
Thank you in advance!

[Jon Skeet [C# MVP]]

SpikeTool <Sp*******@discussions.microsoft.com> wrote:

If you have no intention of making programming your life's ambition, go with
VB. Database development is fast, clean, and powerful in VB without the
learning curve of C (# or otherwise). VB.NET has some awesome database tools
built-in. Regardless of what anyone says, VB is as powerful (if not more so)
as C in database application development. Dont take my word for it, ask
Microsoft.

C gets its power from its intrinsic design and vast library collection. VB
is not portable (like to Linux or Mac), C is. C is almost holy to the memory,
interrupt, and environment control freaks, VB could care less (unless it has
something to do with the functionality of the application you are building).
Ten years ago I would have said "at least KNOW C". For Windows development
here and now, its six of one, half a dozen of the other.

As far as the cool factor goes, cool is subjective. I think its cool when my
app does what I want without bugs or a BSOD (blue screen of death),
regardless of how I built it. The end user wont see your code, he will see
the crash.

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,
all the power of the .NET framework which VB.NET uses for database
access is also available in C#.

I wouldn't want to do database development in C, but the OP didn't
*ask* about C - he asked about C#.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[William \(Bill\) Vaughn]

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

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

"SpikeTool" <Sp*******@discussions.microsoft.com> wrote in message
news:6B**********************************@microsof t.com...

If you have no intention of making programming your life's ambition, go
with
VB. Database development is fast, clean, and powerful in VB without the
learning curve of C (# or otherwise). VB.NET has some awesome database
tools
built-in. Regardless of what anyone says, VB is as powerful (if not more
so)
as C in database application development. Dont take my word for it, ask
Microsoft.

C gets its power from its intrinsic design and vast library collection. VB
is not portable (like to Linux or Mac), C is. C is almost holy to the
memory,
interrupt, and environment control freaks, VB could care less (unless it
has
something to do with the functionality of the application you are
building).
Ten years ago I would have said "at least KNOW C". For Windows development
here and now, its six of one, half a dozen of the other.

As far as the cool factor goes, cool is subjective. I think its cool when
my
app does what I want without bugs or a BSOD (blue screen of death),
regardless of how I built it. The end user wont see your code, he will see
the crash.

--
-SpikeTool

"cf***********@yahoo.com" wrote:

Hi,

I know that I'm an extreme newb by asking this overly beaten question,
but I am leaning toward C#, becuase the perception is that it is better
to learn than VB.Net. I guess it makes you cooler.:-)

Anyhow, I am a novice programmer, and I will remain one as well...I have
no plans to make programming my life ambition, but I think that it would
be fun to make my databases do some cool tricks and maybe write a
simplistic client to access the database over the LAN, and by internet
as well. My programing will be centered around Data manipulation, i.e.
collecting, sorting, and reporting on this data to myself.....

I want to know which language you find most compelling to accomplish my
mission. It may be that it doesn't have anything at all to do with the
language, from my understanding they are close to equal, but everyone I
come in contact with prefer C# over VB.net
Please, NO FLAMES; just logic
Thank you in advance!

[doug00]

Chad Z. Hower aka Kudzu wrote:

This is your summary of what makes C# an non beginngers language?

You missed the part in my note where I referred to VB.NET. According
to your logic, since I didn't mention the Empire State building either,
I must have been making arguments about why the Empire State building
is not a beginners' language either.

[doug00]

Chad Z. Hower aka Kudzu wrote:

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]

Jon wrote:

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]]

do****@gmail.com <do****@gmail.com> wrote:

Jon wrote:

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

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Steve Walker]

In message <MP************************@msnews.microsoft.com >, Jon Skeet
<?@pobox.com.invalid> writes

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.

--
Steve Walker

[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]

"do****@gmail.com" <do****@gmail.com> wrote in
news:11**********************@f14g2000cwb.googlegr oups.com:

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.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blogs: http://www.hower.org/kudzu/blogs

[Herfried K. Wagner [MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.com> schrieb:

>> a.. C# code is also harder to "read". "Dim X as New SqlConnection()"
>> is easier to read than "SqlConnection x = new SqlConnection();"
>
> You may find the C# harder to read, but personally I find it easier. It
> keeps the declaration separate from the
In VB.NET you can write 'Dim x As SqlConnection = New SqlConnection()'
too.
'Dim x As Y' is more self-describing than "Y x;" and thus less confusing,
especially for beginners.

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]()
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.

Consider the following piece of code:

\\\
bool a = ..., b = ...;
if (a = b)
...;
///

A beginner wants to compare the values of 'a' and 'b' and forgets to type
'==' as comparison operator. The code will compile and it's very hard to
find the logical bug. This gets even worse when dealing with more
complex
expressions.

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?"...

In VB.NET, potential problems like this do not occur as often.

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...

> Double click on the brace and you'll find the matching one. If your
> methods are short for readability purposes anyway, it shouldn't be a
> problem IME.

I don't think that it's a big problem either, but in VB.NET you don't
even
need to doubleclick anywhere or watch at tooltips, depending on the IDE
you
are using.

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Bill Butler]

"William (Bill) Vaughn" <bi**************@nwlink.com> wrote in message
news:ef**************@TK2MSFTNGP12.phx.gbl...

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]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in
news:ew**************@TK2MSFTNGP14.phx.gbl:

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 (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blogs: http://www.hower.org/kudzu/blogs

[Chad Z. Hower aka Kudzu]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om:

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.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blogs: http://www.hower.org/kudzu/blogs

[Herfried K. Wagner [MVP]]

Chad,

"Chad Z. Hower aka Kudzu" <cp**@hower.org> schrieb:

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.

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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Jon Skeet [C# MVP]]

Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

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.

I think we'll have to agree to disagree.

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:

And again, we'll have to disagree.

(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]()
Dim x As IFooBar = goo.Bar.@IFooBar
///

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

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', ...).

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).

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.

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

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.

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

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?"...

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*?

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#.

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?

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.

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.

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...

<shrugs> I do, and I suspect a lot of VB developers don't know what's
going on behind the scenes, and that some of them may be bitten by it.

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.

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

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Chad Z. Hower aka Kudzu]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in
news:eX**************@TK2MSFTNGP12.phx.gbl:

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.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blogs: http://www.hower.org/kudzu/blogs

[Herfried K. Wagner [MVP]]

"Chad Z. Hower aka Kudzu" <cp**@hower.org> schrieb:

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 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.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Jon Skeet [C# MVP]]

Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in
news:eX**************@TK2MSFTNGP12.phx.gbl:

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.

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.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Tom Shelton]

In article <MP************************@msnews.microsoft.com >, Jon Skeet [ C# MVP ] wrote:

Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in
news:eX**************@TK2MSFTNGP12.phx.gbl:

> 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.

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 ();

--
Tom Shelton [MVP]

[Jon Skeet [C# MVP]]

Tom Shelton <to*@YOUKNOWTHEDRILLmtogden.com> wrote:

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();

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Willy Denoyette [MVP]]

"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:eM****************@TK2MSFTNGP12.phx.gbl...

In article <MP************************@msnews.microsoft.com >, Jon Skeet
[ C# MVP ] wrote:

Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in
news:eX**************@TK2MSFTNGP12.phx.gbl:
> 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.

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 ();

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

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

[Jon Skeet [C# MVP]]

Willy Denoyette [MVP] <wi*************@telenet.be> wrote:

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();

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Chad Z. Hower aka Kudzu]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in
news:OV**************@TK2MSFTNGP12.phx.gbl:

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.
I agree.
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.

Aah - if it were ported directly to C# yes as is. But Delphi constructors are different, so in Delphi
they cannot be confused with type casting.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blogs: http://www.hower.org/kudzu/blogs

[Chad Z. Hower aka Kudzu]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in news:MPG.1d3f8674e471533398c486
@msnews.microsoft.com:

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.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blogs: http://www.hower.org/kudzu/blogs

[Jon Skeet [C# MVP]]

Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:

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.

How? It just makes it more readable, as far as I can see. Where would a
bug creep in? How frequently do you see such bugs creep in? You seem to
see an awful lot of bugs I never see ;)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Willy Denoyette [MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Willy Denoyette [MVP] <wi*************@telenet.be> wrote:

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();

--

Agreed, I just tried to please those who don't like the paired bracketing
characters ;-)

Willy.

[Chad Z. Hower aka Kudzu]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om:

How? It just makes it more readable, as far as I can see. Where would
If you dont separate it - which many dont.
a bug creep in? How frequently do you see such bugs creep in? You seem
to see an awful lot of bugs I never see ;)

Because I work with a lot of students, and I also work with a lot of porting projects in which people
are coming from other languages. If I recall, you work on a fixed team in one company, which is
probably true of most developers in this group.

I work with many teams - some long term, some short term, but always new stuff here and there.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blogs: http://www.hower.org/kudzu/blogs

[Tom Shelton]

In article <Os**************@TK2MSFTNGP10.phx.gbl>, Willy Denoyette [MVP] wrote:

"Tom Shelton" <to*@YOUKNOWTHEDRILLmtogden.com> wrote in message
news:eM****************@TK2MSFTNGP12.phx.gbl...

In article <MP************************@msnews.microsoft.com >, Jon Skeet
[ C# MVP ] wrote:

Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in
news:eX**************@TK2MSFTNGP12.phx.gbl:
> 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.

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 ();

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

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

Oh, I agree. I'm just seems that when reading code like the example I
gave, that it can sometimes be missed what is going on.

--
Tom Shelton [MVP]

[Jon Skeet [C# MVP]]

Chad Z. Hower aka Kudzu <cp**@hower.org> wrote:

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
news:MP************************@msnews.microsoft.c om:

How? It just makes it more readable, as far as I can see. Where would

If you dont separate it - which many dont.

Ah, I see. I took your post to mean that the bugs would creep in if you
*did* separate the lines...

a bug creep in? How frequently do you see such bugs creep in? You seem
to see an awful lot of bugs I never see ;)

Because I work with a lot of students, and I also work with a lot of
porting projects in which people are coming from other languages. If
I recall, you work on a fixed team in one company, which is probably
true of most developers in this group.

I work with many teams - some long term, some short term, but always
new stuff here and there.

Right. I do see a lot of code written outside my team though -
including open source projects and a lot of code here on the
newsgroups, often written by beginners. I still don't see many of the
kind of bugs you talk about - certainly not often enough to talk about
them being *frequent* problems. <shrug>

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Chad Z. Hower aka Kudzu]

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in news:MPG.1d3fa68a908b4db398c493
@msnews.microsoft.com:

Right. I do see a lot of code written outside my team though -
including open source projects and a lot of code here on the
newsgroups, often written by beginners. I still don't see many of the
kind of bugs you talk about - certainly not often enough to talk about
them being *frequent* problems. <shrug>

Because by the time you get the code - its been debugged. It may not be a "release" but it is a release
for others. I work directly with many teams on porting, teaching etc and I see the initimate details of
the development process of various teams - ie what bugs they hit during compiliation, testing etc
before it goes to anyone else.
--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Blogs: http://www.hower.org/kudzu/blogs