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!

[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

[Jon Skeet [C# MVP]]

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

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.

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 - <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:MP************************@msnews.microsoft.c om:

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.
We certainly see a lot of begginer code here - but the simple stuff they figure out before posting.
But simple != frequent.
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.

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

[Pazu]

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

[Scott H]

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

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

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.

[Jon Skeet [C# MVP]]

<"=?Utf-8?B?U2NvdHQgSA==?=" <Scott [e-mail]>>
wrote:

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

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.

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?

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

[Scott H]

"Jon Skeet [C# MVP]" wrote:

Scott [e-mail]> wrote:

For instance, VB.Net can't have a function that returns a value by
reference, which has burned me at least once.

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

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.

[Chad Z. Hower aka Kudzu]

Also regarding the for loop - one reason its been lessened a LOT is because of foreach.
--
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