using classes vs. modules

[Harald M. Genauck]

A couple a reasons I can think of are that you only have to remember
the private constructor in 1 place vs potentially hundreds or
thousands of places where you need to qualify the module name.

Oh, that might depend on how many 'faked' static classes you have to
create.

Second reason is that a shared function forces developers to qualify
the function name. If you want to qualify the function then having a
built in method that forces developers to do it the correct way is a
*really* good thing (tm). THis is especially true in a team
environment.

There are many things a especially team developers might or should be
forced to. Not so many are built in, even not in other environments
than VB.NET.

But you still use redim in some places?

For e.g.: When converting some C# code to VB.NET code it was easier to
'redim preserve' an array than to convert the C# author's
copy-one-array-to-another code.

Oh ok, it misread your post. You do need to add a reference to some
library with the name VisualBasic in it I suspect? I can't see a lot
of C# developers doing this. )

Ok, you might reference one or some of all the many other libraries out
there in the net that are providing some or many of the My namespace
features, if you don't want to write all the stuff yourself into an own
library. You might ending up adding a few more than only one
reference, but, that really doesn't matter.


Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de
"ABOUT Visual Basic" - http://www.aboutvb.de

 

[Michael C]

Oh, that might depend on how many 'faked' static classes you have to
create.

Generally there are few static classes and many functions. BTW, they are not
really fake as a static class is really just a class that you cannot create.

There are many things a especially team developers might or should be
forced to. Not so many are built in, even not in other environments than
VB.NET.

So what you're saying is we can't control everything so why bother trying to
control anything?

For e.g.: When converting some C# code to VB.NET code it was easier to
'redim preserve' an array than to convert the C# author's
copy-one-array-to-another code.

So you're telling me you never use redim preserve otherwise?

Michael

 

[Cor Ligthert[MVP]]

http://msmvps.com/blogs/bill/archive/2009/02/02/iterators-in-vb-10.aspx

 

[Michael C]

http://msmvps.com/blogs/bill/archive/2009/02/02/iterators-in-vb-10.aspx

Not a bad solution but isn't VB meant to be easier to use, not more
difficult?

Michael

 

[Harald M. Genauck]

Generally there are few static classes and many functions. BTW, they
are not really fake as a static class is really just a class that you
cannot create.

A module is a class that you cannot create. A shared class with a
manually implemented private constructor is a fake of a static class.

So what you're saying is we can't control everything so why bother
trying to control anything?

First comes the appropriate usage of elements of a language or
framework. Second is a developer's discipline who should be knowing
always what he is doing. And there are some thirds, fourths etc.
concerning the tasks and their requirements to solve. And just one of
the last, or even the almost last, member(s) of this chain is some
additional support for developer's behaviors.

So you're telling me you never use redim preserve otherwise?

Should I? Have I to do so, because I am a VB.NET developer, grown up
from old VB?
;-)

Ok, because I am grown up from old VB, sometimes it belongs to my tasks
to migrate old VB code to VB.NET. While doing so it might happen that,
first, I'm am trying to get the old code run in VB.NET before I'll,
second, start a redesign based on .NET paradigms.

BTW, by myself I stopped mostly using redimmed arrays as collections
occured in VB4.


Harald M. Genauck

"VISUAL STUDIO one" - http://www.visualstudio1.de
"ABOUT Visual Basic" - http://www.aboutvb.de

 

[Tom Shelton]

http://msmvps.com/blogs/bill/archive/2009/02/02/iterators-in-vb-10.aspx

Nice for VB10... Doesn't help for now does it Nor is that easier then
C#'s yeild return. In the same time period - C#4 - we get easy late binding.
But, that doesn't make late binding easier today.

 

[Armin Zingler]

@all:

OMG! Aren't you guys getting tired of these endless and useless discussions?
The facts are documented. The differences are known.

I use VB(.Net) because I come from a BASIC background. I use it still even
if it might have some disadvantages and (maybe few advantages) compared to
C#. Yes, I admit.

English might be easier to learn but my native language is German, so I
speak it. So what? Switch to English because the average number of letter to
say the same is less? No.

As long as C is case sensitive and as long as I need useless braces around
the If(..) condition and I have to type a ";" after each statement, I will
not even think about considering learning C#. So simple is it.

