C# v VB.NET - any research on usage?

[Kevin Spencer]

Hi Herfried,

Good arguments, and well-stated.

I prefer C#, but I'm not religious about it. It does more than VB.Net, and
I've always liked the syntax. The second reason, however, is purely personal
preference.

It is heartening, though to see the improvements in VB.Net that are in the
..Net 2.0 Framework, and in the Visual Studio.Net 2005 IDE. For example, I
have complained for years about Option Strict being OFF by default, and that
is fixed in the new Visual Studio. I can see why it was done originally, but
the argument just didn't hold water. As you've pointed out, VB.Net is .Net,
*not* VB6. It has all the power of .Net, and that means all of the
opportunity to screw up. That implies that it should be more strict than its
predecessor, which it is.

Other constraints in the new version are also encouraging. Microsoft has had
quite a tightrope to raverse with VB.Net, and has made some adjustments in
the right direction. They had enough trouble selling it to VB6 developers in
the first place, but the problems their accomdations caused certainly
outweighed the complaints of those who were not used to a strongly-typed,
fully object-oriented programming technology. I believe Microsoft has
finally struck the right balance in the latest version. VB6 developers will
simply have to adapt and grow, like everybody else. And that will be good
for everyone.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Cor Ligthert [MVP]]

Michel,

See as well my replies to Jon to that, you can call something a language (or
whatever) than it is therefore not a language.

In computing is more often the word "language" used for things that had
nothing to do with a language.

It can be that it is my interpretation from a language, a language is for me
a tool to communicatie between two media if it is a natural language or a
program language. A description is that not. There have be more developments
tools been (4th generation) that where no language however got that name.

Just my opinion,

Cor

 

[Cor Ligthert [MVP]]

Jon,

Ah, mods. I still believe there are far fewer people doing that than
have been using VBA/VB professionally just occasionally.

Of course those people use VBA/VB professonally
LOL
(I know therefore it are not professional developpers)

What do you think the "L" stands for?

I have written in this thread that it is a "description language", however I
kept always some doubt about that.

I cannot come on that phrase for that at the moment.

Cor

 

[Cor Ligthert [MVP]]

Jon,

This what I write bellow I can never proof.

I have strongly the idea that the Microsoft Visual Basic namespace is only
created, to keep it apart from the framework so that C++ and Java
developpers whould not have the idea that the languages C# and J# are a kind
of changed VB (what I do not say or think).

That does not mean as I have often written that I am lucky with the
behaviour from all classes in that Visual Basic namespace (by instance the
strange use of the indexers). However there are many, which would have
enrichen the basic Net namespase, if they where as well direct available to
the other Net languages.

Let us not start talking in detail about this, which would and which should
not.

Cor

 

[Cor Ligthert [MVP]]

Charlie,

May I have the conclusion from your statements that Microsoft has problems
to sell C# and J# to the Java and C++ developers. I see that more and more
classic VB developers are successful adapting VB Net.



Cor

 

[Cor Ligthert [MVP]]

Jon,

Do standardised SQL include "IF" etc?

That is what I would have wanted to say, and could not get it what it was.
That If is for "me" essential in a program language. Maybe better to
descript as every "branch" statement.



Cor

 

[Herfried K. Wagner [MVP]]

1. the NET framework is associated with various misconceptions ranging
from Bill Gates wanting to take over the world to problems with the MS
Passport.

I don't think that it was the purpose of the .NET Framework to encourage
adoption of .NET Passport, although marketing appended the ".NET" to many
product names.

I don't think it is recognized as a virtual machine in the same way that
Java is yet by most of the public users, it is seen as some kind of
network related system that's not really connected with local software.

I agree with you that the name ".NET" was not the best choice.

Unfortunate naming perhaps, but since programs written using it require a
download I think it will suffer delays in real widespread usage.

Windows Server 2003 comes with the .NET Framework, as Vista will do.
Windows XP SP1/SP2 CD-ROMs included the .NET Framework as an optional
component too. So, hoplefully this won't be such a big problem in future.

 

