Is VB Caca??

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Which makes it really natural to ask "why do you live here, them?".
And it's something that only Göran can answer, I guess... "Because I
have to"; "Because I'd like to see things from a different
perscpective"; "Because I can endure anything"; "Because there are
things here that I don't find anywhere else"; "Because I'm trying to
convince people to leave this city and come to Seatle with me"; Who
knows? I'm one who'd like to know why Göran, which seems to dislike VB
(.Net) hangs in here. Just that.

I don't live here. I just come to visit for the people.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Göran Andersson wrote:


It's not true that x keeps its value outside it's scope. The scope is
the loop, therefore it lives *inside* the scope.

Yes, it lives outside the scope. You leave the scope for each iteration
in the loop, but it still keeps it's value.

Try this, if you don't believe me:

Dim s As String
s = String.Empty

Dim j as Integer
For j = 1 to 3
Dim i As Integer
For i = 1 To 3
Dim x As Integer
x += 1
s += x.ToString + ","
Next
Next

If the variable only kept it's value inside the loop, it would be
initialised when you enter the inner loop, which would produce the
string "1,2,3,1,2,3,1,2,3,".

It doesn't. The value of the variable is retained outside the loop, so
the string produced is "1,2,3,4,5,6,7,8,9,".

To all practical effects, in VB a variable gets its default value
(i.e., nothing, 0, false, etc) just upon declaration. The declaration
itself isn't considered an executable statement. Therefore, if the
variable is declared inside a loop, it will keep whatever value it was
last assigned between cicles (that is, the declaration itself won't be
"executed" between cicles).

Declaring a variable does not set it's value, as I just showed. The
value is set when the variable is created, which is at the start of the
method.

On the other hand, any initialization you supply in the declaration
*is an executable statement*, and thus will be executed between loop
cicles. Thus, if you want a variable to be *reinitialized* at each
cicle, you must explicitly say so:

Dim S As String
For I As Integer = 1 To 10
Dim X As Integer = 0
X += 1
S &= X.ToString & ","
Next

This may seem odd to people that come from a language that doesn't
initialize the memory where the variables live in, but it becomes
quite natural when you understand it.

Oh, I understand it. That's why I am trying to explain the risk of
declaring a variable inside a scope and believing that it only lives
indide that scope.

Sure, this can lead to less "pure" (whatever this means) uses:

Dim S As String
For I As Integer = 1 To 10
Dim X As Integer = X + 1
S &= X.ToString & ","
Next

Does that even compile? Yuck!

 

[Branco Medeiros]

Yes, it lives outside the scope. You leave the scope for each iteration
in the loop, but it still keeps it's value.

Try this, if you don't believe me:

Dim s As String
s = String.Empty

Dim j as Integer
For j = 1 to 3
Dim i As Integer
For i = 1 To 3
Dim x As Integer
x += 1
s += x.ToString + ","
Next
Next

Ouch! The scenario showed in your example is a major trap.

<snip>

I was not aware of the *impractical* effect shown above. The fact is
that variables get initializaded to default values all at once in the
stack frame (even the ones that will be actually declared later,
inside a block). The code you showed uses a side effect of this. =P

Point taken.

Regards,

Branco.

 

[RobinS]

Then you are judging something of which you have no experience. I have
written a handful of apps in VB, then turned around and rewritten the same
applications in C# for the experience, and I can promise you, the
"auto-compile-as-you-type" function in VB is a *lot* more dynamic and
fully-functional than the one in C#.

Robin S.
-----------------------------------------------

Goran,

You surely should try VB.Net once.

I regularly write small pieces of code in VB.NET to try them out. Not
enough to notice any difference in the background compilation, though.

There is some checking in C#, however for somebody who knows what VB.Net
does, it is really nothing.

As you have seen am I a not always a correct typer (but very quick), I
assume that I build a C# program at least 5 times more than a VB.Net
program.

I do mostly web development. I don't even have to build it to run it.

 

[Michael D. Ober]

Yes, it lives outside the scope. You leave the scope for each iteration
in the loop, but it still keeps it's value.

Try this, if you don't believe me:

Dim s As String
s = String.Empty

Dim j as Integer
For j = 1 to 3
Dim i As Integer
For i = 1 To 3
Dim x As Integer
x += 1
s += x.ToString + ","
Next
Next

Ouch! The scenario showed in your example is a major trap.

<snip>

I was not aware of the *impractical* effect shown above. The fact is
that variables get initializaded to default values all at once in the
stack frame (even the ones that will be actually declared later,
inside a block). The code you showed uses a side effect of this. =P

Point taken.

Regards,

Branco.

This is the documented behavior of variables in VB.

Mike Ober.

 

[RobinS]

Just because I prefer C# myself, doesn't mean that I think less off
people only based on what language they use.

