VB6 easier than VB.NET?

[Mitchell S. Honnert]

In some recent posts, I've seen people who seem to be waxing nostalgic with
respect to the "ease of use" of Visual Basic 6. I can't quite put my finger
on it, but they seem to be implying that VB6 was simpler to use than VB.NET,
that it was somehow easier to write programs in VB6 than in VB.NET. I have
to admit I'm astonished by this attitude. I can't see any rationality to
the idea that, on the whole, VB6 is easier than VB.NET.

I *can* see where someone who is entrenched in the VB6 language would find
the switch to VB.NET daunting. (VB.NET is, after all, a major departure
from VB6.) But what I can't see is someone making the judgment, from an
objective standpoint, that VB6 is easier than VB.NET. In other words, just
because *you* happen to be so much more familiar with the collective set of
eccentricities, peculiarities, and inconsistencies that is known as Visual
Basic 6 that you can write applications faster in VB6 than VB.NET, it
doesn't mean that VB6 is easier.

I've heard it argued that a drawback to .NET's full support of object
oriented programming is that it makes coding more difficult. "I just want
to get in there and write some code; I don't want to have to worry about all
of that OO crap." Perhaps the principle holds true for the "Hello World"
type of application, but for any non-trivial application, I just don't see
how the well-ordered, clean, and consistent implementation of OO principles
in the .NET framework couldn't be seen as an easier environment in which to
develop.

I guess I'm looking at it from the perspective of teaching someone who is
completely new to programming how to be a programmer. In this case, which
would be easier, VB6 or VB.NET? There's not doubt in my mind that VB.NET
would be easier. In my opinion, in a relatively short period of time, I
could teach someone the principles of object oriented programming and the
basic layout of the .NET Framework. But if I applied this same amount of
time to teaching someone VB6 from scratch, I'd get so bogged down in telling
them about all of the quirks, workarounds, and exceptions-to-the-rule that
I'd run out of time before I could even get through the basics. (I wouldn't
even want to call this type of knowledge transfer "teaching".)

The point is that even though there might be an initially steeper learning
curve to get past the principles of object oriented programming, once you
have the "OO epiphany" and truly grok the principles, the rest is smooth
sailing. But with VB6, you may get up and running a bit faster, but your
daily process of coding is so taken up by finding workarounds to a seemingly
endless series of quirky behaviors or things that just don't operate how you
think they would, that the overall development time is actually much longer.

So, are there people out there that really think VB6 is easier than VB.NET?
Why? Do you think it depends on the size of the project? Are there other
factors? Help me understand because I just don't get this attitude.

- Mitchell S. Honnert

[Herfried K. Wagner [MVP]]

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb:

"If you spend the money to upgrade to VB.NET, well, you just spent a lot
of money to stand still." I admit that I haven't read the entire article, but this particular quote
is patently ridiculous. Even if you only duplicate existing functionality
in the new VB.NET application, you have gained the ability to take
advantage of all of VB.NET's features.

It seems that you missed the point. Code which has been tested for more
than one decade will rarely be changed or extended. It just works. There
is no need for VB.NET's features (which are in many cases limited and
different compared to VB6's features, for example, the lack of arbitrary
array bounds in .NET), a rewrite would cost a lot (about 60 percent of
original development cost) and would introduce new bugs, which cannot be
accepted in real-world application. There actually are valid reasons why
COBOL code which is decades old is still used in banking and for financial
transactions. A rewrite would hold a risk.
For any future development, you have the new IDE, you have the ease of
extending an OO application, you have all of the other myriad of benefits
that VB.NET has over VB6. (Not to mention, all of the benefits that would
come from redesigning the underlying code.)

For new projects it's always a good idea to use state-of-the-art tools.
However, this doesn't imply that it's always the best solution to rewrite
the existing code. That's rarely a good solution because of cost and risk,
and should be avoided whenever possible.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Mitchell S. Honnert]

>Companies shouldn't have to care about the technology, only the