My VB alternative is C++ for those things I can't do in VB. C# is not an
alternative for those things anyway (native directX for example).
Conclusion: I don't need C# at all.


Armin

 

[Michael C]

English might be easier to learn but my native language is German, so I
speak it. So what? Switch to English because the average number of letter
to
say the same is less? No.

Yet again I say, C# and VB.net are not so different to compare them to 2
different spoken languages. It would take years to switch from English to
German. To switch from VB.net to C# would take 1 single day at most. When it
is so simple to switch and C# is easier to use and more powerful why
continue with VB?

As long as C is case sensitive and as long as I need useless braces around
the If(..) condition and I have to type a ";" after each statement, I will
not even think about considering learning C#. So simple is it.

These are all fairly minor and illogical reasons. You dislike brackets in if
statements but you don't object to typing the useless Then statement. That
just doesn't make sense.

My VB alternative is C++ for those things I can't do in VB. C# is not an
alternative for those things anyway (native directX for example).
Conclusion: I don't need C# at all.

C# is actually pretty good with DirectX, I did a whole lot of work with
DirectShow in C# and it worked quite well.

Michael

 

[Michael C]

A module is a class that you cannot create. A shared class with a
manually implemented private constructor is a fake of a static class.

A module is a fake static class but with global functions.

First comes the appropriate usage of elements of a language or framework.
Second is a developer's discipline who should be knowing always what he is
doing. And there are some thirds, fourths etc. concerning the tasks and
their requirements to solve. And just one of the last, or even the almost
last, member(s) of this chain is some additional support for developer's
behaviors.

So what you're saying is that there are more important things to control so
we shouldn't bother with this.

Should I? Have I to do so, because I am a VB.NET developer, grown up from
old VB?
;-)

Ok, because I am grown up from old VB, sometimes it belongs to my tasks to
migrate old VB code to VB.NET. While doing so it might happen that, first,
I'm am trying to get the old code run in VB.NET before I'll, second, start
a redesign based on .NET paradigms.

BTW, by myself I stopped mostly using redimmed arrays as collections
occured in VB4.

In VB4 to 6 we didn't have much choice as collections were pretty limited.

Michael

 

[J.B. Moreno]

Yet again I say, C# and VB.net are not so different to compare them to 2
different spoken languages. It would take years to switch from English to
German. To switch from VB.net to C# would take 1 single day at most. When it
is so simple to switch and C# is easier to use and more powerful why
continue with VB?

Except it's not easier and the more powerful is arguable (in particular
if you don't use a language feature then it doesn't matter what it
allows you to do, you aren't using it).

There's nothing easier than what you've already done, and not changing
habits is easier than changing them.

The question for switching from one language to another isn't how
difficult it is, but what does it gain you. C# to VB or VB to C#
doesn't really gain you that much.

(I say this having several times run into shortcomings in VB that are
annoying and kept me from doing things I would have liked to do in a
nice, elegant manner).

 

[Rory Becker]

Hello Michael,

To switch from VB.net to C# would take 1 single day at most. When it
is so simple to switch and C# is easier to use and more powerful why
continue with VB?

These are all fairly minor and illogical reasons. You dislike brackets
in if statements but you don't object to typing the useless Then
statement. That just doesn't make sense.

Minor???

Case sensitivity - a facet of the language that almost every keystorke you
type. VB.net does not care and C# will rake you over the coals if you disagree.

If changing from C# to VB.Net, your issue here is likely to be that you cannot
create 2 variables whose names are the same save for the casing of those
characters. You will be immediately allerted to this fact by the background
compiler and will be able to declare a new variable(perhaps using a prefix...
I use lowercase m as a prefix for fields). From what I understand there are
relatively few C# developers who do this though so it is even less of an
issue.

The next major issue in switching in either direction is variable declaration.
VB.Net declares the name of the variable ahead of the type that represents
it. for either group this is less of an issue reading the code, but has conditioned
each if it's respective camps to think in a given manner. If I am thinking
of declaring a variable, I think of it's purpose first which gives me it's
name and from this I deduce it's type. For me this is logical and I can type
as I go. If *I* were to write C#, this flow would be broken. I could not
begin typing until I had got as far as deducing the type of the var and then
I could begin typing it. I a quite happy to believe that C# users have adjusted
to this, but I feel this thinking would slow me down considerably. and let's
not forget that Variables are declares in so many places that this becomes
anopther Major issue.

