C# developers going back to vb.net

[Kevin]

I don't know if I should even start this topic but here goes.
I'm an ex vb6 developer, now developing in C#.
The reason why I started developing in C# is because the company that I
worked for at the time standarised on C#.

Many of my friends working in previous companies that I worked for are
starting to move back to VB.Net. When I asked them why, it seems that
the next release of VB.Net seems very promising and they kinda see
themselves in the same position I'm in. It seems that at the time when
..Net was first released many companies basically forced developers to
work in C# because as in my case the company they worked for
standarised on C#, why these companies did this is beyond me because
most of their developers were vb developers, I think it's because it
was marketed that C# was the main language to use on the .Net
Framework.

Now many companies as well as management in these companies are
starting to realise that vb.net is not that different from c# and are
starting to give their developers a choice and thus obviously the move
back to vb.

The reason why I'm posting this topic here is because I'm wondering how
many developers using c# are ex vb developers and would actually like
to develop in vb.net. I have actually convinced my superiors to use
vb.net as another language choice and they have agreed.

We have just started a new project in vb.net about 3 mths ago and I
must say that it's still a damn fun language to work in, I'm actually
enjoying my work again. Productivity couldn't be higher as other c# (ex
vb6) developers in my department have also wanted to go back.

Wondering how many of you out there would like to move back to the
lighter side of life?