results that are produced. If you are referring to an indifference to what the underlying code at the
expense of the end result (say, from the end-users perspective), I would
have to disagree. I think that what a purely results-focused model does not
properly account is maintenance. Yes, you may have a VB6 system and a
VB.NET system that are functionally identical, but I believe that the VB.NET
code would be much easier to maintain and support. If for no other reason
than today it's more likely you'll be able to find a programmer who can (and
wants to) program in VB.NET. So, to be cost-effective, a company *does*
have to be concerned with the technology, at least in this respect.
The main point I was trying to make is that classic VB was (sorry, is) a
tool that creates solutions rapidly (RAD), and a degree in computer
programming was not required. Thus it allowed people to produce RESULTS
for
their company quickly and inexpensively (sorry again, cost effectively)
even
if the METHOD (the actual code) used wasn't optimal. This brings up the distinction inexpensive and cost-effective again. I
think that VB6, in may ways, gave a false sense of empowerment to the
dilettante programmer. It made them think they were easilly (there's that
word "easy" again) creating a working program, but what they were really
creating was the worst kind of program there is, one that looks like it's
working properly but isn't. On the other hand, I personally believe that
the same thing could be said of VB.NET. I don't think this condition is
particular to VB6. The point is that just because something is inexpensive,
doesn't mean that it's cost-effective. If the guy in accounting whips out a
quick little intra-office app which turns out to have been giving incorrect
data for a year, is that really inexpensive in the long run?

It's interesting to note that many C# developers think that any form of
Visual Basic is for the dilettante programmer and that we "know just enough
to get in trouble". They are apparently of the mindset that it's better to
obfuscate the language itself to discourage the "unwashed masses" from
interfering in "their" realm.

- Mitchell S. Honnert
"Keith Seeley" <ks*****@worldnet.att.net> wrote in message
news:mJ****************@bgtnsc04-news.ops.worldnet.att.net... Hi Stephany,

The same type of situation occured early last century when companies were
dragged kicking and screaming from using horse-drawn transport to

motorised

transport. Regardless of the rights, wrongs or indifferences of it, it
happened. Those that embraced motorised transport tended to propsper and
those that didn't saw their profits dwindle until they did. Did the world
stop turning? No!

Pespective. Companies shouldn't have to care about the technology, only
the
results that are produced.
Motorized transport produced better results than horse drawn carriages and
as such replaced the older technology. Will VB.net produce better RESULTS
for the customer? AFAIK VB.net changes the METHOD to produce software,
not
the results PRODUCED by the software. And that METHOD requires a greater
skill set than classic VB. 1+1= 2 and in any language.

The main point I was trying to make is that classic VB was (sorry, is) a
tool that creates solutions rapidly (RAD), and a degree in computer
programming was not required. Thus it allowed people to produce RESULTS
for
their company quickly and inexpensively (sorry again, cost effectively)
even
if the METHOD (the actual code) used wasn't optimal. Classic VB
accomplished this by hiding much of the underlying technical details from
the programmer. VB.net may fit this bill (not from what I've seen yet),
but
it appears that the product requires a lot MORE knowledge of what goes on
under the hood than classic VB. And as I stated previously, this isn't
necessarily a bad thing but what it does is take the tool away from casual
programmers ("bad" programmers according to some).

In your penultimate paragraph you allude to 'VB Classic' being phased
out.
I'm interested as to what inside information you have that the rest of us
aren't privy to. We are all aware that mainstream for VB6 ceases as at
the
the end of this month but I have not seen any information about VB6 being
phased out any earlier than planned. The whole point is that VB6 is NOT
being taken away, anyone who uses it today will still be able to use it

next

month, and that nobody is being FORCED to change. Those that want to

change

can and those that don't, (having been made aware of the situation and
therefore making their decision on an infomed basis), can continue on as
they do now.

Perspective. MS chose to stop development of an excellent tool for casual
programmers that allowed them to "cost effectively" produce results for
their employer. The replacement tool requires more in-depth knowledge of
"real" programming and I suspect it will not be as accessible as classic
VB.
The result is that more companies will have to hire professional
developers
to do their work, which is an expenditure that previously didn't exist.
VB.net will mean more $$$ to small businesses who DO want to keep up with
current technology. In this respect, companies WILL be FORCED to spend
more
money to keep up with the "latest and greatest", even though the RESULTS
produced will be no different than before.

