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!

cfmortgage***@yahoo.com wrote:
Its not "cooler" just green, and I prefer green over blue :)

Honestly I think that both would suit your simple requirements just fine
so it comes down to a preference of which syntax you prefer.

VB.Net is possibly "simpler" for a novice as it gives you quite a bit of
help with filling out constructs such as if/where/for/properties etc..
and gives you design time syntax checking with background compile.

Personally I prefer c# but thats just me.

JB

Show quoteHide quote

Do both.

Learn the framework and learn both languages. Then become polished in
whichever the first project is on - that is what you will get most practise
with anyway.

- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
----------------------------------------------------------------------------

<cfmortgage***@yahoo.com> wrote in message
Show quoteHide quote

I agree on this. Languages are only a thin "layer" to learn on top of the
..NET Framework beast.


Show quoteHide quote

I'd go it a step farther and say that programming languages are only a thin
layer on top of programming concepts. Once you get proficient at the
underlying logic of writing code, it becomes merely a matter of a few days to
learn syntax and some good reference books to become functional in a new
language.

I tend to agree with that too, but modern languages (products?) come with
huge frameworks (class libraries) that you need to master too to avoid
reinventing the wheel while programming, so, yes, programming concepts
(structured, object-oriented) are important but class libraries too. So,
finally the syntax is almost irrelevant...

Show quoteHide quote

ACK.  However, often programming languages live longer than class
libraries...  The stronger a programming language is tied to a certain
framework, the harder it will be to migrate the code to a new framework.

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.

The implication from that is that I believe that programming languages
(syntax and meta-frameworks) are more than "sugar".

Just my two Euro cents...

Herfried,

In my opinion is this against all what you have written the last months why
VB classic should be kept alive.

Programming language have the same (however quicker) evolution than natural
languages.

Class librarys have in my opinion to be consistent in there behaviour, even
when it is unwanted behaviour which is not a bug. This to fulfil what you
have written the last months.

Just my 2 eurocents.

Cor

The main problem with the Classic VB/VB.NET issue is that the languages are
not code-compatible although they could have been designed to be.  That's
another topic which has been discussed several times in newsgroups.  Despite
this incompatibility the VB.NET runtime library provides functionality which
is almost compatible with the corresponding functions of earlier BASIC
dialects, which means that some of the knowledge can be reused and code can
theoretically be reused if there were no breaking changes to the syntax like
the loss of support for arbitrary lower bounds of arrays etc.

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.

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

Show quoteHide quote

Andrew Faust wrote:
There are a few exceptions to this.

For example, languages like Prolog, F#, LISP change some of the fundamental
nature of the way you think about what the code is and does.  C++, for
example, encapsulates several different ways to code at once, which makes
reading it challenging at times.

But, certainly, within the confines of a particular paradigm (object
oriented/event driven/etc.) translating from one language to another is
quite simple.

I can't agree with that, there are differences. And some of those
differences can be pretty serious.

For instance, VB.Net can't have a function that returns a value by
reference, which has burned me at least once. It also can't mark an event as
non-serializable, which is a huge pain. And the ability to use unsafe code
and pointers if needed with C# gives you some serious flexibility.

VB.Net has much better intellisense and has better immediate feedback for
when you make mistakes. Not having to cast every single thing is nice. Some
of it's constructs, like Select instead of switch, are a lot better. It's
case insensitivity and syntax are a lot easier to deal with, especially for a
new programmer.

Basically, it boils down to VB.Net is easier to use and C# is slightly more
powerful. Most differences are pretty minor, and some of them are being
smoothed over in 2005 of course, but as someone who has used both, I'd say go
for C# if you can handle it.

What *exactly* do you mean by returning a value by reference?
Parameters can certainly be passed by reference in VB.NET, and I
believe that return values are handled exactly the same way as they are
in C#.

Could you give an example of what you can do in C# (in this regard)
that you can't achieve in VB.NET?