[Kevin Spencer]

Jon's issue is not with your use of the word "language," but with your use
of the adjective in the phrase "programming language." In the acronym "HTML"
the 'L' stands for "language," and it most certainly *is* a language. But
the 'M' stands for "markup," which means that it is a markup language, not
necessarily a programming language.

In fact, it is *not* a programming language, as I pointed out in my earlier
message, and for the reasons I gave.

I am not interested in whatever emotional zeal anyone may have, or how
anyone may subjectively characterize the expressions of ideas. I am only
interested in the ideas themselves, as part of the betterment of the
community, via the distribution of knowledge, which is factual by nature.

One may certainly prefer one language over another, and have perfectly
valid, albeit subjective reasons for having that preference. For example,
one may be more comfortable with one syntax over another, and that certainly
lends itself to productivity. Productivity is a profitabl goal, and
therefore makes the preference perfectly logical.

It is not necessary to provide arguments which are *not* logical to promote
the use of one language over another. In fact, such arguments confuse the
issue.

The decision regarding what programming language(s) one chooses to use is a
matter of weighing the benefits of one against the benefits of another. This
decision includes both objective fact, and subjective fact (such as I
described above). Some benefits are global in scope, such as the available
functionality which the language presents to all users of it. Other benefits
are local in scope, such as the comfort-level of the user with one syntax
over another.

In the decision-making process, it is best to have factual evidence, at all
possible levels of scope, to work with. Anything else tends to lead to
erroneous conclusions.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Jon Skeet [C# MVP]]

VB.NET has been marketed as VB6' successor, but from a technical point of
view I don't see many similarities. Behavior of the language's syntax has
been altered in many occasions, thus I believe that it has not been one of
the main goals when designing the language. "Micrsosoft.VisualBasic.dll" is
a nice add-on which makes using VB.NET easier for VB6 programmers. However,
"Microsoft.VisualBasic.dll" is a managed library, and from a technical
standpoint there are no reasons for avoiding its use.

It's a less object-oriented way of doing things. If you want to do
something to a string, surely it makes more sense to call a method on
that string than to call a static method in a class in a totally
different assembly.

No, I do not believe that. But to you believe they had designed the C#
language from scratch with *no* reference to C/C++ and Java, there would
have been quite so many similarities? It's petty clear that Microsoft
didn't attempt to reinvent the wheel. It's hard to position a new
programming language on the market if nobody is familiar with its syntax.

But they could easily have kept the VB syntax without keeping a lot of
the extra functions. Most of the functions have *similar* equivalents
in the .NET framework, as far as I've seen - the differences aren't
usually why someone would use the function rather than the more OO
method call. The reason for using the function would normally be
because that's what their old code did, IMO.

No, they are part of a library. They are not part of the language. It's
not guaranteed that all implementations of the language provide this
library.

Hmm. It's unfortunate that with VB, the line between language and
library is somewhat hazy IMO. Is VB6 the language or the language plus
the libraries? Does "CDate" fall into the category of a language
element or a library call?

They're things that the compiler itself needs to be aware of (as far as
I know), whereas a compiler doesn't usually need to worry about what
libraries are available, so long as it can find out in a standard way
when you try to call them.

Either way, I hope you *do* take the point that saying that "nobody is
forced to use these functions" doesn't help you if you're trying to
understand someone else's VB.NET code when they *have* used them. It's
extra stuff to learn, and I don't believe most of it would be there if
it weren't for earlier versions of VB.

Some of the methods of the library are not avalilable on
handhelds, etc. So they are clearly an add-on.

I don't think that makes them an add-on, any more than it makes those
classes/methods which aren't in the Compact Framework less "part of the
..NET framework".

The .NET Framework and .NET technology is the infrastructure programming
languages can be built on. The 'using' statement, for example, is simply a
wrapper around a method call and error handling code. Some .NET programming
languages do not provide an equivalent keyword as part of their syntax. So,
people using another .NET programming language will have problems to
understand C# or VB.NET code too.