[Frans Bouma [C# MVP]]

Jon Skeet [C# MVP] wrote:

Kevin Spencer <ke***@DIESPAMM ERSDIEtakempis. com> wrote:

I find
the C# switch statement the most lamest version of a switch
statement you could possibly design, for the sole reason that it
has:

As much as I love C#, this is also one of my pet peeves, and I
certainly don't see the logic in it. It doesn't make C# any
"safer." It reminds me of the sort of thing that VB does to prevent
developers from accidentally creating logical errors. The "break"
statement should stay, but the "no fall-through" rule is
monumentally stupid.

I'd go the other way. Falling through has proved buggy in many, many
C/C++ programs. I'd go for implicit breaks and still avoiding falling
through - or possibly have an explicit "continue" if you want to fall
through, to make it obvious that it's not just an omission.

I see your point, and I also understand that implicit fall-through
implies an order in which the case statements are written which also is
a source for problems.

I would love to have a keyword, continue or what ever, which suggests
proper fallthrough or some other flow, so I can avoid replicating small
code snippets, like:
switch(foo)
{
case 1:
DoA();
break;
case 2:
DoA();
DoB();
break;
}

etc.

FB
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Frans Bouma [C# MVP]]

Jon Skeet [C# MVP] wrote:

Frans Bouma [C# MVP] <pe************ ******@xs4all.n l> wrote:

I never thought the day would come I would say anything in favor of
... VB, but here it goes ;) ->

Jon Skeet [C# MVP] wrote:

Aside from those, I would suggest using C#, for the following
reasons:

1) As it was designed specifically for the .NET framework, it's
more closely aligned to it. It doesn't have a load of legacy
quirks - about the quirkiest it gets is in the switch statement.
Compare this with the various oddities of VB.NET which are
basically there for backwards compatibility, for instance the
String "Nothing" handling.

still, the VB.NET select case statement is IMHO more powerful. I
find the C# switch statement the most lamest version of a switch
statement you could possibly design, for the sole reason that it
has: - lame 'break' statement which is completely redundant (no
fall through supported)
- because of no fall through, you have to use 'goto'. So, using
spagetti with goto is preferred over having fallthrough.. I don't
get it.
- VB.NET's select case has range filters for the case clauses, which
are very powerful.

Yes, VB.NET's select is indeed more powerful - although it's really
only the equivalent of

if (...)
{
}
else if (...)
{
}

as far as I know. Does it use the same switch/case IL construct
(whatever that is - I haven't looked into it) that C# does where it's
able to?

I didn't check when I posted, but I did a small check and you're right!

VB code:
Sub Main()
Dim i As Int32
i = 42
Select Case i
Case 0 To 10
Console.WriteLi ne("10s")
Case 11 To 42
Console.WriteLi ne("rest")
End Select
End Sub

C# decompiled code:
[STAThread]
public static void Main()
{
int num2 = 0x2a;
if ((num2 >= 0) && (num2 <= 10))
{
Console.WriteLi ne("10s");
}
else if ((num2 >= 11) && (num2 <= 0x2a))
{
Console.WriteLi ne("rest");
}
}

I think, with strings it's also not able to use the optimization the C#
compiler uses with a static hashtable, because of the if's. (if you're
using case string1 to string2

3) It uses more standard terminology than VB.NET - null, internal
etc.

Isn't this subjective?

No, I don't think so. Look at the terminology the CLI specification -
it talks in largely C#-friendly terms such as "this" and "null"
rather than "Me" and "Nothing".

Plenty of other languages use the concepts of "this" and "null" too -
how many others use "Me" and "Nothing"?

Not much, but how many languages NOT related to C-derived languages
use 'this' and 'null' ?

I agree, 'Me' is pretty silly, but 'Nothing' makes sense in a way.
What I find way more irritating is the type declaration AFTER the
variable (Dim foo As SomeType), because that makes porting code to
VB.NET pretty cumbersome

Also, operator overloading is underestimated a lot as well. For
example, I've managed to create a 'linq-ish' language with operator
overloading alone to create typed, compiletime checked filters for
my O/R mapper, a few other O/R mappers like genome and I believe
also db4o use similar constructs.

I find it a pity that C# doesn't allow you to define your own
operators as well, because there are just a few operators to
overload. So while I can do:
IPredicate f = (CustomerFields .CompanyName==" Microsoft");

It's harder to create a simple construct to write a subquery filter
as the operator(s) required aren't definable like 'IN'. (with C#
3.0, this ofcourse changes).

Personally, I think that when you get into too many operators and
implicit conversions, the code becomes very hard to read. Just my
experience of C++ though...

Agreed, but IMHO that's also up to the developer of course. In any
language you can write unreadable code. With the proper operators you
can make code MORE readable than it is now and definitely make it more
usable for developers. KEY part of that of course is that the operators
you overload are logical to the constructs they're used with. In C# we
have 1 bad example of that, the '+' sign for string concatenation
(IMHO): '+' stands for an addition, i.e. a mathematical action, but you
can't apply that kind of action on a string (in theory).

FB
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Frans Bouma [C# MVP]]

Bruce Wood wrote:

That's why I said that it's great on system types, but that you
rarely need to write your own operator overloads.

I find I need to write my own operator overloads just about as often
as I need to create my own value types.

Which, I admit, isn't very often, but I found it odd that VB.NET
allowed me to create my own value types but not overload operators. At
least they fixed that in Whidbey.

(In passing, I can't help but point out that this article on operator
overloading in VB.NET;

http://msdn.microsoft.com/vbasic/whi...ll=/library/en
-us/dnvs05/html/vboperatoroverl oading.asp

has an example of creating a complex number class. Now why on earth
would anyone want a complex number reference type...?)

I'd reverse that: why on earth do we need value types? I mean, I
understand they speed things up internally, but why should I be
bothered with that? Because there are value-types, we still have stupid
hacks for nullable ints in C#, even in .NET 2.0. C++ doesn't have
slowdowns when it comes to using pointers to ints, managed code does,
which is kind of odd, when you consider the machine the managed code is
used in is virtual, e.g.: you can make it act like you want it to act.
However a corner-cutting action bleeded through into the languages:
value types.

FB
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Jon Skeet [C# MVP]]

Frans Bouma [C# MVP] <pe************ ******@xs4all.n l> wrote:

<snip>

Plenty of other languages use the concepts of "this" and "null" too -
how many others use "Me" and "Nothing"?
Not much, but how many languages NOT related to C-derived languages
use 'this' and 'null' ?

See my reply to Cor - SQL, Perl and VBScript, for starters.
I agree, 'Me' is pretty silly, but 'Nothing' makes sense in a way.
But it's not the same as the terminology elsewhere - and as VB.NET
developers are likely to have to read things other than VB.NET (such as
the CLI spec) it's an extra set of terminology to learn.
What I find way more irritating is the type declaration AFTER the
variable (Dim foo As SomeType), because that makes porting code to
VB.NET pretty cumbersome

Right.

It's harder to create a simple construct to write a subquery filter
as the operator(s) required aren't definable like 'IN'. (with C#
3.0, this ofcourse changes).

Personally, I think that when you get into too many operators and
implicit conversions, the code becomes very hard to read. Just my
experience of C++ though...

Agreed, but IMHO that's also up to the developer of course. In any
language you can write unreadable code. With the proper operators you
can make code MORE readable than it is now and definitely make it more
usable for developers. KEY part of that of course is that the operators
you overload are logical to the constructs they're used with. In C# we
have 1 bad example of that, the '+' sign for string concatenation
(IMHO): '+' stands for an addition, i.e. a mathematical action, but you
can't apply that kind of action on a string (in theory).

I think adding two strings together is pretty intuitive myself, but
there are plenty of people who've suggested operators they want to
overload but haven't been able to (thankfully). To be able to introduce
your own extra operators would make things even worse, IMO.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Cor Ligthert [MVP]]

Frans,

It is in my opinion not relevant if it is with your sample technical right.
The documentive power from the "select case" start where we get code like
beneath.

VB code:
Sub Main()
Dim i As Integer = 42
Select Case i
Case 1,5, 7, 19, 39
Console.WriteLi ne("first form")
Case 11, 9, 10, 24, 28
Console.WriteLi ne("second form")
Case Else
Console.WriteLi ne("not on a form")
End Select
End Sub

(Any relation with a Lotto form is pure coincidence)

In the way you showed the code I will forever prefer an "if else".

Cor

[Cor Ligthert [MVP]]

Jon,

But it's not the same as the terminology elsewhere - and as VB.NET
developers are likely to have to read things other than VB.NET (such as
the CLI spec) it's an extra set of terminology to learn.

First I thought, Jon has here a point.

However, than I thought is "null" not very much a representation to a very
old historic binary null situation in physical memory addresses (in by
instance the code part of the machine code), which represent *nothing*
assigned.

Does Nothing than not more reflect the way as a symbolic language has to
deal with it?

Just a thought,

Cor

[Cor Ligthert [MVP]]

Jon,

Rereading the message from Frans, do I think that he has a *kind* of same
opinion.

Frans, I can be wrong of course in that.

Cor

[Frans Bouma [C# MVP]]

Cor Ligthert [MVP] wrote:

Jon,

Rereading the message from Frans, do I think that he has a kind of
same opinion.

Frans, I can be wrong of course in that.

The philosophy of VB(.NET) is that the language should represent
english speak as much as possible.

so if you want to test if a variable points to void, you could say:
If foo Is Nothing Then
'...
End If

Which IMHO makes sense, in the scope of that philosophy, although you
could also argue:
If foo Is Void Then

or

If foo References Nothing Then
(which I would find even more readable)

defining 'null' as 'undefined' is IMHO the result indeed of having a
pointer set to 0x0000.0000 as a unified 'undefined' value.

FB
--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Jon Skeet [C# MVP]]

Cor Ligthert [MVP] <no************ @planet.nl> wrote:

But it's not the same as the terminology elsewhere - and as VB.NET
developers are likely to have to read things other than VB.NET (such as
the CLI spec) it's an extra set of terminology to learn.

First I thought, Jon has here a point.

However, than I thought is "null" not very much a representation to a very
old historic binary null situation in physical memory addresses (in by
instance the code part of the machine code), which represent *nothing*
assigned.

Does Nothing than not more reflect the way as a symbolic language has to
deal with it?

I don't think it's particularly relevant - the point is that VB.NET
developers still need to know what null is, because so much of the
documentation, specifications etc refer to it. Why learn two ways of
saying the same thing, if you can instead learn a language which uses
the more common way of talking about things?

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Kevin Spencer]

Hi Adm,

Peronally, I understood your remark about "the mother of all languages." It
was beside the point to point out the minor technical issue. In fact, C was
written to look more or less like Pascal, so one might argue, with
Lillipution intent, that Pascal was the "mother of all languages." Still, it
would indeed be pointless to do so.

I appreciated your enthusiasm, and, regardless of the occasional
technicality, I found your arguments for the most part quite understandable.
In fact, as it was an expression of opinion, and not a factual answer to a
question, I considered it less important that it should be "absolutely
factually correct" (if that is possible, considering the vagaries of
language).

It irritates me to see people publicly correct others without some
valid/helpful reason for doing so. If, for example a person asks a question,
and a person responding speaks without knowledge, and therefore leads the OP
down the wrong path to a solution, I feel it necessary to correct the person
responding, and provide the correct information. This helps the OP to find
the solution they seek. On the other hand, when a person is asked for an
opinion and gives it, and is incorrect on some minor technical point, who is
harmed by it? Why should the person venturing the opinion be publicly
corrected for their perceived and minor error? Who is helped by it? The only
conclusion I can draw from such behavior is that ther person doing the
correcting is attempting to elevate public perception of their knowledge at
another person's expense. And that is both unnecessary and uncalled-for.

It took 4 years for Microsoft to develop the first version of the .Net
platform. I will be the first person to admit that I don't know everything
about it. I do, however, know how to research, and am quite good at that.
When I first began to program, I relied heavily on help from others who were
farther along the path than I. Now I feel a sense of responsibility to do
the same. That is my motivation. I help when I can, and keep silent when I
can not.

I did feel a certain need to step in to your defense. I don't like to see
people bullied. And I can hold my own in a scuffle. I don't mind a knock or
two here and there. I can give as good as I get. I am confident in my
professional life, and not afraid of the opinions of others. They cannot
harm me professionally, and I have a thick skin. So, from time to time I
will step in to defend someone else. Call me a glutton for punishment.

But don't feel bad that you may have somehow embarassed yourself with your
contribution. I found it quite refreshing! :)

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

"Adam Tibi" <Ad******@discu ssions.microsof t.com> wrote in message
news:DD******** *************** ***********@mic rosoft.com...

Thanks for explaining pal, maybe I needed to ask more before I reply back
and
maybe your first reply should have included the "mother of all languages"
thing so I would have understood what is going on.
What I meant by saying that C++ is the mother of all languages is that C#,
PHP, Java, JavaScript and others that I don't know tried to follow the
syntax
of C/C++! Well, how far they went varies between one language and another
and
undoubtly C# was the pioneer.
My comments comparing C# versus VB.NET is emotional, I agree on that, and
such topic requires emotional rather than logical answers.
Sorry for being unpolite, this is a lesson for me to listen more than I
speak and believe me I am working on it :)

"Cor Ligthert [MVP]" wrote:

Adam,

> Actually, I think that it would unprofessional to comment on my style
> of
> writing or language versus the actual content.

Can you tell me where I wrote that in my reply to Kevin? I will be
probably
the last one who not completely agrees about that with you. In fact it
was
Kevin who did that.

My reply had nothing to do with your style of writing it had to do with
the
fact that Kevin gave me the idea that he had not even read your message
and
therefore was only trolling my reply to you.

In my opinion are there some things in the content of your original
answer
that makes that probably not much people will read it after they have
seen
this starting sentence.

>>C# syntex is derived from the mother of all languages C++

AFAIK is C# the only language derived from C++.

I had read your message completely and had the idea that I understood
everything you wrote. I had the idea that most maybe came from your hart
but
is not based on much investigation

Therefore I gave you the link to Wikepedi, I assume that you would not be
glad when I was only copying the content of that in a message.

Cor