Sorry, I should have said that *objects* are not passed by reference, at
least not really. Instead of returning the pointer to the object, it makes a
copy of the pointer and sends that instead. But you are right, C# does it the
same way. Someone told me it could be done, but I hadn't actually tried it
before tonight.

And I have to retract my advice to the OP. If you aren't going to be doing
this for a living, VB may be the better choice. It's limitations compared to
C# are rather arcane and I doubt you will ever hit them, and they are
probably going away in 2005 anyway. And it is easier to use in a lot of ways.

<cfmortgage***@yahoo.com> wrote in message
Then MS/Access form for client and or MS/FrontPage for web applications
would best fit your need. Now a day, MS/Office Pro also gives you a so
called InfoPath 2003 that is similar to Access Form but work with .Net and
XML and SQL/Server backend RDBMS.

c# is for true "serious" people who want to become "the developer". c# may
frustrate you more !

In short, you must love it both in good and bad times in order to understand
its potential !

MS/Access, FrontPage, InfoPath 2003, VB, Java Script can do these tricks as
well and cheap and 1,000 times easiers than .Net languages.

This is a very tough bone for a novice programmer to chew!

If you still insist on .Net languages, then c# is in both ISO and ECMA
organizations while VB is very Microsoft. Lets imagine that tomorrow, CUS is
nuked and you have to sail to Italy, without c#, them EU bosses don't know
what VB mean, this can mean Very Bad for you. So c# will come to rescue you
and your family in the darkest hours !!! VERY TRUE !!!

That's called smart programming !

Good luck to you, Novice!

John Webb

Correction needed: In .Net, c-sharp is written as c#, not C#. C# is a
musical symbol, it  denotes Do Major (in Italian), in English, it is a C
Major !
Now, this case-sensitive thing alone will drive a novice crazy!

JWebb

WJ <JohnWe***@HotMail.Com> wrote:
Just in case you were serious - C# is capitalised, according to the
language specification.

It's actually "C#", 'Visual Basic .NET" ("VB.NET") and ".NET".

"Visual C#"  ;-)

http://msdn.microsoft.com/vcsharp/

Carlos,

Visual C# is Microsoft's product.  The language's name accoding to the ECMA
specification is C#:

<URL:http://www.ecma-international.org/publications/standards/Ecma-334.htm>

Yes, yes, I know, although my impression is that nobody uses the term
"Visual C#"...

Show quoteHide quote

ACK!  And /really nobody/ uses the plain term "Basic" when talking about
Visual Basic .NET, except Microsoft in the VS.NET IDE properties dialog ;-).

No it isn't - C# is the black note between C natural and D natural.

Yes, sure it is. Go back to your piano and let us get some work done.

Show quoteHide quote

I don't know why you named Italy, but I'd *love* the situation to be as you
described; actually, there are lots of VB programmers here, and they're
often very bad ones who tought "hey, with VB I can make programs without
knowing anything at all about programming!".
Now, they got quite frustrated by this .NET thing, and tought again "sure
VB.NET is going to be a lot simpler than that C#, and I also already know
VB, so using it will be even simpler!".
And then, they got *even more* frustrated when they discovered that VB.NET
isn't actually *so* similar to VB 6 as they were expecting, and then
reverted back to VB 6. And their companies went with them, instead of firing
them at once.

This is definitely one of the strangest places to work in IT :-/


Massimo

I love Italy ! On top of that, I am a Roman Catholic . Though I never
realized that there are that many VBs overthere until you said so! So
ignorance I am !

John

Me too, I live here ;-)
The country is beaufitul, but the people... well... if you're a tourist
they're ok, but if you're trying to ever accomplish *anything*, this is
absolutely not the best place :-/
This is especially true for IT jobs... IT here was ruined by legions of
wanna-be programmers, technicians and sysadmins who bought "computer
programming for dummies" (or things like that) and then tried to get a job,
and stupid companies managed by people who don't even know what a computer
is but think they can get rich with them.

