Is VB Caca??

[Herfried K. Wagner [MVP]]

If the VB developer is onto the greatest thing since sliced bread it seem
that the Java, C#, C++, et. al. crowds should be the one worrying about
the survival of the language they use or is that not logical?

The proposition is wrong.

They're looking for business solutions not language superiority arguments
don't you think?

They can use different tools to get the solution. That's why it's important
to know the characteristics and features of the tools. Note that I do not
claim that these pro/contra arguments are the only things the decision
should be based on.

 

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

Göran,



A baby carriage may have wheels, but this doesn't make it a car.

So because it's not a car, the wheels won't turn, because that is what
they do on a car?

No, it isn't, at least not when speaking to people from Microsoft.

Here is an older article written by Paul Vick about background
compilation (#1 Google hits on the term "background compilation",
followed by lots of articles about VB (and the lack of background
compilation in C#)):

<URL:http://www.panopticoncentral.net/archive/2004/02/25/276.aspx>
<URL:http://www.panopticoncentral.net/archive/2004/03/19/291.aspx>

Right, older. 2004 < 2005. If you limit the discussion to Visual Studio
2003 they may be relevant.

However, the term is used for a completely different feature in at least
one paper (<URL:http://portal.acm.org/citation.cfm?id=902398>).

That is about background compilation during runtime. That is totally
unrelated.

 

[Cor Ligthert [MVP]]

Goran,

So because it's not a car, the wheels won't turn, because that is what
they do on a car?

This is an analogy:

Your contribution in this thread have more and more the same effect what
moving wheels in the country from Herfried often do.

Cor

 

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

Goran,

You write in this thread exactly the same words as were done by the people
who could not believe that the disk could replace the punch card.

What words? That it should not be used in a deep scope?

That is no
analogy, it is an historical fact of exactly the same behaviour as you show
now in this business.

What behaviour? Presenting examples that prove exactly what I am talking
about?

What is your goal by this than only showing that you have a very
conservative mind.

As I have seen before, you invent your own "truth" without anything at
all to back it up.

My purpose is to present the possibility that what you regard only as a
feature of VB.NET and a shortcoming of C# is not only that, but that
there might be a reason why it works differently in C#, and that the
automagic things that VB.NET does comes with a risk.

You have showed this already enough to us, the problem
for us is however, that we will think about possibilities with our tools for
the future and for that use this newsgroup to communicate about.

If you only see the possibilities with a solution and never consider
that there might be a backside to it, you are not fully equiped to
select the best solution to a problem and how that solution should be
implemented.

Please keep your ideas about VB.Net for your own, until you have made
programs with it longer than 25 hours a week.

So I would have to work with VB.NET more than 25 hours a week to be
allowed to talk about it? That's riddiculous.

For the rest you are forever
welcome here with positive ideas or questions.

Thanks, I guess? What would "the rest" be?

 

[Zim Babwe]

Isn't this a public forum? I think he or anyone should be able to speak
about VB.NET and share ideas no matter how many hours they work with it. So
If I say that I work with VB.NET for 23 hours, my comments are not welcome?

Goran,

You write in this thread exactly the same words as were done by the people
who could not believe that the disk could replace the punch card. That is
no analogy, it is an historical fact of exactly the same behaviour as you
show now in this business.

What is your goal by this than only showing that you have a very
conservative mind. You have showed this already enough to us, the problem
for us is however, that we will think about possibilities with our tools
for the future and for that use this newsgroup to communicate about.

Please keep your ideas about VB.Net for your own, until you have made
programs with it longer than 25 hours a week. For the rest you are forever
welcome here with positive ideas or questions.

Cor

 

[Brian Gideon]

The code I made for C# which is exactly the same in VB.Net, will not compile
in C#, while I don't understand why and can only see legancy
impossibilities.

We will probably see a lot of message which will show that the C# method is
better, but the same kind of message I have already read a while ago about
the puchcard which was better than the hard disk because it was by instance
better transportable.

It has do with the concept of definite assignment which is a very
deliberate inclusion and discussed in detail in section 12.3 of the C#
specification (ECMA version). I do happen to think it is better.

 

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

Unlike some in this newsgroup, I don't feel a need to go back through all
of your postings and produce examples.

Respect for that.

There is enough of that feeling to
your posts that when I see your name, I think to myself, "This should be
interesting." Mind you, that doesn't make it true or not true, just my
perception. I'll try to pay better attention. Maybe I am misconstruing your
intent.

Yes, I can see how you get that feeling from some of my posts. I like
the debate (which I admit is a bit risky), and I can argue strongly when
I feel that there is a deeper truth that would benefit from being revieled.

I try to keep opinions in threads that are about opinions, though, and I
think that you have to admit that in other threads you couldn't even
tell that I have written a single line of C# in my life.

So, speaking in examples and not quoting anybody directly, would you sah
that saying, "I think VB.Net is stupid" is not as bad as saying "I think VB
is stupider than C#"?

I think that you can express an opinion about a language without
absolutely having to comparing it to any other language. For example,
there are things about VBScript that I think sucks big time, but that
doesn't mean that JScript has to be any better at it.

Also, if I avoid comparing VB.NET to a specific language, I can
implicitly compare it to languages like Pascal, Turbo Pascal, Delphi, C,
C++, Cobol, Fortran, BASIC, GFA Basic, ST Basic, GW Basic, Comal,
VBScript, JScript, Javascript, VBA, VB 6 and C#. I think that it gives
quite a wider perspective.

I'm very entertained by the whole discussion. I try not to take it too
seriously. I happen to think there are a lot of brilliant people posting in
the newsgroups, a lot of different personalities, and I enjoy reading the
posts immensely. I may be occasionally annoyed or amused, but have only
truly been offended by one person (and I'm sure everybody knows who that
is).

So keep one throwing those opinions and advice and wisdom out there, and
I'll keep reading them.

Wise words. I will also continue to try to keep it on a level where it
might be enjoyable to read and participate.

 

[Herfried K. Wagner [MVP]]

Göran,

So because it's not a car, the wheels won't turn, because that is what
they do on a car?

I wanted to show that it's not allowed to infer the same reason from
similarities two systems have.

C#'s syntax checking and VB's background compilation may have similarities
(the first is actually a small subset of the latter), but this doesn't make
syntax checking the same as full background compilation.

Right, older. 2004 < 2005. If you limit the discussion to Visual Studio
2003 they may be relevant.


That is about background compilation during runtime. That is totally
unrelated.

In both cases that's not the point. I claim that "background compilation"
is currently only available in VB and not in C#, you claim that it's
available in both programming languages. That's why I took a look at how
the term is commonly used in practice (which is the way I am using it).

 

[Tom Leylan]

Re: background compiling

I would not say that C# does what VB.Net does in this regard. It does
*not* do the same background compilation. In fact, I would say it's very
minimal in comparison.

We all realize that Visual Studio is not the VB.Net language right? VB.Net
doesn't do background compiling in any other editor that I'm aware of.

I'd say there is a very good chance that many C# developers have never used
Visual Studio. It isn't a requirement and (again so far as I know) isn't
available for Linux but C# the language is.

Nobody has even once suggested that background compiling isn't cool and
useful. The thread title isn't "is Visual Studio Caca??"

 

[Tom Leylan]

Good information. As I suggested to Herfried if the VB community is going
to grouse about how they are perceived it might be in their best interest to
do something to change that perception. All the unsupported claims that
"Microsoft had better hurry up" and the speculation that VB developers may
go elsewhere aren't helping matters. Nobody is threatened by all the VB
developers jumping ship to Java because frankly it isn't going to happen.

So here is my guess... in the next month 3 or 4 more sites will appear on
the Internet dedicated to "VB code snippets" and no new sites will appear
that demonstrate the advantages of VB.Net to corporate IT departments.

 

[Herfried K. Wagner [MVP]]

Tom,

Re: background compiling


We all realize that Visual Studio is not the VB.Net language right?
VB.Net doesn't do background compiling in any other editor that I'm aware
of.

You are really splitting hairs. We're here in a Microsoft Public Newsgroup
about VB.NET. It's likely that almost anybody here uses Microsoft's IDE for
VB.

I'd say there is a very good chance that many C# developers have never
used Visual Studio. It isn't a requirement and (again so far as I know)
isn't available for Linux but C# the language is.

That's true, but does that change anything? The most commonly used IDE for
VB supports background compilation whereas the most commonly used IDE for C#
doesn't. That's a pure fact, nothing more and less. It doesn't even
implicate that there are no other IDEs for the both languages and that these
IDEs may behave differently from VS.

Nobody has even once suggested that background compiling isn't cool and
useful. The thread title isn't "is Visual Studio Caca??"

It's the second time in this thread I realize that you attempt to change its
topic by insisting on secondary problems being the primary problem.

 

[Tom Leylan]

They can use different tools to get the solution. That's why it's
important to know the characteristics and features of the tools. Note
that I do not claim that these pro/contra arguments are the only things
the decision should be based on.

Okay then I'm confused. Could you put it into a few sentences so we can
understand why (according to Cor) it is so much faster to write in VB.Net
and according to others it is easier and to others still it is as powerful
and the developers can be had for less money... uh, why is that there is a
perception that C# is used in corporate development rather than VB.Net?

Let's turn the thread into something positive for once... what criteria
should a company use to determine whether to convert an existing project to
C# or to VB.Net? Are these similar or different than if they are starting a
new project?

 

[Tom Leylan]

C#'s syntax checking and VB's background compilation may have similarities
(the first is actually a small subset of the latter), but this doesn't
make syntax checking the same as full background compilation.

In both cases that's not the point. I claim that "background compilation"
is currently only available in VB and not in C#, you claim that it's
available in both programming languages. That's why I took a look at how
the term is commonly used in practice (which is the way I am using it).

It's not part of the language. Neither language background compiles in the
Linux implementations does it?

 

[Herfried K. Wagner [MVP]]

Good information. As I suggested to Herfried if the VB community is going
to grouse about how they are perceived it might be in their best interest
to
do something to change that perception. All the unsupported claims that
"Microsoft had better hurry up" and the speculation that VB developers may
go elsewhere aren't helping matters. Nobody is threatened by all the VB
developers jumping ship to Java because frankly it isn't going to happen.

So here is my guess... in the next month 3 or 4 more sites will appear on
the Internet dedicated to "VB code snippets" and no new sites will appear
that demonstrate the advantages of VB.Net to corporate IT departments.

Although I like many details in VB.NET, I am not a "VB evangelist", but
instead I am one of its strongest critics too. I do not want to sell VB
because it's simply not my job. I do not identify myself with VB. Like
many other VB users I am using VB as my tool but I do not make the decision
which tool to use an ideological decision as users of other programming
languages do. I always felt disgust when reading those Java, <insert any
language here> "advocacy" pages, which often consist only of irrational
points. Being an engineer I prefer to be aware of a system's strengths and
weaknesses. It doesn't make me feel better if I "fight" for my preferred
programming language by denying its weaknesses.

 

[Tom Leylan]

That's true, but does that change anything? The most commonly used IDE
for VB supports background compilation whereas the most commonly used IDE
for C# doesn't. That's a pure fact, nothing more and less. It doesn't
even implicate that there are no other IDEs for the both languages and
that these IDEs may behave differently from VS.

And if no other language on Earth does it you still claim that VB.Net is
getting passed over. So again I ask you "why?" Could it be that nobody
really gives a hoot when it comes down to it, that while it's a nice feature
perhaps it doesn't really impact the bottom-line?

Since I'm sure I'm mistaken with my guess (as always) simply post the
answer, why aren't more companies standardizing on VB.Net?

It's the second time in this thread I realize that you attempt to change
its topic by insisting on secondary problems being the primary problem.

Remember when I said you seemed reasonable? I was mistaken.

 

[Tom Leylan]

Although I like many details in VB.NET, I am not a "VB evangelist", but
instead I am one of its strongest critics too. I do not want to sell VB
because it's simply not my job.

Whatever... I haven't read any criticism from you re: VB.Net except to
remark how it departed from VB6 in some way which you find "just as good".
But I could be wrong so let's see... what don't you like about VB.Net?

 

[Herfried K. Wagner [MVP]]

Tom,

Okay then I'm confused. Could you put it into a few sentences so we can
understand why (according to Cor) it is so much faster to write in VB.Net
and according to others it is easier and to others still it is as powerful
and the developers can be had for less money... uh, why is that there is a
perception that C# is used in corporate development rather than VB.Net?

I am not Cor and I do not often share his position. In a professional
environment there are much more points which have to be considered when
choosing a certain programming tool (language, library, IDE, ...) than the
number of keystrokes necessary for a certain operation or the charge for a
developer per hour. For example, existing source code, language/library
stability of the language/library vendor, support for the product by the
vendor, maybe language/library standardization, and many other factors
require awareness.

Personally I do not have any numbers about which programming
languages/libraries are used in which percentage of companies. Recently
Forrester Research published a new study
(<URL:http://www.forrester.com/Research/Document/Excerpt/0,7211,41746,00.html>)
which is unfortunately only available for money. The numbers shown in the
study I heard (I did not buy the study) are that Java and VB.NET are used
almost equally, followed after a huge gap by C#, which is directly followed
by VB6. I know the actual numbers shown in the study but I won't publish
them here.

Nevertheless, that's only a study and all of us know that studies can be
flawed.

Let's turn the thread into something positive for once... what criteria
should a company use to determine whether to convert an existing project
to
C# or to VB.Net? Are these similar or different than if they are starting
a
new project?

There are many factors (just some that come in my mind):

* Existing projects and their future (only maintenance and
extension of existing projects, development of new projects, etc.).
* Experience of the developers in the company (depending on
the company's structure).
* Standardization of programming languages, libraries, and tools.
* Qualitative measures of the programming languages, libraries,
and tools compared to each other (e.g. provided features, etc.).
* Quantitative measures of the programming languages, libraries,
and tools compared to each other (e.g. completeness of libraries,
stability, security, time required for certain common jobs, etc.)
* Language, library, and tools stability in the vendor's history.
* Support the language, library, and tools vendor offers.
* Availability of other vendors' libraries, tools, etc. which may
be required.
* Cost of development, maintenance, and support.
* ...

Some of the points are referred to as TCO.

 

[Tom Leylan]

That's technically true, although every time the VB/C# question comes up,
someone invariably posts something to the effect of "VB makes it possible
for you to code in a sloppy manner". As if you couldn't do that in any
other language.

Yes but realize those people could be jerks or to be more politically
correct they may have read a book on the language last year. In short what
they "know" about software development is not the truth any more than if
they picked up a guitar last year and now think they can tell Eric Clapton
or Prince how to play the guitar.

The rejoinder BTW when somebody says "I have 10 years of programming
experience" is; Is that 10 years of programming experience or 1 year of
programming experience 10 times? Too often they have repeated the same bad
habits they learned in year one because "hey, the software worked."

It may seem controversial to write, but if somebody learned VB.Net last year
in college or C# last year in college they have about the same skill set
when it comes to developing software applications which is typically not
much. Clearly whatever knowledge they do have is not based upon dealing
with real-world conditions and deadlines.

If there is a difference to be noted and again it is sure to be
controversial, it would tend to be due to the type of people who have
traditionally been drawn to the various languages. Lots of kids pick up on
BASIC because it was a) free, b) an interpreter. Very few just decided to
try C (they would have to get a compiler first) or assembly language as
getting anything more than your name to print was an effort. Of those that
did try C many routinely brought the computer to a halt by forgetting to
initialize a pointer and they learned very fast where the important parts of
the O/S are stored. If they weren't turned off by all the hassle they got
better and wrote safer code. That wasn't traditionally the path of the
BASIC developer because the language was very forgiving.

That may no longer be the case but I will guess that you will not find too
many C/C++ developers turning to BASIC while you will find some BASIC
developers turning to C/C++ and C#. I know the problem of perception as I
developed apps in Clipper (a dBASE derivative). Most dBASE developers used
public variables all over the place making the code hard to maintain. I
used no public variables but I still had to listen to people explain how
terrible the language was because developers routinely abused it. They were
right people abused it but one didn't have to use public variables simply
because they were there.

Anyway... take care,
Tom

 

[Herfried K. Wagner [MVP]]

Tom,

Whatever... I haven't read any criticism from you re: VB.Net except to
remark how it departed from VB6 in some way which you find "just as good".
But I could be wrong so let's see... what don't you like about VB.Net?

Array support (especially "overloading" '(...)' with many different
functions), some language inconsistencies and redundancy ('Exit Sub' vs.
'Return'), the lack of definite assignment checking, BC42104, automatic
import of modules without an option to turn it off, the lack of support for
inline comments, unclear/weakened semantics of 'Shared' (especially since
the introduction of a warning regarding access of shared members via an
instance), ...

 

[Tom Leylan]

There are many factors (just some that come in my mind):

* Existing projects and their future (only maintenance and
extension of existing projects, development of new projects, etc.).
* Experience of the developers in the company (depending on
the company's structure).
* Standardization of programming languages, libraries, and tools.
* Qualitative measures of the programming languages, libraries,
and tools compared to each other (e.g. provided features, etc.).
* Quantitative measures of the programming languages, libraries,
and tools compared to each other (e.g. completeness of libraries,
stability, security, time required for certain common jobs, etc.)
* Language, library, and tools stability in the vendor's history.
* Support the language, library, and tools vendor offers.
* Availability of other vendors' libraries, tools, etc. which may
be required.
* Cost of development, maintenance, and support.

See the thread could have been turned around into something "informative"
rather than the extent to which background compiling is incorporated into
various tools. Discussion rather than arguments.