Perspective. It's about the RESULTS for the CUSTOMER, not about the
details
of being a professional programmer. I realize it's tough for the
participants of this group to understand, but there are many people who do
NOT program for a living yet do so anyway to achive results for their
employers. It's these people and their companies who are losing big
time -
their tool is being phased out and they will have to hire someone to do
the
work for them. Good for you folks, bad for them.

[Mitchell S. Honnert]

> It seems that you missed the point. Code which has been tested for more

than one decade will rarely be changed or extended. It just works. There
is no need for VB.NET's features How does the above statement relate to my critisism of the "stand still"
quote? As I stated in my post, I know that it does not make economic sense
in all cases to convert VB6 code to VB.NET code. But what the quote
indicates is that it NEVER makes sense. My point is that and upgrade could
make sense in the case where you would have to do any kind of enhancement or
perhaps even very regular maintenance.

- Mitchell S. Honnert
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Ox*************@TK2MSFTNGP09.phx.gbl... "Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb:

"If you spend the money to upgrade to VB.NET, well, you just spent a lot
of money to stand still."

I admit that I haven't read the entire article, but this particular quote
is patently ridiculous. Even if you only duplicate existing
functionality in the new VB.NET application, you have gained the ability
to take advantage of all of VB.NET's features.

It seems that you missed the point. Code which has been tested for more
than one decade will rarely be changed or extended. It just works. There
is no need for VB.NET's features (which are in many cases limited and
different compared to VB6's features, for example, the lack of arbitrary
array bounds in .NET), a rewrite would cost a lot (about 60 percent of
original development cost) and would introduce new bugs, which cannot be
accepted in real-world application. There actually are valid reasons why
COBOL code which is decades old is still used in banking and for financial
transactions. A rewrite would hold a risk.

For any future development, you have the new IDE, you have the ease of
extending an OO application, you have all of the other myriad of benefits
that VB.NET has over VB6. (Not to mention, all of the benefits that
would come from redesigning the underlying code.)

For new projects it's always a good idea to use state-of-the-art tools.
However, this doesn't imply that it's always the best solution to rewrite
the existing code. That's rarely a good solution because of cost and
risk, and should be avoided whenever possible.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Cor Ligthert]

Herfried,

There actually are valid reasons why COBOL code which is decades old is
still used in banking and for financial transactions. A rewrite would hold
a risk.
Good point, what I did not expect from you (that very positive meant) ,
however see my other message at the end of this thread.
For new projects it's always a good idea to use state-of-the-art tools.
However, this doesn't imply that it's always the best solution to rewrite
the existing code. That's rarely a good solution because of cost and
risk, and should be avoided whenever possible.

I agree as well, see the same message.

Cor