This always seemed strange to me... I can go to st. Peter's in 15 minutes,
and there are people from all over the world who only saw it in pictures
Yes, there are... and many of them are as I described above. If you saw a
RecordSet being used by one of them as I saw one, you would have wept over
that poor RecordSet's tragic fate :-(

Massimo

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

By the way: I prefer C#, but it's only a syntax thing.
I never used VB (altough I know something about it), but used C, C++ and
Java extensively... and I definitely prefer { and } over BEGIN and END.


Massimo

Massimo,


... and I definitely prefer { and } over BEGIN and END.

That was what I too was always thinking.

I see now large benefits from the seperated kinds of begin and ends in
Visual Basic.

A nested procedure 6 deep with only {} do I find already almost a crime.

In VBNet I have not seen the maximum of that and it stays still stays
readable.

Just my thought about this

Cor

A nested procedure with six depth levels is a crime anyway :-)

Massimo

"Massimo"
You wrote that you never tried VBNet. You should try that, you would not
believe your eyes when you see how nice that is arranged by the IDE and how
good readable your programs become by nesting something even 10 or 12  (or
more) deep.

Just my thougth

Cor

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.

Massimo

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

Cor

Cor Ligthert <notmyfirstn***@planet.nl> wrote:
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.

Jon,

Show quoteHide quoteI agree with you and probably will use in future your sample, which I to be
honest never thought of, however the difference is that it is at the moment
not automaticly done and as well not automaticly alligned direct when you
are busy.

However thanks for the idea

Cor

Jon,

It's actually 'Next', not 'End For' :-).

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

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

Show quoteHide quoteI 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.

Wilbur Slice <p*@papapapa.com> wrote:
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,
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

Cor Ligthert <notmyfirstn***@planet.nl> wrote:
But Visual C# does exactly that too, as I said in my previous post. It
basically formats the whole block that the brace ends.

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

Show quote Hide quote 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
"|" indicates the caret position after pressing the return key.

Herfried K. Wagner [MVP] <hirf-spam-me-here@gmx.at> wrote:
Show quoteHide quoteGiven 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...

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

Show quoteHide quoteIn 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...

Wilbur Slice <p*@papapapa.com> wrote:
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.

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.

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

Show quoteHide quoteI 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.

Wilbur Slice <p*@papapapa.com> wrote:
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 Fri, 1 Jul 2005 17:24:48 +0100, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

Show quoteHide quoteWell, 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.

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

Ah, but there's nothing stopping you from commenting your C# code
incorrectly either.  So, to use your example, you could have this...

Obviously, because the "end tag" is a comment, this misleading information
is not going to be caught by the compiler.  The advantage of the "End If"
and "Next" key words in VB is that these end tags are checked on-the-fly by
the IDE.  So, you can't run the code without the matching beginning and
ending tags.

Of course this comes down to personal preference.  You mention that there's
nothing stopping you from using comments to denote what kind of block the
right brace is terminating.  In my opinion, this good commenting practice
shouldn't be optional.  It should be part of the language itself (as in VB),
not left up to the individual programmer.  That's why I prefer the VB style
over the C# style.  In my book more information is always better than less
information, especially when we're talking only a few additional characters
that are inserted by the IDE most of the time anyway.

Regards,

- Mitchell S. Honnert




Show quoteHide quote

Show quote Hide quote The problem are not only blocks inside methods.  Imagine an explicit
namespace definition with class definitions, nested classes, properties and
only a single additional 'if' block inside the property's getter.  This
leads to six closing brackets.  When implementing a complex algorithm it
gets even worse (up to ten nesting levels in total).

\\\
namespace Foo
{
    public class Goo
    {
        public class Bar
        {
            public string Name
            {
                get
                {
                    if (...)
                    {
                        ...
                    }
                }
            }
        }
    }
}
///

