C# developers going back to vb.net

[Guest]

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

 

[Frans Bouma [C# MVP]]

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


--

 

[Frans Bouma [C# MVP]]

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.WriteLine("10s")
Case 11 To 42
Console.WriteLine("rest")
End Select
End Sub

C# decompiled code:
[STAThread]
public static void Main()
{
int num2 = 0x2a;
if ((num2 >= 0) && (num2 <= 10))
{
Console.WriteLine("10s");
}
else if ((num2 >= 11) && (num2 <= 0x2a))
{
Console.WriteLine("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

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

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


--

 

[Frans Bouma [C# MVP]]

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/whidbey/default.aspx?pull=/library/en
-us/dnvs05/html/vboperatoroverloading.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


--

 

[Jon Skeet [C# MVP]]

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.


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.

 

[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.WriteLine("first form")
Case 11, 9, 10, 24, 28
Console.WriteLine("second form")
Case Else
Console.WriteLine("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]]

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


--

 

[Jon Skeet [C# MVP]]

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?

 

[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.

 

[Guest]

Hi Kevin,

Thank you for this nice reply and thank you for defending me.

Have a nice weekend

 

[Michael A. Covington]

Peronally, I understood your remark about "the mother of all languages."
And ALGOL 60 is the mother of Pascal. Does that mean ALGOL is C#'s
great-grandmother?

Or that Delphi is C#'s great-aunt?

 

[Doug H]

Here's how it will look in boo, just for comparison:
http://boo.codehaus.org/

i = 42
given i:
when 1,5,7,19,39:
print "first form"
when 11,9,10,24,28:
print "second form"
otherwise:
print "not on a form"

or your other example:

i = 42
given i:
when 0 <= i <= 10
print "10s"
when 11 <= i <= 42
print "rest"

http://jira.codehaus.org/browse/BOO-136

I'm not saying it's better or worse or anything.

To the guy who's deciding about what language to use for new hires, I'd
probably recommend C# if they are already familiar with java or C++
(which is likely if they are CS grads).

 

[Cor Ligthert [MVP]]

Michael,

And ALGOL 60 is the mother of Pascal. Does that mean ALGOL is C#'s
great-grandmother?

Or that Delphi is C#'s great-aunt?

I think that you are right, however in my opinion is Algol not completely
the mother of all languages.

I think that it can be called that for all by mainly Beta's used languages.
The sister Cobol can in my opinion be seen as a mother of all languages for
the "Alpha's".

Strange enough are that much less while they have AFAIK a very broad public
that uses them.

Cor

 

[igouy]

Michael,


I think that you are right, however in my opinion is Algol not completely
the mother of all languages.

I think that it can be called that for all by mainly Beta's used languages.
The sister Cobol can in my opinion be seen as a mother of all languages for
the "Alpha's".

Strange enough are that much less while they have AFAIK a very broad public
that uses them.

Cor

http://www.levenez.com/lang/history.html#01

 

[Cor Ligthert [MVP]]

Hi,

Thanks,

http://www.levenez.com/lang/history.html#01

Very interesting.

Cor

 

[Bruce Wood]

Sigh. Some months back I was waging a battle on this front... I guess
it didn't have much effect.

Yes, in a few situations, structs offer performance benefits. You can
see typical uses in this regard in System.Drawing.Point and
System.Drawing.Rectangle, among others. They're things that by rights
ought to have reference semantics that were made into structs for
performance reasons, I think. At least, I can't think of any other
reason to create _mutable_ value types and suffer the resulting
confusion among programmers using your class library.

That said, value types are incredibly... um, valuable... when it comes
to modeling things that are _values_. I'm going to try very, very hard
not to believe that you're honestly suggesting that ints should have
been reference types. Do you really believe that this code:

int a = 5;
int b = a;
a = 16;
Console.Writeline("{0}", b);

should write 16? Can you imagine how difficult it would be wrap your
mind around programming in a language with only reference semantics?
Just imagining the mayhem makes my head hurt. If memory serves,
even venerable LISP, the everything-is-a-reference-type language, took
pains to avoid this.

Complex numbers, money (quantity plus currency), measures (quantity
plus unit of measure) and other such things are natural value types.
For the complex numbers example,

int a = new Complex(5, 1);
int b = a;
a *= a;

should leave b containing [5, 1] as before, not [-25, 0], which is what
a would contain (pardon if I made an error there... I haven't worked
with complex numbers in 20 years). In other words, the thing should act
like a value, not like an object with reference semantics. As Steve
Walker pointed out, when I add $5.00 and $0.25 and put the result back
in the original variable, I really don't want every $5.00 quantity in
my system to change to $5.25. That would be nasty.

Sorry for the rant, but it drives me nuts when people start building
Customer structs, saying that it's "more efficient", and then wonder
why their code does all these weird things. It drives me even crazier
to know that Microsoft has a (VB) example of how to use structs in
their knowledge base that shows a Customer struct with a half-dozen
fields. Aaaargh!

 

[Bjorn Abelli]

...

That said, value types are incredibly... um, valuable... when it comes
to modeling things that are _values_. I'm going to try very, very hard
not to believe that you're honestly suggesting that ints should have
been reference types. Do you really believe that this code:

int a = 5;
int b = a;
a = 16;
Console.Writeline("{0}", b);

should write 16? Can you imagine how difficult it would be wrap your
mind around programming in a language with only reference semantics?
Just imagining the mayhem makes my head hurt.

I don't see this as a good example on what you mean. Why should it write 16?
When you're assigning a literal to a variable, you could say you're
assigning another object, not changing the objects contents.

int a = 5;
int b = a; // Is now referencing 5
a = 16; // Is now referencing 16
Console.Writeline("{0}", b);

b is still referencing 5

Try this for comparison:

string a = "Hello";
string b = a; // Is now referencing "Hello"
a = "World"; // Is now referencing "World"
Console.Writeline("{0}", b);

b is still referencing "Hello".


This is really no different than:

Customer a = new Customer("Bill");
Customer b = a; // Is now referencing Bill
a = new Customer("Bob"); // Is now referencing Bob
Console.WriteLine("{0}", b);

b is still referencing "Bill"

So the traditional logic when using primitives or value types shouldn't
necessarily need to change just because they became reference types instead.
At least no changes that I can see at the moment. I think much lies in how
to define the behaviour of the operators.

But there still might be other issues with using only reference types rather
than having both value and reference types... ;-)

// Bjorn A

 

[Bruce Wood]

Point taken. My examples weren't very good, as you pointed out. In
order to get into trouble with integers-as-reference-types, there would
have to be some quality of the integer itself that was mutable, so that
you could get into trouble by changing that mutable quality in one
place and having it change everywhere.

Anyway, the point was that I like value types. They're powerful when
used in the correct contexts, but a terrible pain when used in the
wrong contexts. Most complaints I've seen in this discussion group
about what a bad idea value types are arise from people using them for
the wrong reasons.