[Michael C#]

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

It's interesting to note that many C# developers think that any form of
Visual Basic is for the dilettante programmer and that we "know just
enough to get in trouble". They are apparently of the mindset that it's
better to obfuscate the language itself to discourage the "unwashed
masses" from interfering in "their" realm.

I come from a very strong background in C-style languages (C, C++, etc.),
and to be honest the only work I did with VB6 was for Quick & Dirty
throwaway applications that had to have a cute little interface. That's not
to say that others haven't developed great programs with VB6, I just didn't
feel like fighting it to get the performance I needed for the apps I was
developing, or distributing the VB6 Run-Time library DLL's with each and
every app.

Personally, I find the C-style syntax of C# to be simpler without all the
extraneous reserved words and special keyword combos to begin and end
decision and looping structures. I also find it to be more precise, which I
think helps avoid errors. My feelings have nothing to do with discouraging
the "persecuted masses" from learning anything they care to learn. In fact,
I think that .NET presents a great opportunity for VB programmers to learn
C-style syntax (those who want to anyway), since VB.NET and C#.NET are
virtually interchangeable. If you understand how a routine works in VB.NET,
you can easily transpose that knowledge to a smiliar C#.NET routine.

So interfere in the realm! And if you want true obfuscation, write Perl.

[Keith Seeley]

:) I recall that these were exactly the words being yelled in VB3 user
groups when VB4 was released (there wasn't much of an internet back then to it was human to human and a few BBSes). So much anger so much fear and in
the end so untrue. We all thought - Including ME - that VB3 was the perfect tool and that nothing could beat it and that ActiveX was a scam. We were
"FORCED" to move up to VB4.

Sorry, but that's not what I'm saying. Let me try to clarify once more.
I believe that:
- VB.net, as a programming environment, IS better than VB6.
- .Net unifies the world of MS Windows programming to a level not previously
available.
- Productivity will increase in .Net for the professional developer.
- Keeping up with technology is fine as long as there are definite benefits.

OK. Can we move on? Just try to understand what I wrote is from the
perspective of your customers - not as a developer. Way back in the good
ol' days, a typical company's IT budget was minimal and productivity was
"low". As MS Windows took hold, the technology matured and software
solutions increased productivity to levels never seen before. Access to
company information stored in databases made life infinitely easier. But
with this improvement came a large jump in the IT budget. No problem,
better productivity costs more so the higher costs were justified.

Good. Technology improved a company's bottom line. Now, what about .Net?
What improvements does it give a company? What will a program written in
..Net do that previous languages won't? Web-enabled apps? Maybe, but that
certainly won't produce increased profits for every type of business. As I
see it, the only thing .Net does well is improve the developers experience
and, in the end, may make software developement a little quicker.

Now, back to the classic VB issue. My contention is that many companies
utilize their existing personel (non-programmers) to write custom apps that
benefit the company. Unless VB.net (or some other tool) can be used by the
same group of non-professional programmers these companies will have to
increase their IT budget to offset. For the non-accountant types out there,
this is BAD.

Now, this is largely based on my exposure to .Net. I've looked at it and my
impression is that it doesn't hide enough of the low-level stuff to make it
usable to someone who just wants to get the job done quickly.

This is nothing new. .Net is 3 years old, if you haven't yet come up with
your company plan for migration and maintenancne then you've got management problems, not technical problems. Techncally it's just code, like VB3 was
just code three years after VB4 came out ... it's not that hard to port or
keep for developers who realize that porting and maintaining have always
been, and will always be, over 70% of the job for a tech person. (I find
porting to to be a more cost effective result in the end based on my VB3 >
VB456 experience but that's my experienced opinion. Some folks don't like
to work late to grow their careers so maintenance of legacy code more fits
their lifestyles)

Boy, I really hope your 70% figure isn't correct. What company would want
to spend 70% of their IT salaries just to migrate code that produces the
SAME results? Seems like that's great for keeping IT people employed but
not so good financially for the company. You say "cost effective", but from
what perspective? Re-writing an app from the ground up to take advantage of
newer technology vs. porting code from one software version to the next?
Either way, at some point I'd hope that there are improved RESULTS for the
company otherwise programmers are simply spending money to "keep up with the
Jones'".

[Cor Ligthert]

Michael,

I have done many program languages. They are evaluating.

In my opinion does the perfect program languages not yet exist. When you
create it today there are (luckily) better ideas tomorrow.

C# has a lot of not anymore needed legacy. (Don't forget that C is a
language originally from the typewriter and the derived ones have all things
that behaves like that).

However VB has that as well. There are parts in VBNet that are for me a
cruel. (By instance the IIF and the needles "then" word and things as OrElse
while it had been in my opinion easy to change that in the VB6 to VBNet
upgrade).

In my idea are we still not yet on the right program language. If it will be
a C# kind or a VBNet kind. I think that most people who are thinking that,
did not often look after the horizon and will change there minds in future.

I like your contributions in this newsgroup by the way.

Cor

[Mitchell S. Honnert]

I'm won't deny there are examples where some specific functionality was made
more difficult in the converson of VB6 to VB.NET. In my experience,
however, I've found that the vast majority of functions to be easier in
VB.NET. "Experiences may vary" as they say.

- Mitchell S. Honnert
<g9*************@yahoo.com> wrote in message
news:42**************@msnews.microsoft.com...

Look at one specific application, serial I/O.