I'm a humurous people, I am a developer, and I am not frustrated - but I
know C#.

- Sahil Malik [MVP]
Upcoming ADO.NET 2.0 book - http://tinyurl.com/9bync
----------------------------------------------------------------------------



Show quoteHide quote

Show quote Hide quote

this means nothing, think about it

stax

Knowing one is nearly to know the other. VB.Net is much closer to C# than it
is to VB "classic". I do agree with you that some people turn up their nose
at the mere mention of anything with "VB" in its name, but thats somewhat
showing their ignorance also. Best just to know both, and not so difficult
to slide across once you know one.

<cfmortgage***@yahoo.com> wrote in message
Show quoteHide quote

Languages are passe... Pimp the framework and the rest will fall into place.

Show quoteHide quote

Hi,

Seeing as noone seems to have touched the issues I find important ...

If you have no background in C/C++/Java or similar you may find VB.NET easier to understand simply because it has less symbols and more logical words.  If you have dabbled in C/C++/Java or similar you may find C# to be easier to do.

There are no real performance differences between C# and VB.NET. With a few minor exceptions they are each capable of doing the same things.

As Malik said, what takes time is learning to know the framework, which is identical for all .NET languages.  If you read the questions in these groups you will find that the answers in many cases are language independent, valid for both C# and VB.NET.  And in those cases that it is language dependent, translating it to the other language is a simple task.

Go with what you prefer, either is fine.

I have the same opinion: C# en VB.NET are really close. It just depends on
preferences.
I used to work in VB6, so VB.NET seemed the most logic thing to me. but if
you know VB.NET, you automaticly can work in C# too: it's the same syntax,
they just put it a little bit otherwise on the form, like this:
- VB.NET: "I am a programmer"
- C#: "{A programmer I am}"
One of the things I really dislike about C# is the fact that you have to put
al those {}{}{}{} :-)

news:op.ss2hf2vzklbvpo@stone...
easier to understand simply because it has less symbols and more logical
words.  If you have dabbled in C/C++/Java or similar you may find C# to be
easier to do.
few minor exceptions they are each capable of doing the same things.
identical for all .NET languages.  If you read the questions in these groups
you will find that the answers in many cases are language independent, valid
for both C# and VB.NET.  And in those cases that it is language dependent,
translating it to the other language is a simple task.
Show quoteHide quote

As a programmer in both, more VB.NET than Visual C#, I will echo some of
the sentiments and share my own.

Being that you are a novice programmer, it may be easier and faster for
you to start with VB.NET as opposed to C#. This curve is a bit dependent
on what tools you are using to learn with.

C#'s case dependence, bracketing, and lack of real human readable
keywords and syntax may make the transition a little longer than with
VB. The case issue was fixed in Whidbey with better Intellisense, so
this may not be an issue for you anymore... but there is something to be
said for being able to decipher how code blocks work when you are
looking at something like:

for Counter as integer = 0 to MyCollection.Count
....
next

versus

for (int Counter = 0; Counter < MyCollection.Count; Counter++)
{
}

It is less verbose, but does not convey terribly clearly what is happening.

That having been said... I can say that my usage of C# with VB.NET has
made me a much better programmer overall. Why? Because C# forces you in
some degree to pay attention to concise, clear code. This translates
well into VB.NET, despite the somewhat more verbose syntax.

Lastly, while totally undeserved, there is something to be said in the
community about being able to program in C# than VB.NET. I think part of
this is Microsoft's fault (I wont change the thread here by launching
into my reasons why I believe this), part is from the general perception
since the early VB days of it being a "toy" language.

My 2 cents, thrown in with the rest of the group.


Morten Wennevik wrote:
Show quoteHide quote

