Which .net language ?

[Jonathan]

I know this question may have been asked many times before, but I have
never used any Microsoft languages in the past and have always worked
on Unix shell, Awk, Progress 4GL/RDBMS, Paradox ObjectPAL and
Powerbuilder 6.5 and 7 for the last few years.

But I am still unsure which .Net language to choose to learn, has
anyone else moved over to .Net from a similar environment/background
to mine and which language did you choose?

Regards
Jonathan

 

[Cor]

Hi Jonathan,

Look to yourself, do you want to make very strict code, more mathimatical
than describing and you know from yourself that you write always good code
and make no typos or whatever errors.
Choose C#

Are you not that strict and you do make often typos or whatever and you do
also like that your code itself is a little bit describing.
Choose VB.net

There are more points, but in my opinion the most important thing is your
own way of thinking that lets you feel better with the one than with the
other.

If a program is good written, than the code result from both languages is
the same.

Cor

 

[Jon Skeet [C# MVP]]

Look to yourself, do you want to make very strict code, more mathimatical
than describing and you know from yourself that you write always good code
and make no typos or whatever errors.
Choose C#

Are you not that strict and you do make often typos or whatever and you do
also like that your code itself is a little bit describing.
Choose VB.net

That sounds like you can only write in C# if you're already perfect.
It's not that way at all - it's a case of whether you want your code to
be able to end up with typos *after* you've got it to successfully
compile.

It's not like C# means you end up with applications that are fault-
intolerant (i.e. you'd better not have made any errors) - it's just
that the compiler is more picky.

 

[Cor]

Hi Jon,

That sounds like you can only write in C# if you're already perfect.
It's not that way at all - it's a case of whether you want your code to
be able to end up with typos *after* you've got it to successfully
compile.

It's not like C# means you end up with applications that are fault-
intolerant (i.e. you'd better not have made any errors) - it's just
that the compiler is more picky.

I am not so strict, I think you know that already. Maybe therefore I did not
write it as strict as it should be.

However the compiler is the same for both, it is only things as that you get
your error messages with VB.net while typing also and you do not have to
look at the case, because that is direct corrected for you.

And in future you can even correct things with VB while debugging. (Before
you start this is an option that is for me also overdone, but not something
that I say that it should not be there, that is something you never saw me
say).

By the way, what is your favorite, C# or VB.net

)))

Cor

 

[James J]

Dear Cor,

Edit and continue would sure be a big help to me. Often
I find that it is a tedious and lengthy procedure to get
to where the problem occurs. Making a small change and
testing to see if it works takes a lot of time. It would
be very time saving if I could just make the change like
we used to be able to do and then immediately test it.
Better yet, test it in the Immediate window to see if it
works and then make the change in the code itself. I am
a big fan of that. You can already do that in C#, but
not yet in VB. I would sure like to have it.

James J.

 

[Jon Skeet [C# MVP]]

Edit and continue would sure be a big help to me. Often
I find that it is a tedious and lengthy procedure to get
to where the problem occurs. Making a small change and
testing to see if it works takes a lot of time. It would
be very time saving if I could just make the change like
we used to be able to do and then immediately test it.
Better yet, test it in the Immediate window to see if it
works and then make the change in the code itself. I am
a big fan of that. You can already do that in C#, but
not yet in VB. I would sure like to have it.

Um, no - C# *doesn't* have edit and continue. You can't change the code
once it's running.

Personally I don't find this a hardship, and I don't like the "tinker
until it works" style of coding that E&C can (doesn't always, but can)
encourage. I prefer unit testing as a way of finding problems quickly.

 

[Peter van der Goes]

I know this question may have been asked many times before, but I have
never used any Microsoft languages in the past and have always worked
on Unix shell, Awk, Progress 4GL/RDBMS, Paradox ObjectPAL and
Powerbuilder 6.5 and 7 for the last few years.

But I am still unsure which .Net language to choose to learn, has
anyone else moved over to .Net from a similar environment/background
to mine and which language did you choose?

Regards
Jonathan

Here's a slightly different view. C# has C-like syntax while VB has,
well..., BASIC-like syntax. If you're comfortable in C, I'd suggest you try
C#. I don't know that PowerBuilder or ObjectPAL code looks like, so you'll
have to decide on similarities. Performance and complexity are not really
discriminators here, IMHO, as both use the .NET Framework classes.
Just a thought.

 

[Jeremy Todd]

Hi Jonathan,

Look to yourself, do you want to make very strict code, more
mathimatical than describing and you know from yourself that
you write always good code and make no typos or whatever errors.
Choose C#

Are you not that strict and you do make often typos or whatever
and you do also like that your code itself is a little bit
describing. Choose VB.net

Unfortunately, there's more to it than just the style of the languages.
There are some things you can do in C# that you just can't do in VB, and
vice versa. For example, VB allows you to have a method with any scope and
name implement an interface member (the famous example being "Close"
implementing IDisposable.Dispose). It also features automagical event
binding with the Handles keyword, which eliminates a lot of error-prone
bookkeeping.

On the other hand, it's been announced that C# will feature generics in
Whidbey, which is something I would really, really like. Edit-and-continue
I don't care so much about. I don't miss it.

Up until recently, the built-in XML commenting feature in C# was a big
deal, but now there are add-ins that will do the same in VB. VB's pointing
out compiler errors in real time is a huge plus for me, too.

Stylistically, I would prefer to use C# (to say nothing of the fact that
C# programmers get paid more), but VB seems to implement more of the CLR
features I want at this time. That may change with Whidbey/Longhorn; we'll
see.

Jeremy

 

[Bryan Dickerson]

VS.Net 2003 has the Edit and Continue back in it... I think. I haven't
tried it yet, but I'm pretty sure that there was enough clamor when the
first edition of VS.N came out that they put it back in for 2003.

 

[Jonathan]

Here's a slightly different view. C# has C-like syntax while VB has,
well..., BASIC-like syntax. If you're comfortable in C, I'd suggest you try
C#. I don't know that PowerBuilder or ObjectPAL code looks like, so you'll
have to decide on similarities. Performance and complexity are not really
discriminators here, IMHO, as both use the .NET Framework classes.
Just a thought.

Many thanks for the comments, they have been useful. The language
style syntax I have used has been more english like than C but looking
at picking C/C++, Java has always interested me just needed a reason
to do something with them and make it worthwhile. I now have a small
project for home/family which I would like to use as my first project
using .Net

From the various material I have seen so far, I think C# will be my
favoured option, partly because this looks familier to what I started
looking at last year and I want to leave some of the old baggage that
I had previously learnt (i.e. Powerbuilder etc.) behind.

Regards
Jonathan

 

[Daniel O'Connell [C# MVP]]

Unfortunately, there's more to it than just the style of the languages.
There are some things you can do in C# that you just can't do in VB, and
vice versa. For example, VB allows you to have a method with any scope
and
name implement an interface member (the famous example being "Close"
implementing IDisposable.Dispose). It also features automagical event
binding with the Handles keyword, which eliminates a lot of error-prone
bookkeeping.

Both of these I personally dislike. It makes little difference to me if I
have to locate all methods that reference an event to remove the event
binding(I assume handles is capable of that, at any rate) or if I have to
locate the one method inwhich I do my code-time local bindings, its pretty
likely going to be the same amount of work. As for renaming interface
methods...that just seems to me to be a very undesirable choice to make, if
for no reason other than to ease up on confusing the next coder working on
the project or someone who inherits from the class. IDisposable.Dispose is
named Dispose, not Close.

On the other hand, it's been announced that C# will feature generics in
Whidbey, which is something I would really, really like.
Edit-and-continue
I don't care so much about. I don't miss it.

VB will have generics as well(syntax, last I heard was Class X(Of String),
along with partial classes. Generics would lose alot of their thunder if VB
& MC++ didn't support them. The primary distinguishing features in C#, as I
understand it, are anonymous methods and iterators, plus a couple other
little bits(fixed sized struct members, global namespace operator, another
thing or two I can't remember right now, I also don't know if VB is gaining
the same features or not).

Up until recently, the built-in XML commenting feature in C# was a big
deal, but now there are add-ins that will do the same in VB. VB's
pointing
out compiler errors in real time is a huge plus for me, too.

XML comments are expected in whidby for both VB & MC++ I think, not entirely
sure on MC++.

 

[Jon Skeet [C# MVP]]

When I use edit and continue the problem is not finding the error,
the problem is fixing it. I don't see a problem with tinkering with a
segment of code to get it to work. What is problem with that? Unit
testing identifies a problem, but I already know I have a problem. I
don't understand what you are saying.

If you tinker with code at the point you notice it's broken, you don't
know what else your change will do - the same code could already have
been called several times, and your change could well have broken what
happened previously. You end up appearing to fix the error, but not
actually doing so.

A good regimen of unit testing allows you to quickly find problems, and
there's no need to use edit and continue as rerunning the test should
be a quick thing to do. (Most people seem to want E&C so that they can
verify their fix quickly.)

 

[Stu Smith]

Yikes, I'm glad you're not on my dev team. If you're fixing a bug, you
either see where the code is going wrong, and fix it (hopefully one change),
or you don't understand why the code is going wrong, in which case you find
out why /before/ you make any further changes to the code. "Tinkering"
sounds like you're changing buggy code that you don't understand into
might-be-bug-free-I-have-no-idea code, that you still don't understand.

Dear Jon,

When I use edit and continue the problem is not finding the error, the

problem is fixing it. I don't see a problem with tinkering with a segment
of code to get it to work. What is problem with that? Unit testing
identifies a problem, but I already know I have a problem. I don't
understand what you are saying.