Most questions are about programming in general and methods in the
framework anyway, and that is the same regardless of the language used.

To me, you come across derisive of VB and sure that there is nothing that
can be done as well in VB as it is in C#. You may not *think* that means
you don't think less of VB programmers, but there is an implicit judgment
in there.

I hang out in the C# group, and am not judgmental or derisive about C#. And
yes, I could be if I wanted to, but I think it's disrespectful of other
peoples' choices.

To me, it's like standing in a place of worship and vocally deriding the
religion therein. Judging by how strongly some people feel about their
language of choice, I don't think that's far off the mark. ;-)

As we all know, we can debate the pluses and minuses of VB and C# all day
long and never reach a consensus. I program in both, but I prefer VB
because it is clearer *to* *me*. There are things I prefer about C# as
well.

What is important is that people write effective, impactful, logical,
understandable code in whatever language they choose, and help their
customers do their jobs more effectively and more efficiently or help their
business obtain better results more easily, etc. Someone could write a bad
program in C# just as easily as they could in VB. They can also write a
good program in either language.

Robin S.

 

[Scott M.]

If you don't understand what I'm saying, it is clear you haven't used both
languages for more than 5 minutes. There is no contradiction in what I'm
saying if you have experienced both. Instead of being so stubborn, maybe
you could ask yourself why all the other responses to you on this contradict
what you're saying. Maybe there's something to what we're saying that you
haven't experienced yet?

Also, since you indicated that C# 2005 has the full dynamic compilation that
VB .NET has, I took you at your word, but now I see other posts indicating
that it still doesn't have the same level (which is what my understanding
was).

It seems very clear that you just don't know what you are talking about here
Goran.

 

[Scott M.]

"I regularly write small pieces of code in VB.NET to try them out. Not
enough to notice any difference in the background compilation, though."

Well, there you go...Just my point. Why be so stubborn when others, who do
have the experience to make such a comparison tell you you are wrong?

Goran,

You surely should try VB.Net once.

I regularly write small pieces of code in VB.NET to try them out. Not
enough to notice any difference in the background compilation, though.

There is some checking in C#, however for somebody who knows what VB.Net
does, it is really nothing.

As you have seen am I a not always a correct typer (but very quick), I
assume that I build a C# program at least 5 times more than a VB.Net
program.

I do mostly web development. I don't even have to build it to run it.

 

[Scott M.]

Just to concur and to re-inforce something I mentioned earlier...

In VB.NET, you will know what potential compilation errors await you as soon
as you move off the line you just typed. With Option Strict set to On (not
the default), there really isn't too much left to chance when it comes to
the dynamic compilation that VB.NET gives you on the fly.

But, with C#, you really MUST manually build your app. to see what problems
you have. Many complilation issues will not show up at all automatically in
C#.

Then you are judging something of which you have no experience. I have
written a handful of apps in VB, then turned around and rewritten the same
applications in C# for the experience, and I can promise you, the
"auto-compile-as-you-type" function in VB is a *lot* more dynamic and
fully-functional than the one in C#.

Robin S.
-----------------------------------------------

 

[RobinS]

Hi Robin: I realize your question was directed to Göran but I thought
I'd take a stab at it since you seem like a reasonable person.

It depends on how you define "reasonable". If you define it as someone who
agrees with you, than I'm probably not as reasonable as you would like.

Notwithstanding your attempts in microsoft.public.dotnet.general to get
people to stop posting questions about why their modem won't dial and
such

I always wonder what people think about me doing that. If people think that
is an inappropriate response, I can certainly stop. It is my compassion for
people who need help that encourages me.

If I knew zippo about computers (as is the case with most of those people),
and posted a question in the only place I could figure out how to post one
(the first "General Discussions" occurrence under the dropdown in the
Microsoft Discussion Group site), and nobody helped me or redirected me to
somewhere I could get help, I would be really frustrated. And unhelped.

But if people think I should stop doing that, I will. I know you stuck a
smiley face on that comment, but you must have some real feeling behind it
to mention it.

LA and Smog

I don't agree with your analogy, if you are comparing VB to LA. You can't
really escape the smog in LA. You can escape poor coding in VB.

VB syntax is quirky in a number of ways due to it's roots. They may not
seem quirky to a person who has only developed in VB but they are if you
step back and compare it to other languages in an unbiased manner. That
isn't easy, people have preferences and they tend to be passionate about
them.

Calling a function of a language "quirky" seems terribly judgmental.
Someone else could deem C# quirky in that it does not require curly braces
if there is only one sentence in an If/EndIf statement.