There are very few of those in C# compared with the number of VB
functions, however - and they're part of C# that all C# developers (and
anyone reading C#) really *should* know.

Well, there is a Java to C# conversion wizard available.

I don't think that's really the same as the VB situation though. (It
was also a really bad idea IMO, but that's another matter.)

Maybe they didn't copy C but copied Java instead... I don't think this
argument makes much sense.

They certainly copied the syntax of Java to a large extent. I don't
think anyone outside Microsoft would argue against that. I don't see
why that's a legacy issue though. They fixed some of the issues at the
same time though, because they weren't trying to let people run their
Java code in C#.

A good example is calling static methods. I really like the fact that
C# doesn't let you call a static method via an instance variable. For
instance, this won't compile:

Thread t = new Thread (...);
t.Sleep (1000);

The equivalent in VB.NET *does* compile though - and I believe they
chose to keep it that way because it would have worked in VB classic.

There are various quirks in VB like that - the handling of null strings
being another example. Do you really think they would have made the
string handling that way if they didn't care about backward
compatibility to some extent?

The switch statement is one of the very, very few places where a bad
idea has been kept (admittedly slightly improved) in C# rather than
fixed.

 

[Jon Skeet [C# MVP]]

This what I write bellow I can never proof.

I have strongly the idea that the Microsoft Visual Basic namespace is only
created, to keep it apart from the framework so that C++ and Java
developpers whould not have the idea that the languages C# and J# are a kind
of changed VB (what I do not say or think).

What's your reasoning for that? I can't imagine anyone either thinking
that C# is a changed VB or believing that other people would. It's
*much* more likely that they'll think C# is a derivative of Java, which
it basically is...

That does not mean as I have often written that I am lucky with the
behaviour from all classes in that Visual Basic namespace (by instance the
strange use of the indexers). However there are many, which would have
enrichen the basic Net namespase, if they where as well direct available to
the other Net languages.

Let us not start talking in detail about this, which would and which should
not.

That would quite possibly be a bad idea, yes.

 

[Cor Ligthert [MVP]]

Jon,

What's your reasoning for that? I can't imagine anyone either thinking
that C# is a changed VB or believing that other people would. It's
*much* more likely that they'll think C# is a derivative of Java, which
it basically is...

Maybe you can get yourself an idea with some more thinking about it, you are
clever enough for that.

In additon start with thinking about this at the time from the introduction
not now, because now you would be handles as a complete fool to tell that.



Cor

 

[Herfried K. Wagner [MVP]]

Jon,

It's a less object-oriented way of doing things. If you want to do
something to a string, surely it makes more sense to call a method on
that string than to call a static method in a class in a totally
different assembly.

I believe that's a matter of personal preference. Take mathematical
functions for example. They are still shared methods although they could
alternatively have been implemented as methods of numeric data types.
Operators are not really object-oriented too. IMO it's legitimate to treat
strings differently from other types as it is done with types like 'Int32',
'Int64', etc. which have alias names defined and specialized support
provided as part of the language. VB.NET has built-in support for dealing
with strings ('Like' operator).

But they could easily have kept the VB syntax without keeping a lot of
the extra functions.

As the functions are not part of the language, that's not really relevant.
Maybe somebody else would have implemented an equivalent to the VB6 function
library if Microsoft hasn't done that.

Most of the functions have *similar* equivalents
in the .NET framework, as far as I've seen - the differences aren't
usually why someone would use the function rather than the more OO
method call.

OO has its advantages, but I do not see the huge benefits of OO when dealing
with numbers and strings. I remember discussions in which people were
asking why 'r.Replace("b", "c")' didn't manipulate the contents of 'r'. On
the other hand I have /never/ seen such a question about 'Replace(r, "b",
"c")'. Consequently I would not say that 'String''s methods are more
intuitive and preferrable over VB's strings-related functions. Another
example is 'Substring' vs. 'Left', 'Right', and 'Mid', which I have
mentioned in previous discussions about this topic. In this case I like the
power of 'Mid' on the one hand and the existance of specialized functions
over one generic method. VB's 'Split' functions is more powerful than
'String.Split', and thus I do not see any benefits in using 'String.Split'
instead of VB.NET's 'Split' function.

The reason for using the function would normally be
because that's what their old code did, IMO.

As shown above, that's not the reason why I prefer the VB string handling
functions over the methods of the 'String' class.

Hmm. It's unfortunate that with VB, the line between language and
library is somewhat hazy IMO. Is VB6 the language or the language plus
the libraries? Does "CDate" fall into the category of a language
element or a library call?

In VB6, the 'C*' conversion functions were members of 'VB.Conversion',
although they were compiled inline. In VB.NET, the conversion functions (or
operators...) are not part of a module included with
"Microsoft.VisualBasic.dll". In VB6 the line 'n = Conversion.CLng(12)'
compiled, while it cannot be compiled in VB.NET.

They're things that the compiler itself needs to be aware of (as far as
I know), whereas a compiler doesn't usually need to worry about what
libraries are available, so long as it can find out in a standard way
when you try to call them.

Yes, in VB6 the compiler was aware of the existance of the functions in the
library. In VB.NET the 'C*' functions are directly built into the language.
However, it's not uncommon that a compiler emits calls to functions in
external libraries for syntax features. In VB.NET and C#, for example, the
compiler will emit method calls and error handling code for the 'Using'
statement.

Either way, I hope you *do* take the point that saying that "nobody is
forced to use these functions" doesn't help you if you're trying to
understand someone else's VB.NET code when they *have* used them. It's
extra stuff to learn, and I don't believe most of it would be there if
it weren't for earlier versions of VB.

I really wonder how all those huge applications are being written if people
have problems with learning how a dozen of function work. It's pretty clear
understanding code which is implemented in another programming language
requires one to get familiar with the language.

There are very few of those in C# compared with the number of VB
functions, however - and they're part of C# that all C# developers (and
anyone reading C#) really *should* know.

For me it's important to make a clear distinction between language features
and library functions/classes. As you know, it's possible to use
"Microsoft.VisualBasic.dll" in C# projects too. "Cscompmgd.dll" has a
"Microsoft.CSharp' namespace, but this doesn't mean that the classes
contained in this library are part of the C# programming language. I agree
with you that someone claiming to be familiar with C# should know the
meaning of the 'using' statement, but I don't think that somebody using
COBOL.NET, which (I am not sure about this) doesn't have an equivalent
statement, needs to know that.

They certainly copied the syntax of Java to a large extent. I don't
think anyone outside Microsoft would argue against that. I don't see
why that's a legacy issue though. They fixed some of the issues at the
same time though, because they weren't trying to let people run their
Java code in C#.

The same has been done for VB.NET. They took certain features of other
programming languages, mainly VB6, fixed them and added other features.

A good example is calling static methods. I really like the fact that
C# doesn't let you call a static method via an instance variable. For
instance, this won't compile:

Thread t = new Thread (...);
t.Sleep (1000);

The equivalent in VB.NET *does* compile though - and I believe they
chose to keep it that way because it would have worked in VB classic.

VB6 didn't have static methods at all, so I cannot draw the line between
this design decision for VB.NET and VB6. The VB.NET team has chosen to use
the keyword 'Shared' instead of 'static' and refer to these members as
"shared" members opposed to C# where they are called "static" members.
"Shared" implies that those members are shared between all (0, 1, 2, ...)
instances of a class. So the decision to allow access to shared members via
an instance variable is in compliance with VB.NET's semantics of shared
members.

Practice has shown that this decision has drawbacks too, and thus this issue
has been fixed by adding a compiler switch which disallows access to shared
members via instance variables.

There are various quirks in VB like that - the handling of null strings
being another example. Do you really think they would have made the
string handling that way if they didn't care about backward
compatibility to some extent?

I am not sure what you are talking about. It would be great if you could
provide some more details.

 

[Cor Ligthert [MVP]]

Jon,

If could for the same case be the other way around by the way.

I don't see any technical reason why the Microsoft Visual Basic namespace is
not inside the Net Namespace. That is the only reason that did give me that
idea, what as I already wrote can be a complete mis.

Cor

 

[Cor Ligthert [MVP]]

Jon,

I miss the handling of the indexers and array in this.



Cor

 

[Kevin Spencer]

What's your reasoning for that? I can't imagine anyone either thinking

that C# is a changed VB or believing that other people would. It's
*much* more likely that they'll think C# is a derivative of Java, which
it basically is...

Now, I wouldn't say that, any more than I would say that the .Net platform
is a derivative of the J2EE platform.

From my observations, Microsoft has been using some of the syntax (the dot
separator, for example) for quite some time now, and it really is a much
clearer syntax than the traditional C++ syntax. Furthermore, and this is
merely conjecture on my part, I can't help but notice that the '#' character
can be viewed as a combination of 2 "++" sequences, implying that C# is
"C++[++]". In the time-honored tradition of C's extensibility, I would
suppose that C# is intended as such, an extension of C++.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Cor Ligthert [MVP]]

Herfried,

For me was this a main part of Jon's reply

But they could easily have kept the VB syntax without keeping a lot of the
extra functions.

Because that I was sure that you would give a long reply on Jon, did I not
reply on that, however now I miss in your reply that Net has a lot of
methods which are almost the same.

By instance Parse and Convert, backgroundworker and threading however
calling them is impossible because it is endless..

(Visual) Basic has a longer consistent lifeline than the languages derived
from Algol -> CPL -> C which forever start often again. However C# 2 has
now as well with methods which are original from C#1, those are not deleted.
There will be with improvement more and more of those doublures in the C#
language (in fact in Net).

That there are so much shows in fact the consistency of the Visual Basic
Language, while C# gets now in the current and the next version the same
consistency.

Just to add to your reply.



Cor

 

[jeremiah johnson]

What's your reasoning for that? I can't imagine anyone either thinking
that C# is a changed VB or believing that other people would. It's
*much* more likely that they'll think C# is a derivative of Java, which
it basically is...

My personal opinion is that when it was decided that a new platform was
in order, that a new language was in order as well. Anders(sp?) raised
his hand, said "I'll do it," and came up with C#. A home run, I believe.

the VB people did not want to leave their armies of VB6 programmers
behind, so they created VB.NET in C#'s image (because it was so well
designed). the VB.NET syntax is eerily VB-like and OO-like, an odd
combination of each, and for the few programs I've tried it on, going
from C# syntax to VB.NET syntax is a line-for line conversion (the vise
versa is not necessarily true.) I could list out many examples but if
you look at C# code, it is simple to convert it to VB.NET, line for
line. This shows a *clear* relationship, to me.

VB.NET was created so that the batallions of VB programmers out there
would not be left behind when .NET became the development platform of
choice for Windows. It is designed to look familiar (and thus
comfortable) to VB6 programmers, so they will adopt it, but basically it
is C# with a few VB language paradigms tacked on. In the future this
might not be true, but I think right now it is the case.

 

[Kevin Spencer]

You're joking I hope!

What about the other 18+ languages that have been developed for the .Net
Framework?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Charlie Tame]

Charlie,

May I have the conclusion from your statements that Microsoft has problems
to sell C# and J# to the Java and C++ developers. I see that more and more
classic VB developers are successful adapting VB Net.



Cor

I think that if MS are trying to get NET implemented it needs to be reliable
and easily distributed to end users. It doesn't need to be a series of false
starts where the end user's install package tells him he needs something
different on each machine he installs it on. I don't think developers will
sell their products as easily.

Charlie

 

[Cor Ligthert [MVP]]

Jeremiah,

In other words as I wrote it earlier in this thread and were Jon was
absolutely agreeing with me. The rest is in my opinion just the point of
view that you have to the object of this thread.

Absolutely - we just disagree about what exactly that means, I suspect.

Cor