The programming language that's best for you is a function of where you come
from. As Morten so clearly said, if you come from the OO-style languages C#
will be more comfortable but there's also Managed C++ for those folks and J#
as well. VB.NET was originally designed to help VB6 developers transition to
..NET. That's because at the time almost 80% of developers used VB6. It has
evolved over time (and is still evolving) to help developer productivity.
You'll find more differences in the Visual Studio.NET IDE than anywhere
else. In the current versions (and more so in older versions) C# required
you to constantly rebuild your project to resolve addressing. C# is always
going to be case sensitive (which is a royal PITA) and pretty anal. Newer
versions of C# have included on-the-fly compilation (finally) and
edit-and-continue (unless they dropped it again)--but so does VB.NET (which
always did on-the-fly compilation). VB.NET also has a new "My" namespace to
vastly simplify some of the more convoluted framework references. But again,
they build virtually identical IL.

news:op.ss2hf2vzklbvpo@stone...
Show quoteHide quote

Hi,

I have seen a lot of discussion about this. Only one guy impressed me with
what and how he wrote about this subject.

http://groups-beta.google.com/group/microsoft.public.dotnet.general/msg/804482b9cce63bb7?hl=en

I hope this gives an idea.

Cor

put some c# source and some vb.net source side by side, have a good
look at them and choose the one where you like the look of the source
better.

(I was going to say 'flip a coin', but you wanted logic, and logic
tells me it would be better to work with the language you like the
looks of) :)

Sam

cfmortgage***@yahoo.com schrieb:
Show quoteHide quote

On Tue, 28 Jun 2005 00:37:51 GMT, cfmortgage***@yahoo.com wrote:


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

What did they say when you asked them why?


Paul
~~~~
Microsoft MVP (Visual Basic)

Obviously, the best solution is to use both languages (and J# also) and then
buy our converters to switch between them as often as possible.
;)

David Anton
www.tangiblesoftwaresolutions.com
Home of:
Instant C#: VB.NET to C# Converter
Instant VB: C# to VB.NET Converter
Instant J#: VB.NET to J# Converter

Show quoteHide quote

Show quote Hide quote

cfmortgage***@yahoo.com wrote:
The one thing that hasn't been mentioned, that I saw, is the direction that
Microsoft is pushing the languages towards in 2.0.  The last time I went to
a presentation on this, which was a while ago, each language had been given
a particular focus.

The focus for VB.Net in 2.0 was to be the rapid application development
platform.  They include the My.* heirarchy to allow for quick access to
various items... basically instant help.  I believe that it also had
slightly better support, in the development UI, for developing forms, but I
could be misremembering.

The focus for C# was on back end business processing.  As such it came with
facilities for assisting coding with standard Gang of Four patterns and the
ability to refactor code quite easily.

The focus for Managed C++ was for 'down and dirty' close to the framework,
fast as possible, type work.

Based on what you've said above, sounds like C# in 2.0 is better suited for
your likes and dislikes.  But that's just a guess.  And my recollection of
things may be off, as well as things may have changed.

All .Net languages are very similar because they ultimately produce the same
intermediate language and use the same application services. I have only
heard of (never experienced myself) a handful of capabilities in one that
doesn't exist in the other. That being said, each language is syntactically
different and has SUBTLE nuances that would be more appropriate to one
application or another. So if you really want to split hairs that is the
place to look.

You also may want to consider the possibility of if you will ever have to
look at legacy code. You might want the syntax you are familiar with to be
similar to what you are likely to encounter. Is it more likely to be C/C++
or VB?

Most serious commercial software and operating systems are written in C /
C++ with a little assembler thrown in.  Other proprietary software written
for business and engineering has been written in dozens of languages,
PASCAL, FORTRAN, COBOL, ADA, SMALL TALK, POWER BUILDER, DELPHI, to name a
few. Most Microsoft applications and technologies that provide for scripting
support VBA (Visual Basic for Applications) a form of VB.