(Please don't waste your breath arguing about whether that's quirky or not.
I didn't say it was quirky. I said someone else could deem it so.) That's a
matter of opinion. Quirky could also be redefined as "language-specific".

You've no doubt read a few of the threads here where the topic is LEN()
or UCASE(). If a person (let's say me) suggests the syntax is dated (and
goes out on a limb and suggests it was only retained to placate the VB6
folk) that doesn't translate into "VB.Net is stupid". It could even be
interpreted as "you'd get more respect (if C# is considered as a language
that gets more respect) if the things that made it seem like a "toy
language" (those aren't my words) were eliminated."

This comes across as really condescending. Microsoft has a real problem
with all of the VB6 work out there that has not been converted to VB.Net,
even 6 years after its introduction. You can think of it as placating, but
it can also be a business decision to not remove the "shortcuts" that are
imbedded all over the place, in order to make it (infinitesimally) easier
to move applications to .Net.

You could argue that they should have changed the functionality of And and
Or to "AndAlso" and "OrElse" by default. But that would also have had a
huge impact on the conversion of VB6 code.

And before you throw the hammer at me, I will admit that I use the .Net
methods rather than the VB shortcuts. I do this because I program in both
VB and C#, and it is easier for me to switch back and forth.

Everything in life doesn't have to come down to a language war. One can
like Java fundamentally yet program in VB.Net for economic reasons and
should be able to point out "that's odd" without being asked to leave a
public newsgroup. The alternative to rational discussion is embodied in
"the cult of VB6 developer" where everybody must chant the same thing or
be branded a heretic. People have attempted to pull that nonsense here
but I believe the days of yelling "he's a witch" and having that work
have (thankfully) passed.

I don't remember ever feeling like I had to agree with everybody else or I
would be tossed out of the group. I think there are different ways to
disagree or to have a problem with a language. I don't think everybody has
to agree. I guess I try to be mindful of other people's choices, and know
that just because I don't agree with it, it doesn't mean I'm 100% right.

If I talk to a SmallTalk developer (and I have) and they proclaim there
is no better language on the face of the planet I tend to doubt them.
Perhaps there isn't for the type of software they write but by definition
this can't be the universal case. If there was no language betterin
every case there would be no other languages.

Well, there may not be any better language on the face of the planet for
that developer. I can respect that and disagree with them without being
condescending about their choice.

Do you still think I'm reasonable?

Robin S.

 

[RobinS]

I don't live here. I just come to visit for the people.

LOL.

Robin S.

 

[RobinS]

My point is that I like the way it is done in VB.Net and in my eyes.
VB.Net is the start of a new generation of programming languages. While
C# is the end of the C generartion. As forever people need time to get
use to it, but I have the believe that it will be like that as soon as
the shorter develop time becomes also vissible at management level. (And
again I don't see it as a successor from VB6, it adopted only some good
things from that although it took much more from C++)

Cor,

That's a nice pipe dream, but it's more likely to be the other way around,
and is encouraged by Microsoft's continuing to publish all samples in C#,
but not as many in VB. At the Vista launch, even their examples of Office
programming were written in C#, and I think pretty much everyone agrees
that doing Office stuff is easier in VB.

In the new WPF, there are things that work in C#, but if you write them in
VB, they don't. I'm sure these are just bugs in the compiler (the one I
found was), but that pretty much indicates they aren't doing as much
testing on the VB side as on the C# side. And good luck finding a WPF book
in VB.

I agree that you can write apps in VB faster -- the
compiling-as-you-go-along really helps. (This was discussed in another
thread). I also don't have to stop as often and fix my case because it's
not case sensitive.

I did recently read that 40% of businesses use VB.Net. But if Microsoft
does not begin to demonstrate as much support for VB as it does for C#,
there's no telling what the long-term outlook is, even for them. They need
to step up and do something, or all those VB6 apps out there are still
going to be there when they've changed .Net to yet another marketing
moniker.

(Not that I'm cynical. ;-)

Robin S.

 

[RobinS]

You can't even fix the line in C# and see if you fixed it right w/o
re-building. Drives me nuts.

Robin S.
----------------------

Just to concur and to re-inforce something I mentioned earlier...

In VB.NET, you will know what potential compilation errors await you as
soon as you move off the line you just typed. With Option Strict set to
On (not the default), there really isn't too much left to chance when it
comes to the dynamic compilation that VB.NET gives you on the fly.

But, with C#, you really MUST manually build your app. to see what
problems you have. Many complilation issues will not show up at all
automatically in C#.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

To me, you come across derisive of VB and sure that there is nothing that
can be done as well in VB as it is in C#.

Derisive? Do you really think so? Why?

The difference between what you can do in C# and VB.NET is truly very
small, and that is not at all the base for my opinion of the language.

You may not *think* that means
you don't think less of VB programmers, but there is an implicit judgment
in there.

You are right that we always face the risk to judge people by the
language they use, but I try to make the distinction between the
language and the people that uses the language.

I know at least that I place far more value in how a person uses a
language than in what language the person uses.

I hang out in the C# group, and am not judgmental or derisive about C#. And
yes, I could be if I wanted to, but I think it's disrespectful of other
peoples' choices.

Do you really think that I am judgmental and derisive? Have you read any
of the posts I have written in the group, or are you just grounding that
on the few lines that I have written in this thread?

To me, it's like standing in a place of worship and vocally deriding the
religion therein. Judging by how strongly some people feel about their
language of choice, I don't think that's far off the mark. ;-)

