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!

[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