moving from vb.net to c#

[Leo Muller]

I always thought that moving from VB.NET to C# would be very easy. Even
though so far it hasn't been hard, there are some annoying things, that may
have to do with my visual studio settings.

- When I type "system." the intellisense doesn't comlete this, only if I
write it with a capital S, rather annoying...
- is the type "string" or "String", both get excepted, but only "string"
gets marked in blue, while all examples use "String"
- Methods need () and properties need [], and all methods need (), can't the
editor add this automatically?
- There is a whole bunch of basic functions missing, such as "Replace",
"Ctype", etc. Are these anywhere else?
- Why doesn't the editor auto indent at the end of a line?
- Why oh why can't the editor add the end ";" by itself.
- Compile errors only show after compiling. After finding errors with
compilation, these errors are marked, but when fixed, the same mark stays,
until compiled again.

So far things work fine with C#, but as far as I can see, VB is much sharper
;-), VB lets me focus on the design, while C# gets me back to focussing on
the syntax details.

Any ideas for improving my C# environment are welcome!

Leo

 

[Brock Allen]

- When I type "system." the intellisense doesn't comlete this, only if

I write it with a capital S, rather annoying...

C# is a case sensitive language

- is the type "string" or "String", both get excepted, but only
"string"
gets marked in blue, while all examples use "String"

string is a language mapping onto the runtime datatype String. They are equivalent
and both correct.

- Methods need () and properties need [], and all methods need (),
can't the editor add this automatically?

I suppose it's possible. You can give feedback to the products teams here:

http://lab.msdn.microsoft.com/productfeedback/

- There is a whole bunch of basic functions missing, such as
"Replace", "Ctype", etc. Are these anywhere else?

String.Replace is there. CType is the casting syntax. It exists in C# as
well via the parentheses syntax:

double d = 5.5;
int x = (int)d;

- Why doesn't the editor auto indent at the end of a line?

This is a VS.NET setting. Check the Tools Menu under Options, then find the
language settings for C#.

- Why oh why can't the editor add the end ";" by itself.

You're the programmer, not the editor. There are some things you need to
delineate yourself.

- Compile errors only show after compiling. After finding errors with
compilation, these errors are marked, but when fixed, the same mark
stays, until compiled again.

This is an annoyance in the C# editor, yes.

Any ideas for improving my C# environment are welcome!

I'd suggest picking up a basic C# book, as some of your questions should
be answered. Also, the C# spec makes for some good reading also:

http://msdn.microsoft.com/vcsharp/team/language/default.aspx

 

[Kevin Spencer]

So far things work fine with C#, but as far as I can see, VB is much

sharper ;-), VB lets me focus on the design, while C# gets me back to
focussing on the syntax details.

Welcome to the world of "real" programming. Now, by that I don't mean that
you can't write a "real" program using VB.Net. You certainly can. However,
VB has always babied the developer (and probably always will). It hides
things that Microsoft doesn't want apprentice developers to worry their
pretty little heads about. IMHO, it does more damage by this than good. And
that, like any other opinion, is worth what you paid for it.

Of course C# is case-sensitive. The character 'a' and the character 'A' have
2 entirely different numeric values. VB.Net hides this from you by handling
case at a lower level without you having to worry your pretty little head
about it. Now, I can appreciate the fact that the C# IDE isn't as easy to
use because of this. It might be nice if you had an option in VS.Net to turn
case-sensitivity off. But C developers have developed a methodology over the
years that uses case-sensitivity to discriminate between, for example,
private and public fields and properties. Other than case, the names are the
same. So, making the IDE for C# case-insensitive would be anathema to most
C/C++ developers, and some existing code would break if compiled with this
setting.

Methods and properties need the punctuation that you specified. Here is
another case where the compiler handles things behind the scene. In fact,
there is no such thing as a Sub. A Sub is a Function that returns null. If
the Sub takes no parameters, VB.Net will happily let you omit them (the
parentheses). C# will not. Why? Because C programmers are not used to and
don't like being babied. They like to be in control, know as much about what
their app is doing as possible. They like to take responsibility for their
code.

Those "missing functions" you mentioned can all be found in the
Microsoft.VisualBasic namespace. But before you go trying to use them,
remind yourself that they are mere wrappers for other functionality in the
CLR. They were put there for the convenience of VB programmers. VB
programmers are used to using these functions. Rather than take them away,
Microsoft simply changed their back end.