When it comes down to it all languages let you do the same thing, create and
access data structures and control the flow of logic. It will boil down to a
personal preference. For me C / C++ has always been the coolest thing
around. C# is a natural extension of this. It brings a lot of the niceties
of the higher level language to the syntax that is familiar to me. I think
also C# is the favored language of those who created .Net which is always
something to consider. The older you get the harder it is to be cool. You
might as well get it while you can.



<cfmortgage***@yahoo.com> wrote in message
Show quoteHide quote

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. 


Show quoteHide quote

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.

Show quoteHide quote

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

Show quoteHide quote

Try C Omega from the Microsoft Research site.

Show quoteHide quote

cfmortgage***@yahoo.com wrote:
Show quoteHide quoteVB.NET has a lot of design decisions specifically made for beginners
like you.  Things like case-insensitivity, no semicolons or curly
braces, meaningful english words for keywords.  Download SharpDevelop,
a free .NET development environment, and you can start designing your
interface and programming your application right away.

I'm recommending VB.NET even though I'm trying to help make another
..NET/Mono language called boo the easiest for beginners.  It's still
not there yet.

@o13g2000cwo.googlegroups.com:
So are you saying that:
-case sensitivity
-The use of a single character, the semi colon
-The use of two characters, the curly braces
-The use of shorter and abbreviated words or symbols.

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

a.. C# code is also harder to "read". "Dim X as New SqlConnection()" is easier to read than "SqlConnection x = new SqlConnection();"
  b.. C# is anal. VB is forgiving.
  c.. Event declarations have to be made explicitly in C#.  In VB we simply code "Dim x WithEvents as Y" and the Event prototypes are exposed and built for us on demand.
  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.
  e.. In C# the "}" character ends all code blocks. In VB code blocks are delineated with End If, Next, Loop, End Sub, End Function etc. This makes code easier to read and debug as you can easily find the end of the code block.
  f.. Depending on the version, Visual Studio is far easier to work with when working with VB. As you work through your code, you can easily change variable names and not have to forcibly rebuild the code to verify that the names resolve as you must in C#. C# has improved in the 2005 version in this regard.
  g.. C# has caught up with VB.NET in that it will also offer edit and continue in the 2005 version. This is a tremendous productivity enhancement that radically changes the approach you must take as you develop applications.
Both C# and VB.NET produce virtually identical IL. The question you should ask when choosing a language (or a developer that uses one or the other) is "How much productivity do you want?". VB.NET developers have been shown to be more productive than C# types. The language and VS does more for them behind the scenes. Of course it can be said if you're a Java developer, transitioning to VB would be harder that C# but transitioning to J# might be even easier. If you're a C++ developer, you need to look at Managed C++--not C#.

Just my $.02.



Show quoteHide quote

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.

Chad Z. Hower aka Kudzu wrote:
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.

William (Bill) Vaughn <billvaRemoveT***@nwlink.com> wrote:
You may find the C# harder to read, but personally I find it easier. It
keeps the declaration separate from the

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.

And if you use that without knowing what's *really* going on (as I
suspect many developers do) you can get bitten by it - I answered a
question on that a month or so ago.

Again, I like to see problems early.

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.

It's still miles away from Eclipse's refactoring support,
unfortunately. <shrug>

Fortunately it won't change how *everyone* develops applications. I'm
firmly of the view that as little time as possible should be spent in a
debugger. As far as I'm concerned, if I have to go into the debugger
that means I've already failed to some extent - my unit tests either
haven't tested a sufficiently small block of code, or my code isn't
readable enough to make the error obvious just by inspection.

Do you have a reference to a study that shows that with a decent
methodology? I suspect there's hearsay about it both ways, and probably
biased studies both ways too.

Don't forget that there's a lot more to being productive than getting
functionality written quickly - to my mind it's more about getting
*high quality* code written quickly. That's where language constructs
such as the "using" statement in C# help, by making it easy to do the
right thing with streams etc.

It prevents subtle bugs like calling Sleep "on" a specific thread and
expecting it to make that thread sleep rather than the current thread -
C# would disallow that as Thread.Sleep is a static method.

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.