I rarely get into discussion about languages. In this case I answered to
a direct question about the language, and I thought that my opinion
would be helpful coming from someone who isn't part of the religion.

I didn't even mention C# in my first answer. It was only my opinion of
VB.NET and not compared to any other specific language at all.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Everyone said that there were no background compilation in C#, and only
because I was so stubborn, now everyone is only talking about the
difference in the background compilation.

That means that I was really right from the start. There is background
compilation in C#, despite what everybody with "the experience" said,
and there is only a difference in what it does.

"I regularly write small pieces of code in VB.NET to try them out. Not
enough to notice any difference in the background compilation, though."

Well, there you go...Just my point. Why be so stubborn when others, who do
have the experience to make such a comparison tell you you are wrong?

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

I am only saying that there is backgrond compilation in C#, which
everybody first denied. Do you say that I have no experience of
programming in C#?

Then you are judging something of which you have no experience. I have
written a handful of apps in VB, then turned around and rewritten the same
applications in C# for the experience, and I can promise you, the
"auto-compile-as-you-type" function in VB is a *lot* more dynamic and
fully-functional than the one in C#.

Robin S.
-----------------------------------------------

 

[Michael D. Ober]

Cor,

That's a nice pipe dream, but it's more likely to be the other way around,
and is encouraged by Microsoft's continuing to publish all samples in C#,
but not as many in VB. At the Vista launch, even their examples of Office
programming were written in C#, and I think pretty much everyone agrees
that doing Office stuff is easier in VB.

In the new WPF, there are things that work in C#, but if you write them in
VB, they don't. I'm sure these are just bugs in the compiler (the one I
found was), but that pretty much indicates they aren't doing as much
testing on the VB side as on the C# side. And good luck finding a WPF book
in VB.

I agree that you can write apps in VB faster -- the
compiling-as-you-go-along really helps. (This was discussed in another
thread). I also don't have to stop as often and fix my case because it's
not case sensitive.

I did recently read that 40% of businesses use VB.Net. But if Microsoft
does not begin to demonstrate as much support for VB as it does for C#,
there's no telling what the long-term outlook is, even for them. They need
to step up and do something, or all those VB6 apps out there are still
going to be there when they've changed .Net to yet another marketing
moniker.

(Not that I'm cynical. ;-)

Robin S.

I suspect the WPF problems are more a case of MS running so far behind on
Vista that they cut corners on the new dotNet libraries. I do agree,
however, that unless MS starts treating VB as a first class language,
business developers will start moving away from VB, which also means that
they may simply move away from MS development languages all together.

Mike Ober.

 

[Michael D. Ober]

The background compilation in C# appears to be limited to the current source
file. In VB, it is the entire project, which is a lot more useful.

Mike Ober.

Everyone said that there were no background compilation in C#, and only
because I was so stubborn, now everyone is only talking about the
difference in the background compilation.

That means that I was really right from the start. There is background
compilation in C#, despite what everybody with "the experience" said, and
there is only a difference in what it does.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

If you don't understand what I'm saying, it is clear you haven't used both
languages for more than 5 minutes.

No, I don't have any problem understanding what you are saying. I just
can't understand the reasoning in how you first say that there is no
background compilation in C#, and then go on to compare how the
background compilation works in C# and VB.NET.

It's like saying that you don't have a dog, and besides it doesn't bark
that much anyway...

There is no contradiction in what I'm
saying if you have experienced both.

You don't have to have any programming experience at all to see the
contradiction.

Instead of being so stubborn, maybe
you could ask yourself why all the other responses to you on this contradict
what you're saying.

Funny how every first denied that there was background compilation in
C#, but now confirms that it's there by discussing how it works.

Maybe there's something to what we're saying that you
haven't experienced yet?

I'm only saying that there is background compialtion in C#, do you
really think that I haven't experienced that?

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Ouch! The scenario showed in your example is a major trap.


<snip>

I was not aware of the *impractical* effect shown above. The fact is
that variables get initializaded to default values all at once in the
stack frame (even the ones that will be actually declared later,
inside a block). The code you showed uses a side effect of this. =P

Point taken.

Regards,

Branco.

This is the documented behavior of variables in VB.

Mike Ober.

Yes. It's just not that obvious that it works that way. Without my
experience in assembler programming I would have a hard time explaining
why it works exactly as it does.