As to why the editor doesn't do a whole lot of work for you, well, again,
that's the style of the developers who use the code. It's important to
remember that C (not C#) developers and VB (not VB.Net) developers come from
entirely different backgrounds. C is the lowest-level programming language
above Assembler. For this reason, it is also the most powerful and
extensible language ever developed. And for this reason, it is also the most
concise and cryptic in terms of syntax. It was written with power in mind,
not readability. To use C, one must have a fairly intimate acquaintance with
how the computer works, how memory works, how the processor works, etc. VB
on the other hand, was written for a differrent purpose. It was written both
as an instructive language for beginners, and as a quick prototyping
language. IOW, one could throw together a quick prototype in VB, and write
the actual app in some flavor of C. Somewhere along the lines, this original
purpose was forgotten or overlooked, and VB became an intensely popular
language for writing fairly simple business applications. Microsoft has been
scrambling for years to make VB as powerful as the apps it was being written
for demanded of it.

VB.Net is pretty close to the ultimate goal of making VB.Net a "real world"
programming language. But now we have 2 sets of developers, used to coding
in different ways, and used to their existing syntax. We also have projects
written in earlier native machine code that must be migrated to .Net. So,
Microsoft made VB developers feel right at home with VB.Net, and C#
developers right at home with C#.

Your only real issue is that you're not used to it. I can't tell you how
many developers I know who made the switch and would never dream of going
back to VB.

Now, for those of you (like Steve Orr) who are quite happy with VB.Net, and
are good developers as well, let me clarify that I am NOT putting VB.Net
down in any sense of the word. As I mentioned before, it is nearly as
powerful, and arguably easier to develop with than C# (at least if you don't
come from a C background). I'm just trying to put things in perspective here
with regards to history, and how we got where we're at now.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

I always thought that moving from VB.NET to C# would be very easy. Even
though so far it hasn't been hard, there are some annoying things, that may
have to do with my visual studio settings.

- When I type "system." the intellisense doesn't comlete this, only if I
write it with a capital S, rather annoying...
- is the type "string" or "String", both get excepted, but only "string"
gets marked in blue, while all examples use "String"
- Methods need () and properties need [], and all methods need (), can't
the editor add this automatically?
- There is a whole bunch of basic functions missing, such as "Replace",
"Ctype", etc. Are these anywhere else?
- Why doesn't the editor auto indent at the end of a line?
- Why oh why can't the editor add the end ";" by itself.
- Compile errors only show after compiling. After finding errors with
compilation, these errors are marked, but when fixed, the same mark stays,
until compiled again.

So far things work fine with C#, but as far as I can see, VB is much
sharper ;-), VB lets me focus on the design, while C# gets me back to
focussing on the syntax details.

Any ideas for improving my C# environment are welcome!

Leo

 

[dgk]

Welcome to the world of "real" programming. Now, by that I don't mean that
you can't write a "real" program using VB.Net. You certainly can. However,
VB has always babied the developer (and probably always will). It hides
things that Microsoft doesn't want apprentice developers to worry their
pretty little heads about. IMHO, it does more damage by this than good. And
that, like any other opinion, is worth what you paid for it. ....
Now, for those of you (like Steve Orr) who are quite happy with VB.Net, and
are good developers as well, let me clarify that I am NOT putting VB.Net
down in any sense of the word. As I mentioned before, it is nearly as
powerful, and arguably easier to develop with than C# (at least if you don't
come from a C background). I'm just trying to put things in perspective here
with regards to history, and how we got where we're at now.

Why not just code in Assembler then? All that power and no babying.

 

[Kevin Spencer]

Why not just code in Assembler then? All that power and no babying.

Do you have fifty years to write an application? Neither do I. This remark
lacks logic, the bedrock of good programmming.

Truth = Argument - Rhetoric

The problem with VB is that it doesn't require the developer to know much of
anything except syntax, and it even fixes that up. It is too easy, in a
sense. And let me clarify that statement: It is not something innately wrong
with VB. Anyone with self-discipline can program using any language.
However, it takes a lot less self-discipline and knowledge to get rolling
with VB.

Learning to program with VB is like joining the army and in Basic Training
you have the option to do the hard stuff or not. If you don't, you come out
of basic training a wimp, and useless to the military. If you have
self-discipline, and take it upon yourself to do all the necessary training,
you come out a soldier.

Learning to program with any C language is like joining the army and not
having any choice about what you are going to do in Basic Training. Everyone
has to do everything. You either come out a soldier, or you fail out.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[dgk]

Do you have fifty years to write an application? Neither do I. This remark
lacks logic, the bedrock of good programmming.

Truth = Argument - Rhetoric

Not so, it is quite logical. The remark was pointing out that you lose
power by accepting any hand holding, so we aren't talking absolutes
here, we are merely talking degree. The absolute is coding in
assembler using notepad. In fact, anyone who hasn't programmed in
assembler, and that includes C programmers, really doesn't know what
is going on under the covers. AX or bust I say. I'm not even going to
mention coding directly in IL as an option.