In VB6 there was the MSComm control that handled the OnComm events.
In VB.Net, there is nothing built in. You can shoe-horn the MSComm
control in; or more recently you could use some of the posted
solutions, but none of the posted solutions are as easy to use as the
MSComm control, in my opinion. Most of the posted solutions that I
have seen only do polling, ...no event generation, which greatly
limits the responsiveness. I've resorted to mixed VB.NET and C
programming for my solution. If I were to write a class, I'd do it in
C++, not VB.NET.

On Thu, 24 Mar 2005 17:04:23 -0500, "Mitchell S. Honnert"

So, are there people out there that really think VB6 is easier than
VB.NET?
Why? Do you think it depends on the size of the project? Are there other
factors? Help me understand because I just don't get this attitude.
- Mitchell S. Honnert

[Herfried K. Wagner [MVP]]

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb:

It seems that you missed the point. Code which has been tested for more
than one decade will rarely be changed or extended. It just works.
There is no need for VB.NET's features

How does the above statement relate to my critisism of the "stand still"
quote? As I stated in my post, I know that it does not make economic
sense in all cases to convert VB6 code to VB.NET code. But what the quote
indicates is that it NEVER makes sense. My point is that and upgrade
could make sense in the case where you would have to do any kind of
enhancement or perhaps even very regular maintenance.

I think that there are no clear borders when conversion makes sense or not,
and the decision depends on each individual project. There are projects
which are 100 % complete and which won't be extended, and there are projects
which are in an early state of development. My comments apply to "perfectly
working systems".

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Richard Myers]

> He did not understand the message

from Stephany, which is for me very clear. That he than tells that he does not understand my messages tells more about his ability with the English
language than about my.

Being able to read English is not the same as being able to understand it.
The fact that you can agree with anything she wrote suggests you have
merely read the text but haven't actually thought about any of it. If you
could "understand" English rather than just "read" English Cor, you might
have noticed that she contextualises her message with "COMFORT ZONE", and
then with this statement

As a species (homo sapien), we are comfortable with what we know. The
inverse is also true - we are NOT comfortable with what we DON'T know.

This truism has been proved again and again throughout the course of history.

she suggests what follows is going to back her so called truism.

Because of this, change tends to resisted, (especially in the early

stages),until such time as there is a widespread understanding of the 'technology'

behind the change.
Change does not "tend to be resisted". It simply isn't always immediately
accepted until its benefits have been sufficiently communicated, witnessed
and understood.
Shes suggesting that Homosapians are Anti-Technology which when given the
world we all live in is a ludicris proposition. Even if her statement were
true it has nothing to do with "comfort zone" and laziness as it does with
an information gap.

In the end, those who 'change' prosper and those who resist, don't. This is the nature of the evolution of the species and the evolution of
technology.

This is complete bullocks. In much the same way as the victor in war tends
to rewrite history to suit themselves, those who do change and fail as a
result of this "early adoption" are simply discarded and forgotten.
Therefore only those who experience success thru change prosper. Change
itself is no guarantee for success. Stephanie seems to be completely blind
to all the change "failures" of which there would be many many more than
change successes..
A case in point is the rise of 'Cro Magnon' as the dominant species which became modern humans and the demise of 'Neandethal' man. The Neanderthal's were, for what ever reason, unable to change and consequently the species did not survive.

What has biological evolution got to do with "comfort zones", vb6 or
vb.net? Can a duck tap play guitar? No. According to Stephanie this makes
the duck "lazy". Its simply staying within its comfort zone. More likely
its because its... just a duck. Being "unable to change" has nothing to do
with being not willing to change even after a better alternative has been
communicated, witnessed and understood.
In the late 18th and early 19th centuries, we saw a movement, known as the Luddites, who bitterly resisted industrialisation of the weaving industry. Not only were they vociferous in their opposition, they went as far as vandalising and destroying the 'modern' weaving machines that were being developed at the time. Can you really imagine where we would be without the range of textiles that we take for granted in our everyday life
if they had succeeded?
Again most of this is just unneccessary dribble. Her whole post reeks of
someone who spent the morning @ a doctors waiting room reading time
magazine/natures journal and now decided that she will tell us all what she
thinks she knows regardless of what the actual topic is. All so she can
make this point
The word 'luddite' has since entered our language to mean someone who unreasonably resists change.