I'm not going to suggest that you could switch entirely from C# to VB.Net
in a single day (while you could read in in that time frame, writing it as
efficiently as you already do your *native* C# is unlikely), I certainly
believe you could switch From C# to VB.Net in a quicker timeframe than the
other way around.

So you don't use If much then... Seriously for a language that's so concerned
with having the least amount of keystrokes possible, why throw these noise
symbols in here?

VB.Net programmers do not type "Then". The IDE does it for them. The *modern*
purpose of the "Then" keyword is to aid readability.
The purpose of Brackets is to seperate sets of content from each other. They
are unnessecary for a single clause C# if statement.

If you like these facets of your language then that's fine....I'm not going
to argue. I simply agree with Armin. For me they are noise and a pain and
so I won't switch.

Actually the biggest barrier to switching languages in .Net is that, short
of a greenfield app (quite rare), you have to create a new project specifically
to hold the code for this new language and then deal with further dependancy
issues.

 

[Andy B.]

Hello Michael,

It does? When I used C# about 6 months or so ago, I had this idea that VB
sucked and really wasn't worth the time. I had the idea that it was inferior
to C# just like you do. When I changed over because it seemed easier to
understand, I had lots of vb language styles to get over. It takes more than
a day to change.

C# and VB don't have superior/inferior complexes on each other the last time
I know. Sure there are some feature differences between them, but the
languages themselves aren't in a power struggle with each other. Just a few
feature differences are:

1. In VB, a lot of runtime errors are caught at compiletime. With C# you
have to run the project to find out any runtime errors.
2. VB claims to support xml data types and processes better than C#. Since I
don't use xml that much at this point I can't verify that.
3. VB is easier to read for most because it attempts to follow the english
grammar style of writing sentences. C# still follows a lot of C++ writing
styles which for some can be hard to understand.

Minor???
Case sensitivity - a facet of the language that almost every keystorke you
type. VB.net does not care and C# will rake you over the coals if you
disagree.

I have been stumped on a few projects for a while trying to fix case
sensitivity problems in code.

If changing from C# to VB.Net, your issue here is likely to be that you
cannot create 2 variables whose names are the same save for the casing of
those characters. You will be immediately allerted to this fact by the
background compiler and will be able to declare a new variable(perhaps
using a prefix... I use lowercase m as a prefix for fields). From what I
understand there are relatively few C# developers who do this though so it
is even less of an issue.

The next major issue in switching in either direction is variable
declaration. VB.Net declares the name of the variable ahead of the type
that represents it. for either group this is less of an issue reading the
code, but has conditioned each if it's respective camps to think in a
given manner. If I am thinking of declaring a variable, I think of it's
purpose first which gives me it's name and from this I deduce it's type.
For me this is logical and I can type as I go. If *I* were to write C#,
this flow would be broken. I could not begin typing until I had got as far
as deducing the type of the var and then I could begin typing it. I a
quite happy to believe that C# users have adjusted to this, but I feel
this thinking would slow me down considerably. and let's not forget that
Variables are declares in so many places that this becomes anopther Major
issue.

dim PersonsAge as int

Is easier to read than

int PersonsAge;

I'm not going to suggest that you could switch entirely from C# to VB.Net
in a single day (while you could read in in that time frame, writing it as
efficiently as you already do your *native* C# is unlikely), I certainly
believe you could switch From C# to VB.Net in a quicker timeframe than the
other way around.

I could read VB 2008 code before writing it. That's what got me interested
in it.

 

[Michael C]

Except it's not easier

I think it is actually easier to use. VB has all these features that are
designed for beginers but they just slow you down when you get a bit of
experience. For example, VB has less compiler checks. Surely if the compiler
picks more errors up for you that is better.

and the more powerful is arguable (in particular
if you don't use a language feature then it doesn't matter what it
allows you to do, you aren't using it).

I really don't think there's much arguement in that. VB is missing some key
features. The more I learn about it the more I realise it's missing.

There's nothing easier than what you've already done, and not changing
habits is easier than changing them.

That doesn't mean it is a good decision. I've seen *many* projects where the
developers have chosen the wrong language because that's what they know.

The question for switching from one language to another isn't how
difficult it is, but what does it gain you. C# to VB or VB to C#
doesn't really gain you that much.

That's true but I think it gains you enough. I used to use VB but thought
I'd have a look at C# with an open mind. I've never looked back and really
dislike working in VB now.

Michael

 

[Michael C]

Minor???
Case sensitivity - a facet of the language that almost every keystorke you
type. VB.net does not care and C# will rake you over the coals if you
disagree.

I used to think like you but I found it to be a complete non issue.
Intellisense fixes your casing for you anyway. In the rare event that you do
get something wrong it's a very simple fix.

If changing from C# to VB.Net, your issue here is likely to be that you
cannot create 2 variables whose names are the same save for the casing of
those characters. You will be immediately allerted to this fact by the
background compiler and will be able to declare a new variable(perhaps
using a prefix... I use lowercase m as a prefix for fields).

Who'se going to change from C# to VB.net anyway ;-)

From what I understand there are relatively few C# developers who do this
though so it is even less of an issue.

I don't think it would be a major problem, a good converter would just add a
suffix to one of the variables.

The next major issue in switching in either direction is variable
declaration. VB.Net declares the name of the variable ahead of the type
that represents it. for either group this is less of an issue reading the
code, but has conditioned each if it's respective camps to think in a
given manner. If I am thinking of declaring a variable, I think of it's
purpose first which gives me it's name and from this I deduce it's type.
For me this is logical and I can type as I go. If *I* were to write C#,
this flow would be broken. I could not begin typing until I had got as far
as deducing the type of the var and then I could begin typing it. I a
quite happy to believe that C# users have adjusted to this, but I feel
this thinking would slow me down considerably. and let's not forget that
Variables are declares in so many places that this becomes anopther Major
issue.

You would get over this in a few days. This is seriously the most minor of
issues. The payoff would be not having to type Dim and As all day long.

I'm not going to suggest that you could switch entirely from C# to VB.Net
in a single day (while you could read in in that time frame, writing it as
efficiently as you already do your *native* C# is unlikely), I certainly
believe you could switch From C# to VB.Net in a quicker timeframe than the
other way around.

Either way I don't see it as being a big problem.

So you don't use If much then... Seriously for a language that's so
concerned with having the least amount of keystrokes possible, why throw
these noise symbols in here?

You need them because there is no then statement to delimit the test and the
action. Eg if x < 0 x = 0, I would much prefer to have the brackets

VB.Net programmers do not type "Then". The IDE does it for them. The
*modern* purpose of the "Then" keyword is to aid readability.

I don't have 2008 here but this doesn't work on 2005. In 2008 don't you have
to type T and then down arrow followed by space?

The purpose of Brackets is to seperate sets of content from each other.
They are unnessecary for a single clause C# if statement.

I think it looks better with them

If you like these facets of your language then that's fine....I'm not
going to argue. I simply agree with Armin. For me they are noise and a
pain and so I won't switch.

That just makes no sense. You won't switch because of these but you're happy
with VB having 10 times the amount of noise?

Actually the biggest barrier to switching languages in .Net is that, short
of a greenfield app (quite rare), you have to create a new project
specifically to hold the code for this new language and then deal with
further dependancy issues.

With a good convertor you can switch a reasonable size app in a few hours.
Someone where I work started a project in VB and then left, leaving all
these developers who would prefer C# stuck in VB.

Michael

 

[Michael C]

It does? When I used C# about 6 months or so ago, I had this idea that VB
sucked and really wasn't worth the time. I had the idea that it was
inferior to C# just like you do. When I changed over because it seemed
easier to understand, I had lots of vb language styles to get over. It
takes more than a day to change.

Sure there were a few things I was learning over the next couple of weeks
but within 1 day I was 99% of the way there. At my last job we had several
meetings about switching from VB to C#. Some people were unsure and were
nervous about the switch. We decided to give it a try and it was the biggest
non event in history. No one even bothered to have another meeting to decide
if we'd switch or not everyone just laughed about how we'd wasted more time
discussing it than doing it.

C# and VB don't have superior/inferior complexes on each other the last
time I know. Sure there are some feature differences between them, but the
languages themselves aren't in a power struggle with each other. Just a
few feature differences are:

1. In VB, a lot of runtime errors are caught at compiletime. With C# you
have to run the project to find out any runtime errors.

That is not true. C# has a larger number of compiler checks than VB and will
catch quite a few more errors. In C# you need to do a compile (ctrl-shift-b)
and it will give you a list of errors. Many of these errors are just plain
missed in VB.

I think what you're thinking of is background compiling so VB will give you
errors as you type. This is a pita imo and makes the VB ide significantly
slower (a lot of corporate users like me are stuck with oldish machines).
You're certainly confusing compile time and runtime errors as C# certainly
has the upper hand with compile time errors.

2. VB claims to support xml data types and processes better than C#. Since
I don't use xml that much at this point I can't verify that.

Yes this is meant to be a better feature of VB. I don't use xml that much
either and I think most people don't have that great a need to embed xml in
their app. While this is an advantage in VB it is certainly a rarely used
feature and pales into insignificance when you compare it to one of the
majors such as the poor intellisense in VB.

3. VB is easier to read for most because it attempts to follow the english
grammar style of writing sentences. C# still follows a lot of C++ writing
styles which for some can be hard to understand.

This can be true at first but trust me, you get over this real quick.

I have been stumped on a few projects for a while trying to fix case
sensitivity problems in code.

I have seriously never encounter any problems. If I mess up I get a compile
error and it highlights the exact problem. I fix it and the whole non event
is over in 10 seconds.

dim PersonsAge as int

Is easier to read than

int PersonsAge;

Not really, you need to read more. When you're beginning you might need the
extra words but if you're remotely advanced user the extra words are just
unecessary.

I could read VB 2008 code before writing it. That's what got me interested
in it.

When you were starting right? Now that you've got more experience you'll
have no trouble with C#.

Michael

 

[Cor Ligthert[MVP]]

That's true but I think it gains you enough. I used to use VB but thought
I'd have a look at C# with an open mind. I've never looked back and really
dislike working in VB now.

As I am active in this end the C# newsgroup, I am curious why do we see you
so terrible active here and less in the C# newsgroup.

Cor

 

[Andy B.]

"I don't have 2008 here but this doesn't work on 2005. In 2008 don't you
have to type T and then down arrow followed by space?"

No. If you go to Options>project defaults>visual basic and turn the "code
prettier" on then all you have to do is:

if(x = 0) [hit enter here and the then...end if is automatically added]


Also if you are in that same dialog (visual basic project defaults) and you
turn on the automatically fix errors, then vs will reformat your code.

'I can type this in the code window
dim PersonsAge Integer

'And after hitting enter it will rewrite the line as...
dim PersonsAge as Integer

Basically if you have these 2 features in vs2008 turned on it minimizes your
typing and coding. You can go back and customize the autogenerated code, but
I would imagine for some code writers it would be a pain in the neck having
to rewrite autogenerated code. For me it works wonders because when i use
new features in vb like inherits or implements it helps out when I don't
know what I'm doing.

 

[Andy B.]

"When you were starting right? Now that you've got more experience you'll
have no trouble with C#."


Haven't actually tried C# again since I started messing with VB fulltime.
Don't know if I plan on changing back though. My projects depend on a
timeline and I can't keep going back and forth or mixing languages between
projects in the same solution. Maybe I will check it out again on the
sidelines and see what happens but not changing back to C#.

 

[Branco]

@all:

OMG! Aren't you guys getting tired of these endless and useless discussions?
The facts are documented. The differences are known.

As long as C is case sensitive and as long as I need useless braces around
the If(..) condition and I have to type a ";" after each statement, I will
not even think about considering learning C#. So simple is it.

<snip>

Amen. Completely aggreed, thank you very much.

It should be quite obvious that most folks hanging out here and
helping out people (even the lurkers and the ones requesting help)
aren't interested in changing languages.

Unfortunately that won't stop the trolls. Speaking of which, I hereby
motion to elect Michael C. the troll of the month.

Regards,

Branco.

 

[Michael C]

As I am active in this end the C# newsgroup, I am curious why do we see
you so terrible active here and less in the C# newsgroup.

I come and go, I have been in the CSharp newsgroup for 8 years and only
recently come here.

Michael