We're talking tools and language really. Should I not use Visual
Studio because it holds my hand and separates the design from the code
behind? Should I write it using the ASP Matrix because that gives me a
better idea of what is going on? Is intellisense bad because I don't
have to keep referring to a schematic of my object in order to
remember the name of the property? So why should I accept a complier
that needs me to tell it where a statement ends?

I remember when (too long ago) a Cobol compiler complained that I was
missing a period, and I remember thinking, well you're the computer,
fix it.

I just was arguing with someone who prefers coding in HTML and
Javascript to using ASP.Net. He wants the power he gets writing it
directly, whereas I like the ability to, well, you know why I like
ASPNET. And I'm an ASPNET newbie. I called him a Luddite and compared
it to wanting to code in Assembler once Fortran was available. And
(I'm not that old) I bet there WERE programmers who were upset.

Your argument, that VB is too easy and encourages sloppiness, isn't
true anymore and it never really was true. The complaint was really
that dropping boxes onto a form and setting a label to "Hello World"
wasn't real programming. Real programmers wrote it all by hand. Now
you're all doing the same thing and need something else to complain
about with VB. What else was it that folks complained about with VB?
Oh yes, it had that stupid run time; it couldn't even produce real
EXEs. Now, of course, it's called a Virtual Machine and all the best
languages are wearing them. We now call it "The Framework".

I was at VSLive last year and Shaw was denigrating VB by saying how
the C# team was pushing for generics and the VB team wanted edit and
continue but was going to get generics also because they were
embarrassed not to have generics. Well, which one is going to make me
more productive? I say edit and continue. Of course, both are in the
Framework so even C# gets edit and continue. Perhaps you can turn it
off so as to remain pure?

-------------------------------------------

By the way, I do want to tell you that I have already learned a great
deal by reading your postings. I'm assembling a compilation of all the
tips and tricks that I've already learned from just a few weeks in
this newsgroup and several are from you. Thank you for the time that
you spend helping folks. Hopefully I'll be at that level sooner or
later.

Dave

 

[Kevin Spencer]

Hi Dave,

By the way, I do want to tell you that I have already learned a great
deal by reading your postings. I'm assembling a compilation of all the
tips and tricks that I've already learned from just a few weeks in
this newsgroup and several are from you. Thank you for the time that
you spend helping folks. Hopefully I'll be at that level sooner or
later.

Why, that is one of the kindest remarks I've heard directed towards myself
in a long time (except from my wife, of course!). Thank you!

Let me see if I can explain my remarks better. You seem to be mixing my
metaphors. The remarks about babying were in reference to the fact that the
VB language hides a lot from the developer and allows for and automatically
corrects many errors. Case-insensitivity is an example of this. Of course,
the words Foo and foo are not the same. Not to the computer. The case
difference gives the numeric value of 'F' a completely different value than
'f'. The VB compiler fixes all of this. Is that a bad thing? No. On the
other hand, if one is learning programming, and one has never had to deal
with the numeric values of characters, it would be quite easy for one to
become a VB programmer without ever knowing exactly what a character IS, or
how the computer reads it. Now, how important is that? Well, in many cases,
it doesn't make a lick of difference. But try parsing character data out of
a binary file and see how far you get.

In other words, my point was that VB makes it too easy to "make it work"
without the developer knowing much of anything about WHY. And it is the WHYs
that give us the power to do more. I see every day on this newsgroup many
people who don't even care about the WHY of what they're doing. All they
want is some code to get them over this particular hump. And when they have
finished the project, they are no better at what they do than they were
before they started. And in a few days they're back here with their
proverbial hand out, looking for the next snippet to get them over the next
hump. An endless cycle of need.

Why is it that we demand knowledge of our lawyers, doctors, scientists, and
other professionals who do technical work, but as long as a programmer can
"get over the next hump" they are considered a professional developer? I
can't tell you how much nightmare code I've had to work on over the years,
or how much money it cost the companies I worked for to be so short-sighted.
Building an application is like building a building. The criteria for its
quality is not limited to whether it looks good on the day you buy it. The
criteria for its quality is how it looks 5, 10, or more years AFTER you buy
it. Software is seldom "finished." It evolves. It goes through cycles of
development and release, and God help those who have to extend a
poorly-written application. And God help those who have to pay them for it.

So, I'm not putting VB.Net down by any means. I'm simply lamenting the fact
that people can "get over" with it easily if they want to, and that human
nature being what it is, many want to.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[dgk]

Hi Dave,


Why, that is one of the kindest remarks I've heard directed towards myself
in a long time (except from my wife, of course!). Thank you!

Let me see if I can explain my remarks better. You seem to be mixing my
metaphors. The remarks about babying were in reference to the fact that the
VB language hides a lot from the developer and allows for and automatically
corrects many errors. Case-insensitivity is an example of this. Of course,
the words Foo and foo are not the same. Not to the computer. The case
difference gives the numeric value of 'F' a completely different value than
'f'. The VB compiler fixes all of this. Is that a bad thing? No. On the
other hand, if one is learning programming, and one has never had to deal
with the numeric values of characters, it would be quite easy for one to
become a VB programmer without ever knowing exactly what a character IS, or
how the computer reads it. Now, how important is that? Well, in many cases,
it doesn't make a lick of difference. But try parsing character data out of
a binary file and see how far you get.

In other words, my point was that VB makes it too easy to "make it work"
without the developer knowing much of anything about WHY. And it is the WHYs
that give us the power to do more. I see every day on this newsgroup many
people who don't even care about the WHY of what they're doing. All they
want is some code to get them over this particular hump. And when they have
finished the project, they are no better at what they do than they were
before they started. And in a few days they're back here with their
proverbial hand out, looking for the next snippet to get them over the next
hump. An endless cycle of need.

Why is it that we demand knowledge of our lawyers, doctors, scientists, and
other professionals who do technical work, but as long as a programmer can
"get over the next hump" they are considered a professional developer? I
can't tell you how much nightmare code I've had to work on over the years,
or how much money it cost the companies I worked for to be so short-sighted.
Building an application is like building a building. The criteria for its
quality is not limited to whether it looks good on the day you buy it. The
criteria for its quality is how it looks 5, 10, or more years AFTER you buy
it. Software is seldom "finished." It evolves. It goes through cycles of
development and release, and God help those who have to extend a
poorly-written application. And God help those who have to pay them for it.

So, I'm not putting VB.Net down by any means. I'm simply lamenting the fact
that people can "get over" with it easily if they want to, and that human
nature being what it is, many want to.

Oh, well that's ok then. I thought that you were insulting my favorite
programming language.

The reason I get pissed when folks insult VB (programmers) is perhaps
the very reason that Leo is looking to change to C#. He never stated
it but it's sort of obvious that he wasn't too happy about changing. I
can guess. It's because he can make more money as a C# programmer,
because, after all, everyone knows that they're better. Not <> != '=
necessarily.

I think that .Net has removed, for now, the ability for anyone to just
jump in and write programs in any language. Particularly if you aren't
using VS. I think that we need to touch on the MY object.

I'm withholding judgement on MY. As I understand it, and I have not
been trying 2005 yet, it delivers the functionality of the Framework
without needing to actually know where the classes exist nor even the
"correct" syntax. Somehow I don't think that you're going to be a fan.

On the one hand it organizes the classes logically rather than having
to hunt through the framework to find what you need, and thus allows
me to accomplish my goal quicker. But it does push me further from the
actual framework itself. Not performance-wise since it is really the
same code down below. I think that it will make good programmers more
productive but it opens up the door for folks really not understanding
what is happening. Oh well, this is another topic. Do we really still
need to know about registers?

Now I have an issue with cross-browser stuff. If I can't find it
myself, I'll ask about it. I saw something about browserCaps...

 

[Kevin Spencer]

Hi Dave,

Thanks for understanding. You may have noticed that earlier today I
recommended NOT migrating a VB.Net to C#, as there was no requirement that
dictated it, and it would have cost the company more money to do so. So, I'm
not a religious fanatic about languages. Still, I think it is useful to talk
about the strengths and weaknesses of a given language or technology,
wihtout having to be emotional about it. Facts exist, whether we recognize
them or not. And facts are the basis of good decision-making, NOT opinions.
And every programming language/technology has strengths and weaknesses,
which we should always be aware of.

I think that we need to touch on the MY object.

You just lost me. What does the acronym (I presume it's an acronym) 'Y'
stand for?

At this point all I can say is, nobody touches MY object, except for me and
my wife! ;-)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.

 

[Matt Berther]

Hello Kevin,

My is a new namespace coming forth for VB.NET programmers in the Whidbey
builds. It provides a common entry point for things.

ie: My.Computer, My.Network, My.Printers... Think of it is a facade over
some commonly used BCL classes.

 

[Kevin Spencer]

Thanks Matt. I'll research it.

I have Visual Studio 2005, but have not had the time to "play" with it. I
had to install it for a project we are working on that uses Indigo, but
that's all I've had time for so far.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
What You Seek Is What You Get.