Which is completely out of context. "Unreasonably resists change". Whats
unreasonable about a company with a VB6 library developed over 10 years
using 100s' if not 1000's of man hours to produce, a library which is
*fully* debugged, in production, one that is perhaps even considered a sub
platform for their products and services not converting to dotNet? Sounds
like common sense business logic to me. Sounds very reasoned and well
thought out. As for "comfort zone"....try "livelihood" = mortgage paid,
food in their kids mouths. If they dont need dotNet, or haven;t yet had the
benefits of some dotNet related technologies explained to them, then they
can hardly be called a "Luddite".
More recently we have also seen a trend towards a way of thinking that
kmakes the rights of the individual sacrosant. Don't get me wrong here, the rights of the indivuadual are important! I do, however, find this trend disturbing because the rights of the individual are being attributed a
higher importance than the good of the whole. My view is that being able to enjoy indivdual rights brings obligations that the individual owes to
society as a whole. The latin phrase 'quid pro quo' translated as 'something for something' springs to mind as being appropriate here.
What has any of this passage got to do with anything? If its supposed to
set up some argument that its better for everyone if we move to dotNet then
it failed.
"The rights of the indivdual sacrosanct". Just more my waffle that
completely misses the point that someone using VB6 does not prevent someone
from using dotNet. The greater good is not at all comprimised which should
be very obvious to Stephanie considering that she early postulated that
"those who dont change, wont survive anyway". So shes basically just
contridicting herself.

I dont what shes trying to paraphase here but its just another ridiculous
inclusion that serves no purpose and has nothing to do with vb6, vb.net or
"comfort zones".
During this debate I have seen a lot of hand-wringing, roughly

paraphrased

and reading between the lines as "How dare Microsoft take a business
decision that, in my view, puts the longevity of my personal library of VB6 code at risk" and "How dare Microsoft NOT provide (for free) a mechanism that will automatically convert my personal library of esoteric VB6
procedures into perfect VB.NET code". To those for whom the cap fits - all I can say is "Get off your backsides and join the real world."
Well first off...im not sure of the ergonomics of Stepahines working
environment but it seems a little ambitious to be telling the developer
community to "get off their backsides" and expect a result. Whats more they
are in the "real world", not some Microsofty wet dream whereby everyone
works in some completely standardised homogeneous environment and
immediately upgrades every tme Microsoft releases a new version of product
xxx. You see in the real world Stephanie we have constraints....the biggest
one is more generally referred to as "economics".

Her paraphrasing and reading between the lines is biased. Another way of
looking at it is from Microsoft point of view. "How dare ISVs, etc, take a
business decision, that in my view, puts the long term revenue projections
of our developer suite of products at risk. How dare they question they
value of a platform shift. How dare they be happy with the technology they
already have. How dare they not be open to us selling them more stuff."

And as for [personal libraries of esoteric VB6 code], maybe Stephanies'
doodlings fit into those catagories but some companies *in the real world*
actually have those libraries in production, running bug free, and they
dont want to have to redevelop and redeploy. Since we're talking about the
"real world" and all.
I believe that the late John F. Kennedy put it quite succinctly when he said "Ask not what your country can do for you, ask what can you do for

your country." (Apologies for any misquote.) In this case I doon't think he would have minded a small bit of plagarism: Ask not what your industry can do for you, ask what can you do for your industry.

What? Is this yet another random inclusion? I dont work for my industry, i
work for my company and my company works for its customers...more of that
*real world* stuff again. Beyond that my "industry" is a damn sight bigger
than just Microsoft and its offerings but again VB6 *ease of use* vrs
VB.net / *comfort zone*.
??? Relevance please?What is she on about?

Maybe in your particular dialect Cor, simply saying/writing words gives
them meaning, but in English the idea is to think about what you're saying
or going to say before you say it. And its genrally a good idea if what
your saying actually makes sense and supports itself. Another good tip when
communicating in English is not to confuse length of response with depth of
response nor relevance of response; its also a good idea to try to maintain
"context". i.e when someone asks how your day went, you dont respond..."I
'll have six please".