Jon Skeet [C# MVP] <sk***@pobox.com> wrote:
Oops - concentration slipped.

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?

Jon wrote:
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.

dou***@gmail.com <dou***@gmail.com> wrote:
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.

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.

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,

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.

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.
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.  In VB.NET, potential problems like this do not occur as often.

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.

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.

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.

Herfried K. Wagner [MVP] <hirf-spam-me-here@gmx.at> wrote:
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.)

In a very few cases - but not in many others.

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?

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?

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.

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

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?

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


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.

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

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.

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

\\\
foo.MdiPare***@SampleForm.Bla()
Dim x As IFooBar = goo.Bar.@IFooBar
///

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

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

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.

Show quoteHide quoteI 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?"...

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

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

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.

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.

Chad,

Show quoteHide quoteI 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 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.

ACK.

I agree.

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 aka Kudzu <c***@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.

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.

In article <MPG.1d3f8674e471533398c***@msnews.microsoft.com>, Jon Skeet [ C# MVP ] wrote:
Show quoteHide quoteI 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 <t**@YOUKNOWTHEDRILLmtogden.com> wrote:
Exactly - and those are the cases where I'd suggest breaking it up:

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

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

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


Willy.

Willy Denoyette [MVP] <willy.denoye***@telenet.be> wrote:
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();

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

Willy.

In article <OsWuHu#hFHA.1***@TK2MSFTNGP10.phx.gbl>, Willy Denoyette [MVP] wrote:
Show quoteHide quoteOh, 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.

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in news:MPG.1d3f8674e471533398c486
@msnews.microsoft.com:
In some cases, but its just another roach point. It allows bugs to creep in, and fairly frequently.

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

Chad Z. Hower aka Kudzu <c***@hower.org> wrote:
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 [C# MVP] <sk***@pobox.com> wrote in
If you dont separate it - which many dont.

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 aka Kudzu <c***@hower.org> wrote:
Ah, I see. I took your post to mean that the bugs would creep in if you
*did* separate the lines...

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 [C# MVP] <sk***@pobox.com> wrote in news:MPG.1d3fa68a908b4db398c493
@msnews.microsoft.com:
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 aka Kudzu <c***@hower.org> wrote:
While that's true of open source projects, it's *certainly* not true of
code posted here - usually the point of people posting code here is
because they've got problems they don't understand! If lots of people
were coming across these kinds of bugs and having problems with them,
I'd expect to see them on the groups - and I just don't.

Of course, I also see the code that my own team is working on - but I
wouldn't be surprised if the team I work with is more experienced than
average.

Jon Skeet [C# MVP] <sk***@pobox.com> wrote in
We certainly see a lot of begginer code here - but the simple stuff they figure out before posting.
But simple != frequent.

Id suggest that they are both more experienced thatn average - as well as having mostly C++
backgounds and long since ago learned not to do certain things. Its just like the type casting we just
discussed. :)

Also regarding the for loop - one reason its been lessened a LOT is because of foreach.

Herfried K. Wagner [MVP] <hirf-spam-me-here@gmx.at> wrote:
I think we'll have to agree to disagree.

And again, we'll have to disagree.

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

Show quoteHide quoteBut 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).

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

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

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

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?

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.

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

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

I have developed in a number of different languages, both MS and non-MS, I
personally like c# and found it rather easy to pick up.  I will say there are
some things that a bit easier to do in VB.net than c#, but overall they are
pretty similar.  The only warning I would give for a novice is that c# forces
you to be very.... exact.  Case sensitive and such, but that is where Visual
Studio is nice, it will let you know when you goof most of the time.

There are a number of resources for whatever you choose.  I would first
visit www.asp.net.   It has a number of tutorials and a free IDE you can
download to get started.  You can play around with a few different things and
see what you like.

From there, on the c# side of the world I have been happy with the Visual C#
..NET Step By Step book (ISBN: 0-7356-1909-3), it is a rather easy read and
covers some of the basic concepts.

I also like the Sams Teach Yourself books pretty well (don't flame me,
remember this is a beginner).  Not to mention there are a number of really
good blogs that cover some of the more difficult and harder to find things. 
I often search MSDN and google for things I need.

Having worked with other languages I have to say the MS community is one of
the best for helping others out and understanding that people aren't experts.
Good luck I hope this helps.

Ken I.
http://www.kicweb.com/blog

If you are a beginner, start always with paper&pencil and sketch in plain
language what your program is doing. Do not hesitate use your own symbolics -
arrows for loops.... You start with a single sheet, and some more compllex
tats you just describe as as a shortcut - instead of writing all details on
single sheet you just write: open file - process lines - close file; then you
might look to the new sheet of paper, title it: process lines and write
another piece of program. This is called decomposition.
If you are able to do this on paper - you will find that this is core
programming task (sometimes called decomposition or top to bottom desing) and
your quetsion VB/C#/Delphi/Java/T-SQL will become obsolete.
I like C# since it is not overly verbose, but when you have clear idea,
maybe some sketches on paper IT DOES NOT MATTER WHICH LAGUEAGE YOU CHOOSE !
Just last recommendation: If make a choice - stay with it because changing
languages too often is usually exhausting (like changing favorite graphical
editor - you know what you want to do - but where is this command in menu ?).

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.

Show quoteHide quote

SpikeTool <SpikeT***@discussions.microsoft.com> wrote:
Show quoteHide quoteYou 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 [C# MVP] <sk***@pobox.com> wrote in
They are significantly different. C# is much closer to C++, and even then quite different.

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

Show quoteHide quote

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

Well so many posts on this thread and i liked it.  My opinions at your
disposal.

While working in C in Unix, i found F2 and shift+F2 key shortcuts to take
you to matching braces.  Isn't it a very great feature?

Sure the Shift+F2 and Ctrl+Shift+F2 shortcuts must be available in c# too to
take you to definitions...

After getting #pragma in VB and me too started testing my very old assembly
language in VB.NET, VB.NET has pyscological upper hand over c# or c++ or c.

I've written so many machine controls apps, finance apps, inventory, sales,
hr, etc applications in VB and RPG/400.  Ofcourse have written few serious
programming in c# also.

But personally i feel one very small syntax miss in c# will cost more time
than VB.NET to figure out.  VB.NET might show Cobol like too many errors but
takes lesser time to sort out than c#.

From program management point of view a c# expert will naturally take more
years than a VB.NET to become one.  So naturally cheaper VB.NET experts are
available than c# experts.  Cheaper the overall project cost!!!

Take a survey among 15 years experienced VB expert and 15 years experienced
c expert.  VB expert would have faced more real life scenarios and
implemented more real business applications than a c expert. (exceptions are
very few!!!)

Now more of DB2 also coming into Visual studio debugging like SQL Business
intelligence studio, i've seen more VB experts than any c# experts.

Hopefully Anders Hejlsberg will even out VB.NET and c#.NET in terms of
keywords.  Practically it is upto the experience the developers build in each
language which makes a language prominent.  Not because european bosses like
it or not.
Show quoteHide quote

I hardly expect that to happen.  If it did, we'd just have one language,
which is not what MS is trying to do by putting one person in charge of both
the C# and the VB .NET code paths.  You CAN expect the feature sets between
the two languages to even out going forward (ie. XML as a first class data
type in VB .NET but not C# and C# indexers but not in VB .NET), but don't
expect the keyword to necessarially be the same.

-Scott

How to compare objects using their typecode
"Handles" Question
SortedList question
Registry Key Permissions
vb.net Threading Question
C# supports pointer.
Circular References...
Accessing dlls from gac
detect mouse leaves control
Strong naming