Beating a dead Horse: Which Language

[Chad Z. Hower aka Kudzu]

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.

 

[Jon Skeet [C# MVP]]

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

 

[Willy Denoyette [MVP]]

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]

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.

 

[Tom Shelton]

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.

 

[Jon Skeet [C# MVP]]

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

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>

 

[Chad Z. Hower aka Kudzu]

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.

 

[Jon Skeet [C# MVP]]

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.

 

[Chad Z. Hower aka Kudzu]

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.

 

[Guest]

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

 

[Chad Z. Hower aka Kudzu]

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

 

[Guest]

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

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?

 

[Guest]

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.

 

[Raja Venkatesh]

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.

 

[Scott M.]

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.

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