The choice whether or not to follow these rules is ultimately yours and
your alone, but if you dont follow these basic rules AND ALSO include
random facts in some vain attempt to sound authoritative then chances are
someone will postulate that you are a either "drunk" or a "shithead".

Richard

[Cor Ligthert]

Richard,

This is in my opinion a more complete message than your first answer. I
never do read every word (in whatever language). I try to get the intention
from the writer even when there are some things in it, that don't right
describes what he/she was wanting to say.

You saw my answer about the Cro Magnon and the Neanderthaler. When I
understand you well, than it describes for me in a way what you are writing
in the message I am answering now.

The survivor is not the in advance so called "strongest" but is often
because of fortuitous or changing environmental reasons.

About the last part of your message. In my opinion has everybody the right
to write too this newsgroup in the way that he/she prefers. Stephany's
message was for me about the subject, in a more general way. In my opinion
has she and I the right to do that.

About the length of a message. When you can say something with two words,
than my opinion is do not try to make a book from it. On the other hand, for
me is good programming to make an as short as possible program, however
there is no reason too use this attitude on other places and especially not
where something is only one time used. Something that developers often
forget.

Statistical is proven that woman use in general more words to pronounce
themselves than men do. However, therefore are in my idea not all women
directly "shitheads".

Cor

[Michael C#]

When the best argument you can make to dispute the validity of someone's
argument is to call her names, it speaks volumes about your mental state,
ability to formulate a complete argument and skill at expressing your
thoughts. Calling someone names doesn't speak to the issue at hand, or
disprove any points made by anyone else.

"Richard Myers" <fa**@address.com> wrote in message
news:u1**************@TK2MSFTNGP14.phx.gbl...

>> As a species (homo sapien), we are comfortable with what we know. The
>> inverse is also true - we are NOT comfortable with what we DON'T know.
> This truism has been proved again and again throughout the course of history.

she suggests what follows is going to back her so called truism.
>> Because of this, change tends to resisted, (especially in the early
> stages),until such time as there is a widespread understanding of the 'technology' >> behind the change.

Change does not "tend to be resisted". It simply isn't always immediately
accepted until its benefits have been sufficiently communicated, witnessed
and understood.

I can easily accept the argument that people don't like change. In my
personal experience, I have seen this proven time and again. You can find
historical context here - look at the Civil Rights movement. Certain groups
of people resisted change to the bitter end -- for no logical reason. They
were simply comfortable with the status quo, and uncomfortable with change.

People as a group get comfortable with a certain way of doing things, and
they offhandedly reject different methods - no matter how many ways you
prove to them that the new method is superior to the old. I've seen this in
the business world as well, although as a whole businesses tend to more
readily plan for, and adopt, new technology. I think most individuals'
adoption of new technology is driven largely by market pressure rather than
any great desire to change the status quo on their part.

[Howard Kaikow]

Once one gets used to it, VB .NET is easier for a "programmer" to use.

There are two major hurdles.

1. The VB .NET Help/documentation is awful.

Although much of the needed information is indeed somewhere in the Help
files, good luck in trying to find something quickly, especially if you have
not been previously exposed to VB 6.

Much of the Help/documentation includes links that require one to be online.
That's absurd. I'm not about to stay connected to the internet while
coding/testing, or to keep hoping on/off the internet.

2. It is far easier to do Office automation with VB 6 than with VB .NET.

--
http://www.standards.com/; See Howard Kaikow's web site.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:O$**************@TK2MSFTNGP10.phx.gbl...

Mitchell,

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb:

a lot of VB programmers were really in their comfort zone with 6.
You've hit on one of main points of my thoughts on this topic. I
hypothesize that the people who think that VB6 is easier than VB.NET are
those who were/are "in the VB6 zone". They had become accustomed to all
of the workarounds necessary to get anything done in VB6, so they
mistakenly believe that VB6 is easier because it's easier for *them*.

I have to disagree. It's not easier for them because they know

workarounds to do things the language was not designed for, but because the tool its set of features is more appropriate for the work they are doing. Take a look at Office automation code -- most of this code doesn't use any "hacks", it
simply uses the Office object model to get certain things done.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

Howard,

"Howard Kaikow" <ka****@standards.com> schrieb:

Once one gets used to it, VB .NET is easier for a "programmer" to use.
That might be true, but there are still people who would disagree.
There are two major hurdles.

1. The VB .NET Help/documentation is awful.
Full ACK!
2. It is far easier to do Office automation with VB 6 than with VB .NET.

Yup. The harnessed team VB6 and VBA is unsurpassed in productivity for
Microsoft Office development.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Herfried K. Wagner [MVP]]

Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:

I don't think that this is true for most VB6 users, at least not for them
using VB6 in a professional manner.
Certainly not, are you afraid for VBNet. An inventive professional will
maybe wait a while; however not rely on an old product from Microsoft
anymore. He does not even know if the bugs created by the new updates can
harm his old product and has to work again to repair that.

It's an issue that Microsoft sees VB6 as an old product -- and the aim of
the petition is to give VB6 a future. The number of people who still use
VB6 indicates that VB6 is more current than people who don't use it might
think.
While he is with that loosing a lot of time and can spend better his time
with migrating it to VBNet.

If Microsoft continues support for Classic VB for the next 10 years, there
is no need to migrate.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

[Cor Ligthert]

> That might be true, but there are still people who would disagree.

There are two major hurdles.

1. The VB .NET Help/documentation is awful.

Full ACK!

Completly not ACK,

I find the documentation on a very high level according to the amount of
possibilities. It does me think on the old days of IBM when from those the
documentation and support was their advantage.

Co

[guy]

totally agree,
try going back to VB6 after VB.NET and a bit of C# for 3 years!

guy

"Mitchell S. Honnert" wrote:

In some recent posts, I've seen people who seem to be waxing nostalgic with
respect to the "ease of use" of Visual Basic 6. I can't quite put my finger
on it, but they seem to be implying that VB6 was simpler to use than VB.NET,
that it was somehow easier to write programs in VB6 than in VB.NET. I have
to admit I'm astonished by this attitude. I can't see any rationality to
the idea that, on the whole, VB6 is easier than VB.NET.

I *can* see where someone who is entrenched in the VB6 language would find
the switch to VB.NET daunting. (VB.NET is, after all, a major departure
from VB6.) But what I can't see is someone making the judgment, from an
objective standpoint, that VB6 is easier than VB.NET. In other words, just
because *you* happen to be so much more familiar with the collective set of
eccentricities, peculiarities, and inconsistencies that is known as Visual
Basic 6 that you can write applications faster in VB6 than VB.NET, it
doesn't mean that VB6 is easier.

I've heard it argued that a drawback to .NET's full support of object
oriented programming is that it makes coding more difficult. "I just want
to get in there and write some code; I don't want to have to worry about all
of that OO crap." Perhaps the principle holds true for the "Hello World"
type of application, but for any non-trivial application, I just don't see
how the well-ordered, clean, and consistent implementation of OO principles
in the .NET framework couldn't be seen as an easier environment in which to
develop.

I guess I'm looking at it from the perspective of teaching someone who is
completely new to programming how to be a programmer. In this case, which
would be easier, VB6 or VB.NET? There's not doubt in my mind that VB.NET
would be easier. In my opinion, in a relatively short period of time, I
could teach someone the principles of object oriented programming and the
basic layout of the .NET Framework. But if I applied this same amount of
time to teaching someone VB6 from scratch, I'd get so bogged down in telling
them about all of the quirks, workarounds, and exceptions-to-the-rule that
I'd run out of time before I could even get through the basics. (I wouldn't
even want to call this type of knowledge transfer "teaching".)

The point is that even though there might be an initially steeper learning
curve to get past the principles of object oriented programming, once you
have the "OO epiphany" and truly grok the principles, the rest is smooth
sailing. But with VB6, you may get up and running a bit faster, but your
daily process of coding is so taken up by finding workarounds to a seemingly
endless series of quirky behaviors or things that just don't operate how you
think they would, that the overall development time is actually much longer.

So, are there people out there that really think VB6 is easier than VB.NET?
Why? Do you think it depends on the size of the project? Are there other
factors? Help me understand because I just don't get this attitude.

- Mitchell S. Honnert