By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,263 Members | 1,579 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,263 IT Pros & Developers. It's quick & easy.

VB6 easier than VB.NET?

P: n/a
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
Nov 21 '05 #1
Share this Question
Share on Google+
66 Replies


P: n/a
In some respects VB6 was simpler than .NET, but .NET has a lot more
functionality in it that you many times had to kludge your way through with
VB6.

VB.NET's support for OO programming, when coming from a VB6 background, does
provide a learning curve to non-OO programmers... and a lot of VB
programmers were really in their comfort zone with 6. But the switch to OO
programming is well worth it, and most people probably discover that .NET
provides a lot of great new functionality and improvements once you stop
trying to do things the VB6 way...

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:OA**************@TK2MSFTNGP09.phx.gbl...
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

Nov 21 '05 #2

P: n/a
> 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*. The thing is, I
wouldn't want to be thought of as a good programmer because I know the
mystical tricks to get my language of choice to do the things it's supposed
to do out of the box. I don't want to be a voodoo programmer. I'd much
rather spend that time learning more about the language. Even if it means
some additional up-front work.

- Mitchell S. Honnert
"Michael C#" <xy*@yomomma.com> wrote in message
news:eg*************@TK2MSFTNGP15.phx.gbl...
In some respects VB6 was simpler than .NET, but .NET has a lot more
functionality in it that you many times had to kludge your way through
with VB6.

VB.NET's support for OO programming, when coming from a VB6 background,
does provide a learning curve to non-OO programmers... and a lot of VB
programmers were really in their comfort zone with 6. But the switch to
OO programming is well worth it, and most people probably discover that
.NET provides a lot of great new functionality and improvements once you
stop trying to do things the VB6 way...

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:OA**************@TK2MSFTNGP09.phx.gbl...
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


Nov 21 '05 #3

P: n/a
On 2005-03-24, Mitchell S. Honnert <news@honnert~R~E~M~O~V~E~.com> 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 don't want to generalize about what others have said, because there's
a very wide range of opinions on this subject, but I'd say VB6 was
definitely easier to learn, especially for beginners and
non-programmers.
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.
"Non-trivial" is a relative term. There's lots of small apps out there
that seem trivial to me, but are treated like the Holy Grail in small
offices. And these are very valuable productivity-enhancing
applications, usually written by somebody who picked up a little VB.
There's really no reasonable consultant market for things like this: I
could write the app in less than a day if I knew what to write, but it
would take me six weeks to learn the business process that needs to be
automated.

VB was perfect for these kinds of things, because it could be very
forgiving of a certain lack of understanding. Consider something basic,
the difference between a class and an instance of a class. People could
write very useful apps without understanding this because VB blurred the
distinction where forms were concerned. You could drag buttons onto a
form, write little event handlers, maybe even do some DB work without
ever really grasping the big picture.

That's much tougher in .NET. VB.Net still hides complexity a little,
but the idea of class and instances and scope and visibility and stuff
like that pops up pretty quickly.
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".)


On the flipside, let's say you did write this one-day application I
mentioned above. You wrote it in six hours and now you have two hours
to hand it over to the "technical" person in the office for ongoing
support (because they can't afford to call you back for new features).
This person has maybe done a few Word macros, can do fairly advanced
spreadsheet functions in Excel, etc.

What's easier to explain, the code behind a VB6 form, or a full-fledged
OOP app in .Net? I think the VB6 app would be much easier to explain
in a limited time.

Nov 21 '05 #4

P: n/a
"Comfort Zone"

In this whole recent, (dare I call it one), 'debate', this is the phrase
that has been missing.

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.
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. Once such change becomes generally accepted, there are
still some who resist further. 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.

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.

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? The word 'luddite' has since entered our language to mean someone
who unreasonably resists change. If I remember some middle 19th century
history correctly a Western Union 'boss' was attributed as saying "I can't
see any practical use for it, now or in the future" when refering to
Alexander Graham Bell's new invention (the telephone).

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.

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

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.
"Michael C#" <xy*@yomomma.com> wrote in message
news:eg*************@TK2MSFTNGP15.phx.gbl...
In some respects VB6 was simpler than .NET, but .NET has a lot more
functionality in it that you many times had to kludge your way through
with VB6.

VB.NET's support for OO programming, when coming from a VB6 background,
does provide a learning curve to non-OO programmers... and a lot of VB
programmers were really in their comfort zone with 6. But the switch to
OO programming is well worth it, and most people probably discover that
.NET provides a lot of great new functionality and improvements once you
stop trying to do things the VB6 way...

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:OA**************@TK2MSFTNGP09.phx.gbl...
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


Nov 21 '05 #5

P: n/a
I'm just dipping in here because this thread caught my attention.

It sounds like David and I have had some similar experiences. I have seen
these "trivial" applications in small offices, and some in big offices, and
I have to say that they worry me. I quite agree with the idea that someone
who considers themselves a professional programmer might write such a
program in less than a day, but that it would take six weeks to understand
the business processes involved. I have been in that situation.

However, just understanding the business process is not enough. The trivial
programs I have seen, written in small and big offices, don't follow even
the simplest of programming principles. The best thing for all concerned
would be if the program were to crash, and then it would be clear that it
had failed. In reality though, the program churns out numbers that, after
some rudimentary testing appear to be correct, and thereafter are taken as
gospel.

The use to which these numbers are put may be low risk, but frequently they
are not. Often a program written by the chap in the corner office starts
life as a spreadsheet, or a database in Access, but before long the whole
company depends on this trivial program, and its function grows out of all
proportion to its original intended purpose. Such programs are not
controlled or documented, and even the person who wrote it has little clue
what it does six months later.

This is where I believe that VB.NET is an improvement over VB6. It requires
that someone using it understand that bit more about the language and how to
program with it, but once they do, it hopefully helps them to structure
their work a bit better.

It is true that a bad programmer can write rubbish in any language, and
ultimately that will be the same for VB.NET. Perhaps what I am saying is
that we should be wary of people who dabble in programming; a little
knowledge is a dangerous thing. We all like a bit of DIY (well, I don't, but
I gather it is quite popular), but there should be limits to which we should
go. If we all fitted our own gas central heating, there would be an
explosion every day in our neighbourhood.

Charles
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd45u5a.8tq.df*****@woofix.local.dom...
On 2005-03-24, Mitchell S. Honnert <news@honnert~R~E~M~O~V~E~.com> 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 don't want to generalize about what others have said, because there's
a very wide range of opinions on this subject, but I'd say VB6 was
definitely easier to learn, especially for beginners and
non-programmers.
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.


"Non-trivial" is a relative term. There's lots of small apps out there
that seem trivial to me, but are treated like the Holy Grail in small
offices. And these are very valuable productivity-enhancing
applications, usually written by somebody who picked up a little VB.
There's really no reasonable consultant market for things like this: I
could write the app in less than a day if I knew what to write, but it
would take me six weeks to learn the business process that needs to be
automated.

VB was perfect for these kinds of things, because it could be very
forgiving of a certain lack of understanding. Consider something basic,
the difference between a class and an instance of a class. People could
write very useful apps without understanding this because VB blurred the
distinction where forms were concerned. You could drag buttons onto a
form, write little event handlers, maybe even do some DB work without
ever really grasping the big picture.

That's much tougher in .NET. VB.Net still hides complexity a little,
but the idea of class and instances and scope and visibility and stuff
like that pops up pretty quickly.
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".)


On the flipside, let's say you did write this one-day application I
mentioned above. You wrote it in six hours and now you have two hours
to hand it over to the "technical" person in the office for ongoing
support (because they can't afford to call you back for new features).
This person has maybe done a few Word macros, can do fairly advanced
spreadsheet functions in Excel, etc.

What's easier to explain, the code behind a VB6 form, or a full-fledged
OOP app in .Net? I think the VB6 app would be much easier to explain
in a limited time.

Nov 21 '05 #6

P: n/a
Mitchell,

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb:
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 don't think it's that important that a programming language is easy to
learn. It's impossible to learn to get /used to/ a programming language.
Experience cannot be replaced by reading a book. However, a language can be
more easy than an other in certain cases. In other words, using language X
might be more appropriate (easier) than using language Y to solve a problem.

It's impossible to create a "general purpose" programming language that can
be used to solve every problem in the easiest possible way. Programming
languages are typically optimized for certain tasks. So are OO languages
and frameworks. However, OO is not the answer to all programming tasks;
there are cases where an object-based language (VB6) is more appropriate
than a full OO language.

While VB6 was suitable for small companies, business applications, office
applications, etc., VB.NET has been designed as an application for
enterprise development. .NET (VB.NET/C#) are not suitable tools in many
situations:

<URL:http://www.dicks-blog.com/archives/2005/03/09/support-classic-vb/#comment-9262>:

---
Weíre not a programming shop, but use Excel as a programming tool to get our
jobs done: taking away VBA and replacing it with .NET is sort of like taking
away a construction workerís hammer and replacing it with a pneumatically
driven nuclear-powered piledriver. That all we want to do is write
relatively small snippets of code and a few loops to handle daily problems
means that for us VBA is a nicely weighted and balanced hammer: from what Iíve
seen (correct me if Iím wrong!), .NET is vast overkill for the relatively
small, yet fiercely complex tasks we need it for. And we gotta learn how to
do everything all over again.
---

(I think the sample above elaborates the main issue of the VB6/VBA -> .NET
migration very well.)
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 am familiar with the .NET technology, VB.NET, C# and other .NET-enabled
languages, but this doesn't imply that I think that using .NET (VB.NET, C#)
is most suitable in all cases. VB(A) enables people who are not programmers
to write code, for example, people working in an office using Microsoft
Office products (Excel, Word, ...). For these cases, full OO simply doesn't
make much sense, moreover it increases the complexity without adding a
benefit.
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."
This argument must be analyzed from three standpoints:

* People owning a large VB6 codebase that cannot be migrated
to .NET without a rewrite (which doesn't bring any benefit).

* People who don't need OO at all, for example, office developers
(VBA).

* The programmer who is simply too lazy to learn OO, but using
OO would significantly increase his productivity. (rarely the case)
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.
There are cases where OO (PIE) doesn't make much sense. For example, when
writing VBA code, reusability is often not important. Inheritance isn't a
required feature too to copy some data from one sheet to another.
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.
Starting with OO when teaching programming is IMO one of the worst things
one can do. I'd start with simple "lists of commands", then explore
procedures, procedural programming, object based programming, and finish
with OOP. Even when writing OO programs, OO doesn't replace procedural
programming, modular programming and object based techniques. They are part
of it.
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.
Many people who claim to be familiar with .NET or Java are lacking
fundamental programming techniques like formulating a problem in the form of
an (procedural) algorithm. They don't know anything about runtime analysis
of algorithms or writing secure code, which are both crucial for writing
high-quality code. Although these people can design class hierarchies, the
quality of method implementations is *poor*!
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


Samples?

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

Nov 21 '05 #7

P: n/a
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/>

Nov 21 '05 #8

P: n/a
Stephany,

Your post makes you seem like a shithead.

Richard

"Stephany Young" <noone@localhost> wrote in message
news:On**************@TK2MSFTNGP15.phx.gbl...
"Comfort Zone"

In this whole recent, (dare I call it one), 'debate', this is the phrase
that has been missing.

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.
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. Once such change becomes generally accepted, there are
still some who resist further. 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.

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.

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? The word 'luddite' has since entered our language to mean someone who unreasonably resists change. If I remember some middle 19th century
history correctly a Western Union 'boss' was attributed as saying "I can't see any practical use for it, now or in the future" when refering to
Alexander Graham Bell's new invention (the telephone).

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.

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

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.
"Michael C#" <xy*@yomomma.com> wrote in message
news:eg*************@TK2MSFTNGP15.phx.gbl...
In some respects VB6 was simpler than .NET, but .NET has a lot more
functionality in it that you many times had to kludge your way through
with VB6.

VB.NET's support for OO programming, when coming from a VB6 background,
does provide a learning curve to non-OO programmers... and a lot of VB
programmers were really in their comfort zone with 6. But the switch to OO programming is well worth it, and most people probably discover that .NET provides a lot of great new functionality and improvements once you stop trying to do things the VB6 way...

"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:OA**************@TK2MSFTNGP09.phx.gbl...
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



Nov 21 '05 #9

P: n/a

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:u7**************@tk2msftngp13.phx.gbl...
Weíre not a programming shop, but use Excel as a programming tool to get
our
jobs done: taking away VBA and replacing it with .NET is sort of like
taking
away a construction workerís hammer and replacing it with a pneumatically
driven nuclear-powered piledriver. That all we want to do is write
relatively small snippets of code and a few loops to handle daily problems
means that for us VBA is a nicely weighted and balanced hammer: from what
Iíve
seen (correct me if Iím wrong!), .NET is vast overkill for the relatively
small, yet fiercely complex tasks we need it for. And we gotta learn how
to
do everything all over again.
---

(I think the sample above elaborates the main issue of the VB6/VBA -> .NET
migration very well.)
To me, VBA should be separated from VB6 in this particular context. When I
think VBA, I think of a scripting language for MS Office product
automation - something to get small tasks done in your spreadsheet without
going all out and writing a complete external application. When I think
VB6, I think of the full-fledged application development tool, external to
the MS Office Suite. I can't think of many things that can be done in VB6
that can't be done in VB.NET - to me it's just a matter of getting out of
the VB6 mind-state.
* People owning a large VB6 codebase that cannot be migrated
to .NET without a rewrite (which doesn't bring any benefit).
The people and companies who have invested a lot of $$$ in VB6 development
may have a valid reason to stick with it for backwards compatibility, but
this should not be used as a rallying cry for continued investment in
antiquated technologies, and ignorance of modern technologies. Fortunately
businesses are a lot better at adapting to, planning for, and scheduling
change than individuals; and in a Capitalist economy, business tends to
dictate the skills that individuals begin to adopt.
There are cases where OO (PIE) doesn't make much sense. For example, when
writing VBA code, reusability is often not important. Inheritance isn't a
required feature too to copy some data from one sheet to another.


OTOH, not all OO projects require that the user design their classes with
reusability by other programs in mind (though it might be a big bonus to
plan for and implement this if possible, since you can save yourself a lot
of time and trouble on future projects). In simple projects, the use of
inheritance might well be hidden from the programmer by the Forms designer
generated code. To add to your statement, not all OO programs require the
programmer to implement Polymorphism; but it's there if you need it. Not
all simple OO programs need be complex as people make them out to be.

The key to me is that VB6 programmers moving to .NET need to first get out
of the VB6 mindset. And those that refuse to learn the new technology, and
change with the business world, will end up missing out on a lot of business
opportunities.

Just my 2 cents.
Nov 21 '05 #10

P: n/a
Richard,

Your post erases all doubt.

"Richard Myers" <fa**@address.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Stephany,

Your post makes you seem like a sh!thead.

Richard

Nov 21 '05 #11

P: n/a
"Michael C#" <xy*@abcdef.com> schrieb:
The key to me is that VB6 programmers moving to .NET need to first get out
of the VB6 mindset. And those that refuse to learn the new technology,
and change with the business world, will end up missing out on a lot of
business opportunities.


Most VB6 programmers (and I know a lot of them) are familiar with OO and use
OO techniques in other programming languages (C++, VB.NET, C#, etc.). There
are very few (except what I call "office developers") who are not familiar
with these techniques. So, skills and learning are not the problem.
"Getting out of the VB6 mindset" is just an easy answer that doesn't apply
in reality. It is based on symptoms, not the reasons.

<URL:http://www.joelonsoftware.com/items/2005/03/14.html>

"If you spend the money to upgrade to VB.NET, well, you just spent a lot of
money to stand still. And companies don't like to spend a lot of money to
stand still, so while you're spending the money, it probably makes sense to
consider the alternatives that you can port to that won't put you at the
mercy of a single vendor and won't be as likely to change arbitrarily in the
future. So as soon as people with large code bases start hearing that
they're going to have to work to port their apps from VB to VB.NET with
WinForms, and then they start hearing that WinForms isn't really the future,
the future is really this Avalon thing nobody has yet, they start wondering
whether it isn't time to find another development platform."

Revolutionary change instead of evolutionary adaption (rewrite instead of
reuse) has a negative impact on overall productivity and slows down adoption
of new technology. Stability of both languages and technology have a
crucial role in software development.

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

Nov 21 '05 #12

P: n/a
I rest my case.
"Richard Myers" <fa**@address.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Stephany,

Your post makes you seem like a shithead.

Richard

"Stephany Young" <noone@localhost> wrote in message
news:On**************@TK2MSFTNGP15.phx.gbl...
"Comfort Zone"

In this whole recent, (dare I call it one), 'debate', this is the phrase
that has been missing.

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.
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. Once such change becomes generally accepted, there are
still some who resist further. 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.

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.

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? The word 'luddite' has since entered our language to mean

someone
who unreasonably resists change. If I remember some middle 19th century
history correctly a Western Union 'boss' was attributed as saying "I

can't
see any practical use for it, now or in the future" when refering to
Alexander Graham Bell's new invention (the telephone).

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.

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

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.
"Michael C#" <xy*@yomomma.com> wrote in message
news:eg*************@TK2MSFTNGP15.phx.gbl...
> In some respects VB6 was simpler than .NET, but .NET has a lot more
> functionality in it that you many times had to kludge your way through
> with VB6.
>
> VB.NET's support for OO programming, when coming from a VB6 background,
> does provide a learning curve to non-OO programmers... and a lot of VB
> programmers were really in their comfort zone with 6. But the switch to > OO programming is well worth it, and most people probably discover that > .NET provides a lot of great new functionality and improvements once you > stop trying to do things the VB6 way...
>
> "Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
> news:OA**************@TK2MSFTNGP09.phx.gbl...
>> 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
>>
>>
>
>



Nov 21 '05 #13

P: n/a
Hi Charles,

Although I agree with your assessment, remember that there is a REAL NEED
for small and medium sized business to get things DONE, inexpensively. The
programs that the so-called "bad" programmers create DO accomplish a task,
even if they aren't up to the standards of "professional" programmers. The
end RESULTS of these programs allow a company to put their profits back INTO
their business, instead of into a software developer's pocket (or MS for
that matter). Thus the real problem with the demise of VB classic is that a
void is created for the non-professional programmer to inexpensively provide
customized solutions to their unique problems.

Now I know that there will be little sympathy from the readers of this
forum, but let me just remind everyone of the REAL job of a programmer: to
accomplish a task for a customer that will improve their profits and not
just create a drain on revenue. All the neat little technology provided by
the "latest-and-greatest" does nothing for the customer UNLESS the software
can be delivered to them inexpensively and reliably. And if you do not
agree that this is what your job is really about, then I sincerely hope that
your customers don't find out because you will quickly find yourselves out
of work. Following this definition, even "bad" programmers fit the bill.

Many of the people who post that the classic VBer's should just accept that
technology changes and deal with it are missing the whole point. Spending
more money on new technology, when it does nothing for a company's bottom
line, is just plain stupid. Rather, I think it is those people who jump on
the technology band-wagon without a single thought as to the ramifications
who are stupid. From a professional programmers perspective, I can
understand their position. Keeping up with current technology keeps you
employable. It's just that when it comes down to meeting a company's need
(your customer) there had better be valid reasons behind the new technology.

Now that VB classic is being phased out, the most productive tool a small
business had to increase their bottom line is being taken away. Supposedly
VB.net, in the next release, isn't all that hard to learn and can still be
considered RAD. And maybe it's not. Problem is, with the limited upgrade
path provided to VB.net, MS might as well said "OK, your existing VB classic
apps are obsolete. They will be able to run on future OS's. However, you
can't easily convert all of your old projects to use our newest technology.
This will require a potentially expensive re-write that will not add a
single penny to your profits. As a matter of fact, it will most likely cost
you big time. Oh, and we don't care."

I don't think a single classic VBer will state that VB.net is a step
backward. In fact, I believe just the opposite. Regardless of people's
impressions, the dissension isn't about VB.net. It isn't about being able
to accept change. It's about all the $$$ that will be required to move from
'Neandethal' to 'Cro Magnon' and about all the companies that are being
FORCED to do this without any real help from MS.


"Charles Law" <bl***@nowhere.com> wrote in message
news:eE**************@TK2MSFTNGP09.phx.gbl...
I'm just dipping in here because this thread caught my attention.

It sounds like David and I have had some similar experiences. I have seen
these "trivial" applications in small offices, and some in big offices, and I have to say that they worry me. I quite agree with the idea that someone
who considers themselves a professional programmer might write such a
program in less than a day, but that it would take six weeks to understand
the business processes involved. I have been in that situation.

However, just understanding the business process is not enough. The trivial programs I have seen, written in small and big offices, don't follow even
the simplest of programming principles. The best thing for all concerned
would be if the program were to crash, and then it would be clear that it
had failed. In reality though, the program churns out numbers that, after
some rudimentary testing appear to be correct, and thereafter are taken as
gospel.

The use to which these numbers are put may be low risk, but frequently they are not. Often a program written by the chap in the corner office starts
life as a spreadsheet, or a database in Access, but before long the whole
company depends on this trivial program, and its function grows out of all
proportion to its original intended purpose. Such programs are not
controlled or documented, and even the person who wrote it has little clue
what it does six months later.

This is where I believe that VB.NET is an improvement over VB6. It requires that someone using it understand that bit more about the language and how to program with it, but once they do, it hopefully helps them to structure
their work a bit better.

It is true that a bad programmer can write rubbish in any language, and
ultimately that will be the same for VB.NET. Perhaps what I am saying is
that we should be wary of people who dabble in programming; a little
knowledge is a dangerous thing. We all like a bit of DIY (well, I don't, but I gather it is quite popular), but there should be limits to which we should go. If we all fitted our own gas central heating, there would be an
explosion every day in our neighbourhood.

Charles
"David" <df*****@woofix.local.dom> wrote in message
news:slrnd45u5a.8tq.df*****@woofix.local.dom...
On 2005-03-24, Mitchell S. Honnert <news@honnert~R~E~M~O~V~E~.com> 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 don't want to generalize about what others have said, because there's
a very wide range of opinions on this subject, but I'd say VB6 was
definitely easier to learn, especially for beginners and
non-programmers.
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.


"Non-trivial" is a relative term. There's lots of small apps out there
that seem trivial to me, but are treated like the Holy Grail in small
offices. And these are very valuable productivity-enhancing
applications, usually written by somebody who picked up a little VB.
There's really no reasonable consultant market for things like this: I
could write the app in less than a day if I knew what to write, but it
would take me six weeks to learn the business process that needs to be
automated.

VB was perfect for these kinds of things, because it could be very
forgiving of a certain lack of understanding. Consider something basic,
the difference between a class and an instance of a class. People could
write very useful apps without understanding this because VB blurred the
distinction where forms were concerned. You could drag buttons onto a
form, write little event handlers, maybe even do some DB work without
ever really grasping the big picture.

That's much tougher in .NET. VB.Net still hides complexity a little,
but the idea of class and instances and scope and visibility and stuff
like that pops up pretty quickly.
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".)


On the flipside, let's say you did write this one-day application I
mentioned above. You wrote it in six hours and now you have two hours
to hand it over to the "technical" person in the office for ongoing
support (because they can't afford to call you back for new features).
This person has maybe done a few Word macros, can do fairly advanced
spreadsheet functions in Excel, etc.

What's easier to explain, the code behind a VB6 form, or a full-fledged
OOP app in .Net? I think the VB6 app would be much easier to explain
in a limited time.


Nov 21 '05 #14

P: n/a
I rest my case.
On what im not sure but.... thank God either way.



"Richard Myers" <fa**@address.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Stephany,

Your post makes you seem like a shithead.

Richard

"Stephany Young" <noone@localhost> wrote in message
news:On**************@TK2MSFTNGP15.phx.gbl...
"Comfort Zone"

In this whole recent, (dare I call it one), 'debate', this is the phrase that has been missing.

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. 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. Once such change becomes generally accepted, there are still some who resist further. 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.

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.

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? The word 'luddite' has since entered our language to mean

someone
who unreasonably resists change. If I remember some middle 19th
century history correctly a Western Union 'boss' was attributed as saying "I

can't
see any practical use for it, now or in the future" when refering to
Alexander Graham Bell's new invention (the telephone).

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.

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

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.
"Michael C#" <xy*@yomomma.com> wrote in message
news:eg*************@TK2MSFTNGP15.phx.gbl...
> In some respects VB6 was simpler than .NET, but .NET has a lot more
> functionality in it that you many times had to kludge your way through > with VB6.
>
> VB.NET's support for OO programming, when coming from a VB6 background, > does provide a learning curve to non-OO programmers... and a lot of VB > programmers were really in their comfort zone with 6. But the switch to
> OO programming is well worth it, and most people probably discover

that
> .NET provides a lot of great new functionality and improvements once

you
> stop trying to do things the VB6 way...
>
> "Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in
message > news:OA**************@TK2MSFTNGP09.phx.gbl...
>> 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
>>
>>
>
>



Nov 21 '05 #15

P: n/a
The final sentence of your final paragraph illustrates my point admirably.

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!

With reference to your first sentence you have used a phrase that also helps
say it all. "...remember that there is a REAL NEED for small and medium
sized business to get things DONE, inexpensively.". The key word here is
'inexpensively". Unfortunately the modern trend tend to be to use the word
'inexpensively' in place of the phrase 'cost effectively'. While I accept
that all companies have a need to get things done in a cost effective
manner - indded they have a responsibility to their shareholders to do so -
I believe any companies attempting to get things done in the most
inexpensive manner to be negligent in their responsibilities.
'Inexpensive' and 'Cost Effective' do not mean the same thing.

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.
"Keith Seeley" <ks*****@worldnet.att.net> wrote in message
news:Zu*********************@bgtnsc05-news.ops.worldnet.att.net...
Hi Charles,

Although I agree with your assessment, remember that there is a REAL NEED
for small and medium sized business to get things DONE, inexpensively.
The
programs that the so-called "bad" programmers create DO accomplish a task,
even if they aren't up to the standards of "professional" programmers.
The
end RESULTS of these programs allow a company to put their profits back
INTO
their business, instead of into a software developer's pocket (or MS for
that matter). Thus the real problem with the demise of VB classic is that
a
void is created for the non-professional programmer to inexpensively
provide
customized solutions to their unique problems.

Now I know that there will be little sympathy from the readers of this
forum, but let me just remind everyone of the REAL job of a programmer: to
accomplish a task for a customer that will improve their profits and not
just create a drain on revenue. All the neat little technology provided
by
the "latest-and-greatest" does nothing for the customer UNLESS the
software
can be delivered to them inexpensively and reliably. And if you do not
agree that this is what your job is really about, then I sincerely hope
that
your customers don't find out because you will quickly find yourselves out
of work. Following this definition, even "bad" programmers fit the bill.

Many of the people who post that the classic VBer's should just accept
that
technology changes and deal with it are missing the whole point. Spending
more money on new technology, when it does nothing for a company's bottom
line, is just plain stupid. Rather, I think it is those people who jump
on
the technology band-wagon without a single thought as to the ramifications
who are stupid. From a professional programmers perspective, I can
understand their position. Keeping up with current technology keeps you
employable. It's just that when it comes down to meeting a company's need
(your customer) there had better be valid reasons behind the new
technology.

Now that VB classic is being phased out, the most productive tool a small
business had to increase their bottom line is being taken away.
Supposedly
VB.net, in the next release, isn't all that hard to learn and can still be
considered RAD. And maybe it's not. Problem is, with the limited upgrade
path provided to VB.net, MS might as well said "OK, your existing VB
classic
apps are obsolete. They will be able to run on future OS's. However, you
can't easily convert all of your old projects to use our newest
technology.
This will require a potentially expensive re-write that will not add a
single penny to your profits. As a matter of fact, it will most likely
cost
you big time. Oh, and we don't care."

I don't think a single classic VBer will state that VB.net is a step
backward. In fact, I believe just the opposite. Regardless of people's
impressions, the dissension isn't about VB.net. It isn't about being able
to accept change. It's about all the $$$ that will be required to move
from
'Neandethal' to 'Cro Magnon' and about all the companies that are being
FORCED to do this without any real help from MS.

Nov 21 '05 #16

P: n/a
> 'Inexpensive' and 'Cost Effective' do not mean the same thing.

Yes they do.
Nov 21 '05 #17

P: n/a

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Os*************@TK2MSFTNGP12.phx.gbl...
"Michael C#" <xy*@abcdef.com> schrieb:
The key to me is that VB6 programmers moving to .NET need to first get
out of the VB6 mindset. And those that refuse to learn the new
technology, and change with the business world, will end up missing out
on a lot of business opportunities.


Most VB6 programmers (and I know a lot of them) are familiar with OO and
use OO techniques in other programming languages (C++, VB.NET, C#, etc.).
There are very few (except what I call "office developers") who are not
familiar with these techniques. So, skills and learning are not the
problem. "Getting out of the VB6 mindset" is just an easy answer that
doesn't apply in reality. It is based on symptoms, not the reasons.


Unless you want to modify your previous list of three standpoints, these
people can only fall into the first category: people with large investments
in VB6.

It's doubtful that every individual or company has invested so largely in
VB6 that moving on to .NET is cost-prohibitive. Of those that are too
cost-prohibitive to "retool" their inventories of VB6 code, what's stopping
them from moving toward .NET for future development? It would seem they
already have - for the most part - the OO skills, so the complexities of
using Inheritance shouldn't be an issue to them...

IMHO, it boils down to the "VB6 mindstate". They are comfortable
programming VB6, and don't feel the need to upgrade their skill sets. The
Market has an amazing way of letting us know whether the decisions we make
will pay off or not.

An opposing viewpoint - the VB6 programmers with little or no OO
experience - might be the minority, but these people are the ones who are
going to get hit the hardest. And I do know some of these types, including
your VBA developers. They seem to make the most noise about not wanting to
change.

Them and COM programmers.

Now, on the topic of support for VB6 - as opposed to "not wanting to port
code to .NET" or "not wanting to learn the new technology" - I have
different feelings. I think that VB6 should continue to be supported by MS,
as there are a lot of businesses and individuals who are still running VB6
code. I feel that VB6 will eventually phase itself out, just like other
older technologies like WFW... But I don't think it will be dictated merely
by Microsoft's force of will, but rather by the forces of the market.
Nov 21 '05 #18

P: n/a
Hi, while i 100% agree with the main point of your argument, that as working
programmers (not hobbyists) we should always keep the "bottom line" first
and foremost in our mind, i disagree completely with your conclusion because
from my experience, coding in .NET is much more efficient than any other
platform ive ever used (granted im not a computer scientist type who has
used a lot of different languages, im pretty much a
COBOL-->VB3/4/5/6-->VB.NET-->C# dork).

further comments below...

"Keith Seeley" <ks*****@worldnet.att.net> wrote in message
news:Zu*********************@bgtnsc05-news.ops.worldnet.att.net...
Hi Charles,

Although I agree with your assessment, remember that there is a REAL NEED
for small and medium sized business to get things DONE, inexpensively.
The
programs that the so-called "bad" programmers create DO accomplish a task,
even if they aren't up to the standards of "professional" programmers.
The
end RESULTS of these programs allow a company to put their profits back
INTO
their business, instead of into a software developer's pocket (or MS for
that matter). Thus the real problem with the demise of VB classic is that
a
void is created for the non-professional programmer to inexpensively
provide
customized solutions to their unique problems.
If you are talking about VBA then yup, its clear that there is a big gap
right now in the area of scripting Office applications. But really whats
the problem here? Is VBA code going to suddenly stop working on a certain
date? And the argument about "oh no, we wont get free tech support or
language upgrades anymore" is complete BS, esp. considering that probably
99% of non-professional-programmers just-want-to-get-it-done people have
never ever dealt with MSFT developer support, and couldnt give two cents if
a new version of VBA was released (in fact, they would probably hate it
because theyd need to revisit their old code and then complain about those
greedy people at MSFT.. forcing them into yet another upgrade.. those
rascals...).
Now I know that there will be little sympathy from the readers of this
forum, but let me just remind everyone of the REAL job of a programmer: to
accomplish a task for a customer that will improve their profits and not
just create a drain on revenue. All the neat little technology provided
by
the "latest-and-greatest" does nothing for the customer UNLESS the
software
can be delivered to them inexpensively and reliably. And if you do not
agree that this is what your job is really about, then I sincerely hope
that
your customers don't find out because you will quickly find yourselves out
of work. Following this definition, even "bad" programmers fit the bill.
I think this argument falls into the common fallacy that because its the
"latest and greatest", it must be hard to work with and more expensive. I
think there is a good deal of evidence (at least from my own experience and
talking to others who have actually used .NET) that in this case the
opposite is true.
Many of the people who post that the classic VBer's should just accept
that
technology changes and deal with it are missing the whole point. Spending
more money on new technology, when it does nothing for a company's bottom
line, is just plain stupid. Rather, I think it is those people who jump
on
the technology band-wagon without a single thought as to the ramifications
who are stupid. From a professional programmers perspective, I can
understand their position. Keeping up with current technology keeps you
employable. It's just that when it comes down to meeting a company's need
(your customer) there had better be valid reasons behind the new
technology.
How would you react if I told you that with .NET you could produce a better
product in a shorter amount of time with fewer people, and that product
would be easier/cheaper to maintain? Would you believe me or not? If not,
why not?

The argument about programmers pushing a fancy new technology to keep
themselves employed seems like an ad-hominem (ferget my Latin pls) attack.
Actually, i see the opposite happening where teams can get smaller or stay
small and get more stuff done quicker.
Now that VB classic is being phased out, the most productive tool a small
business had to increase their bottom line is being taken away.
Supposedly
VB.net, in the next release, isn't all that hard to learn and can still be
considered RAD. And maybe it's not. Problem is, with the limited upgrade
path provided to VB.net, MS might as well said "OK, your existing VB
classic
apps are obsolete. They will be able to run on future OS's. However, you
can't easily convert all of your old projects to use our newest
technology.
This will require a potentially expensive re-write that will not add a
single penny to your profits. As a matter of fact, it will most likely
cost
you big time. Oh, and we don't care."
I disagree with a couple of your assumptions here:
1. VB classic is the most productive tool for small businesses.
2. VB.NET is hard to learn.
Also, your reasoning is contradictory here: youre saying that your old VB
apps will continue to run on future OS's, yet you will be forced into a
costly rewrite of all your apps? If it doesnt make economic sense to
rewrite your existing apps, the solution is simple: don't. That is what
MSFT recommends, and also what it does... you didnt see them rush out a
completely rewritten Office suite built with C# did you? And if an
organization regularly comes to the possibly rational conclusion that
technology upgrades have no economic benefit, then you probably do not need
to worry about them upgrading their OS either. So problem is doubly solved!
I don't think a single classic VBer will state that VB.net is a step
backward. In fact, I believe just the opposite. Regardless of people's
impressions, the dissension isn't about VB.net. It isn't about being able
to accept change. It's about all the $$$ that will be required to move
from
'Neandethal' to 'Cro Magnon' and about all the companies that are being
FORCED to do this without any real help from MS.

Your central assumptions are wrong IMO, because .NET development is cheaper
in the long run, and no one is being forced to do anything that doesnt make
economic sense. the only "forcing" that is going on is caused by natural
competition between businesses who can use technology (both the reality and
the marketing) against their rivals. There are probably many industries
where Windows 3.1 and WordPerfect 5.1 are perfectly "good enough" and
competition between companies within those industries is not affected by
technology. If you find yourself to be a specialist in a field like that,
and youre happy with it, then good for you, i mean it!
Nov 21 '05 #19

P: n/a

I thought VB.net was very very hard back when I started forcing myself to
use it and - here's the real trick - forcing myself to complete and
release a real non-trivial application with it in 2002.

By the end of the project I was a little less shaky with it and confident
enough to start going deeper in beyond just mimicing VB5/6 functionality.

Now, here in '05 my fingers get stuck when I have to go back to VB5/6 (and I
passionately coded VB5/6 exclusively at least six days a week for years).

Recently I bought Virtual PC and just for the test of seeing whether I have
been wrong in my defending VB.Net, I installed my VB2forDOS, VB3 (which I
was quite comfortable with and pretty good with in the day and I was very
very angry that VB4 "killed my tool"), VB4-32, VB5 and VB6.

When they're all put against each other side by side by a person who's done
them all professionally (including VB.Net for real, not just "for testing it
out so you can rant about it") I have confirmed for myself that VB.Net is
the closest to the product that I wanted all along. I think it is the
easiest tool of them all for getting most of my types of corporate jobs done
and its ease is on a number of levels from IDE improvements to inheritance
to deployment ... but I love OOP and I love AutoDeploy/NoTouch and I
understand that a lot of mature VB developers don't share those loves .

btw: Big kick in the face to go back to VB3 and VB4 and see absolutely no
intellisense ... how did we get so much done? A: We bought a million
Microhelp VBXes and used "ActionCodes" :)

Robert Smith
Kirkland, WA
www.smithvoice.com

Nov 21 '05 #20

P: n/a
Richard
Stephany,

Your post makes you seem like a shithead.

I thought that there was at least some education needed to make a program.

Probably you can do it with drag and drop in VB6 probably and now you have
problems?

In my opinion is a good advice for you to try as Herfried told more or less
in this thread MS-Office (the name of that part is MS-Access). Although that
can maybe complex as well for you when you start using the more and more
advanced features.

Just my thought,

Cor
Nov 21 '05 #21

P: n/a
Stephany,

The more detached style I tried in past.

Now I see that the comments on that personally, however more a qualification
from the persons who are answering in that style.

However this is in my opinion not proven true,
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.


AFAIK did they disapeared in a time that there was no fysical reason to
change. The same AFAIK is that it is not even impossible that they are mixed
up with the Cro Magnon.

The reason why they disappeared is AFAIK one of the big misteries.

(Maybe was it because Microsoft has stopped the support for them or made the
step to become from a Neanderthaller a Cro Magnon very easy)

:-)

Cor
Nov 21 '05 #22

P: n/a
Mitchell (and others),

What I find surprising in this thread is that every professional in this
business should be used to this behavior from the users of his product. They
are afraid for every new or improved part that makes working easier;
however, they are not used too. There is fear for it and that is primarily
direct reflected in telling that it is not good.

There are more reasons for that, one of the most known is this one.

The user has made around his tools a special environment. In addition,
because that he becomes superior in his environment gives that him
authority. This superiority he looses with the new tool or is at least very
afraid to loose that.

This is a human aspect reflected as well in the messages from Sthephany.

I find it strange that the ones in this thread (now it becomes them) react
like that.

Just my thought,

Cor
Nov 21 '05 #23

P: n/a
> However this is in my opinion not proven true,
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.
AFAIK did they disapeared in a time that there was no fysical reason to
change. The same AFAIK is that it is not even impossible that they are

mixed up with the Cro Magnon.

The reason why they disappeared is AFAIK one of the big misteries.

(Maybe was it because Microsoft has stopped the support for them or made the step to become from a Neanderthaller a Cro Magnon very easy)

:-)

Cor


Cor,

It always amuses me that you are one of first to attempt to reprimand
others when you consider them being OT ...and yet when you yourself feel
like going OT or find something of interest in someone elses OT comments,
you immediately side step/bypass the standards you profess to support. The
fact that english is not your native tongue is no excuse for your
hypocrisy.

Richard
Nov 21 '05 #24

P: n/a
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ud**************@tk2msftngp13.phx.gbl...
Richard
Stephany,

Your post makes you seem like a shithead.
I thought that there was at least some education needed to make a

program.
Probably you can do it with drag and drop in VB6 probably and now you have problems?

In my opinion is a good advice for you to try as Herfried told more or less in this thread MS-Office (the name of that part is MS-Access). Although that can maybe complex as well for you when you start using the more and more
advanced features.

Just my thought,

Cor


Cor... are you drunk?
Nov 21 '05 #25

P: n/a
Richard,

It always amuses me that you are one of first to attempt to reprimand
others when you consider them being OT ...


Proof

Cor
Nov 21 '05 #26

P: n/a
Richard,

By the way, the only message OT in my opinion in this thread is yours.
Stephany, Your post makes you seem like a shithead. Richard


The message from Stephany is in my opinion very much On thread.

Cor
Nov 21 '05 #27

P: n/a
Well given the gibberish you're prone to post Cor, that hardly surprises
me.
Someone asks a question about VB6 ease of use vrs VB.NET and Stephanie
responds
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.


Yep thats really on topic. Its just dribble for dribbles sake.


"Cor Ligthert" <no************@planet.nl> wrote in message
news:uJ**************@TK2MSFTNGP12.phx.gbl... Richard,

By the way, the only message OT in my opinion in this thread is yours.
Stephany,

Your post makes you seem like a shithead.

Richard


The message from Stephany is in my opinion very much On thread.

Cor

Nov 21 '05 #28

P: n/a
"Michael C#" <xy*@abcdef.com> schrieb:
The key to me is that VB6 programmers moving to .NET need to first get
out of the VB6 mindset. And those that refuse to learn the new
technology, and change with the business world, will end up missing out
on a lot of business opportunities.
Most VB6 programmers (and I know a lot of them) are familiar with OO and
use OO techniques in other programming languages (C++, VB.NET, C#, etc.).
There are very few (except what I call "office developers") who are not
familiar with these techniques. So, skills and learning are not the
problem. "Getting out of the VB6 mindset" is just an easy answer that
doesn't apply in reality. It is based on symptoms, not the reasons.


Unless you want to modify your previous list of three standpoints, these
people can only fall into the first category: people with large
investments in VB6.

It's doubtful that every individual or company has invested so largely in
VB6 that moving on to .NET is cost-prohibitive. Of those that are too
cost-prohibitive to "retool" their inventories of VB6 code, what's
stopping them from moving toward .NET for future development? It would
seem they already have - for the most part - the OO skills, so the
complexities of using Inheritance shouldn't be an issue to them...


For real application developers the move to .NET for new projects is not
such a big problem. However, to be able to do that, there must be a
seamless way to use existing VB6 code by the new .NET projects without a
rewrite. In addition to that, existing code still must be maintained for
years to satisfy the needs of the customers. On the other hand there is the
group of what I call "office developers", secretaries etc. who don't have
in-depth programming skills, and use VBA/VB simply for writing loops and
procedures. For them, OO increses complexity because it detracts from the
"simple" problem they want to solve.
IMHO, it boils down to the "VB6 mindstate". They are comfortable
programming VB6, and don't feel the need to upgrade their skill sets.
That's true for office developers who I wouldn't consider to be real
developers mostly. However, OO is not the right tool for them.
An opposing viewpoint - the VB6 programmers with little or no OO
experience - might be the minority, but these people are the ones who are
going to get hit the hardest. And I do know some of these types,
including your VBA developers. They seem to make the most noise about not
wanting to change.
Imagine you are a carpenter and use a little handsaw. This tool is
opmtimized for the work you do, so there is absolutely no need for a change
of the tool. One day the handsaw doesn't work any more and the manufacturer
of the saw wants to sell you a huge power saw and doesn't sell handsaws any
more because power saws are, in his eyes, an improvement. Would you learn
how to use the power saw if it doesn't fit your needs as exactly as the
handsaw did, or would you consider to buy a new handsaw from another
manufacturer instead? Would you buy a tool that is dysfunctional because
you cannot use it to do your work? I think it's absolutely clear that those
people don't want to change.
Now, on the topic of support for VB6 - as opposed to "not wanting to port
code to .NET" or "not wanting to learn the new technology" - I have
different feelings. I think that VB6 should continue to be supported by
MS, as there are a lot of businesses and individuals who are still running
VB6 code. I feel that VB6 will eventually phase itself out, just like
other older technologies like WFW... But I don't think it will be
dictated merely by Microsoft's force of will, but rather by the forces of
the market.


That's exactly what I think.

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

Nov 21 '05 #29

P: n/a
Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:
The user has made around his tools a special environment. In addition,
because that he becomes superior in his environment gives that him
authority. This superiority he looses with the new tool or is at least
very afraid to loose that.


I don't think that this is true for most VB6 users, at least not for them
using VB6 in a professional manner. Many of them already know OO techniques
from C++, Java, or learned OO when learning VB.NET and C#. However, their
OO knowledge doesn't give them the time and money to convert an application
without bringing it further.

Many "VB shops" have VB code bases started in BASIC, which cannot be used
any more because of fundamental, breaking changes in the language (for
example, the change of array bounds breaks tons of code -- this code needs
to be completely redesigned in order to work in VB.NET or C#). I am just
curious why most people think that VB6 developers are only familiar with
VB6, and I am sure this is a misperception.

The whole issue is more economical than ideological. Treating it as an
ideological issue distracts from the core issues.

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

Nov 21 '05 #30

P: n/a
Richard,

"Richard Myers" <fa**@address.com> schrieb:
Well given the gibberish you're prone to post Cor, that hardly surprises
me.


Note that not everybody in this group is a native English speaker. I
encourage you to take care of that :-)...

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

Nov 21 '05 #31

P: n/a
Herfried,
Well given the gibberish you're prone to post Cor, that hardly surprises
me.


Note that not everybody in this group is a native English speaker. I
encourage you to take care of that :-)...


I am very much able to read what Stephany wrote, and as you know, is that
something I very much agree with ,as I have written it with other words in
the same way as she did, in the other thread directly on statements of you.

I miss in this thread your very much-used link to rules of conduct. I think
that that was more on his place message to Richard.

Alternatively, is it a kind of selective use of that; When the messages fits
your idea's it is not against the rules of conduct. Richard abused both
Stephanie and me in a horrible way, what did me decide not to answer on that
anymore.

Cor
Nov 21 '05 #32

P: n/a
Hefried,
"Richard Myers" <fa**@address.com> schrieb:
Well given the gibberish you're prone to post Cor, that hardly surprises
me.


Note that not everybody in this group is a native English speaker. I
encourage you to take care of that :-)...

--

Before you don't understand my message, with this you agree with Richard
that my messages are gibberish.

Although you are not a native English speaker have I no doubt that you
understand what is written by Richard.

In my opinion is this writing of you than very much in conflict with the
rules of conduct.

Cor
Nov 21 '05 #33

P: n/a
Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:
Well given the gibberish you're prone to post Cor, that hardly surprises
me.
Note that not everybody in this group is a native English speaker. I
encourage you to take care of that :-)...


I am very much able to read what Stephany wrote, and as you know, is that
something I very much agree with ,as I have written it with other words in
the same way as she did, in the other thread directly on statements of
you.


Well, I didn't want to doubt that you understand what Stephany wrote and I
understand what you want to say, but I for me it's sometimes hard to
understand what you write.
I miss in this thread your very much-used link to rules of conduct. I
think that that was more on his place message to Richard.

Alternatively, is it a kind of selective use of that; When the messages
fits your idea's it is not against the rules of conduct. Richard abused
both Stephanie and me in a horrible way, what did me decide not to answer
on that anymore.


I typically post the rules of conduct link when insulting text is directed
to me :-). You can do the same when you are abused.

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

Nov 21 '05 #34

P: n/a
Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:
Well given the gibberish you're prone to post Cor, that hardly surprises
me.


Note that not everybody in this group is a native English speaker. I
encourage you to take care of that :-)...


Before you don't understand my message, with this you agree with Richard
that my messages are gibberish.

Although you are not a native English speaker have I no doubt that you
understand what is written by Richard.


I assume that Richard didn't take enough time to understand what you wrote,
that's why I made him aware that some people don't make mistakes because
they are drunk or idiots, but instead because they are non-native speakers.

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

Nov 21 '05 #35

P: n/a
Herfried,
Well, I didn't want to doubt that you understand what Stephany wrote and I
understand what you want to say, but I for me it's sometimes hard to
understand what you write.

I did almost write nothing to Richard. 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. Whereby I don't write that I am a perfect English
writer. Although I make the writing errors, I make in English, in almost
every language (including Dutch) in mail messages.

In addition, I know that they sometimes are unreadable; therefore, you see
sometimes when it is in my opinion to many corrections. When I see that I
have done typos or whatever which are in my opinion still understandable, I
let it go.

However telling with that, as you do now with this message agreeing with
Richard, that all my messages are gibberish (Kauderwelsch) is a little bit
going too far in my opinion.

Cor
Nov 21 '05 #36

P: n/a
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.

Nov 21 '05 #37

P: n/a
> To me, VBA should be separated from VB6 in this particular context.
Exactly. In fact, I intentionally omitted any reference to VBA in my
original post. My goal was to get the opinion of professional programmers
on enterprise-level programming tools. Yes, I know that VBA is used in the
enterprise, but I had wanted to focus the responses to more "hard core"
programming. Not to discount the programs written by the "guy in
accounting", but that wasn't my focus.
The people and companies who have invested a lot of $$$ in VB6 development
may have a valid reason to stick with it for backwards compatibility Exactly! But again, I didn't reference any migration issues because I
personally was looking for a more objective, side-by-side comparison, rather
than the issues of going from one to another. (Which apparently warrants
its own thread!)
In simple projects, the use of inheritance might well be hidden from the
programmer by the Forms designer generated code. To add to your
statement, not all OO programs require the programmer to implement
Polymorphism; but it's there if you need it. Not all simple OO programs
need be complex as people make them out to be. Exactly!!! I think the discussion about the "VB6 comfort zone" is
appropriate, not to arbitrarily ridicule the programmers who are "stuck in
the past", but to point out how there might be confusion between familiarity
and true ease-of-use. Specifically, I believe that it really *is* easier to
program in VB.NET. Yes, if you want to delve into the complexities of OO,
you will have a steeper learning curve, but you can still to the
drag-and-drop style of programming you could with VB6. It's just that when
you need to go beyond some of the simple stuff, there is an amazingly clear
and coherent architecture waiting for you to discover.

- Mitchell S. Honnert

"Michael C#" <xy*@abcdef.com> wrote in message
news:JQ***************@fe11.lga...
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:u7**************@tk2msftngp13.phx.gbl...
We're not a programming shop, but use Excel as a programming tool to get
our
jobs done: taking away VBA and replacing it with .NET is sort of like
taking
away a construction worker's hammer and replacing it with a pneumatically
driven nuclear-powered piledriver. That all we want to do is write
relatively small snippets of code and a few loops to handle daily
problems
means that for us VBA is a nicely weighted and balanced hammer: from what
I've
seen (correct me if I'm wrong!), .NET is vast overkill for the relatively
small, yet fiercely complex tasks we need it for. And we gotta learn how
to
do everything all over again.
---

(I think the sample above elaborates the main issue of the VB6/VBA ->
.NET
migration very well.)


To me, VBA should be separated from VB6 in this particular context. When
I think VBA, I think of a scripting language for MS Office product
automation - something to get small tasks done in your spreadsheet without
going all out and writing a complete external application. When I think
VB6, I think of the full-fledged application development tool, external to
the MS Office Suite. I can't think of many things that can be done in VB6
that can't be done in VB.NET - to me it's just a matter of getting out of
the VB6 mind-state.
* People owning a large VB6 codebase that cannot be migrated
to .NET without a rewrite (which doesn't bring any benefit).


The people and companies who have invested a lot of $$$ in VB6 development
may have a valid reason to stick with it for backwards compatibility, but
this should not be used as a rallying cry for continued investment in
antiquated technologies, and ignorance of modern technologies.
Fortunately businesses are a lot better at adapting to, planning for, and
scheduling change than individuals; and in a Capitalist economy, business
tends to dictate the skills that individuals begin to adopt.
There are cases where OO (PIE) doesn't make much sense. For example,
when writing VBA code, reusability is often not important. Inheritance
isn't a required feature too to copy some data from one sheet to another.


OTOH, not all OO projects require that the user design their classes with
reusability by other programs in mind (though it might be a big bonus to
plan for and implement this if possible, since you can save yourself a lot
of time and trouble on future projects). In simple projects, the use of
inheritance might well be hidden from the programmer by the Forms designer
generated code. To add to your statement, not all OO programs require the
programmer to implement Polymorphism; but it's there if you need it. Not
all simple OO programs need be complex as people make them out to be.

The key to me is that VB6 programmers moving to .NET need to first get out
of the VB6 mindset. And those that refuse to learn the new technology,
and change with the business world, will end up missing out on a lot of
business opportunities.

Just my 2 cents.

Nov 21 '05 #38

P: n/a
Hi,

Hi, while i 100% agree with the main point of your argument, that as working programmers (not hobbyists) we should always keep the "bottom line" first
and foremost in our mind, i disagree completely with your conclusion because from my experience, coding in .NET is much more efficient than any other
platform ive ever used (granted im not a computer scientist type who has
used a lot of different languages, im pretty much a
COBOL-->VB3/4/5/6-->VB.NET-->C# dork).

I'm certain that .NET is more efficient - if you are a professional
programmer who chooses to understand the intricacies involved. But what
about the "hobbyists"? These people produce results for their employers.
They may not code nice pretty interfaces or customized UI controls, but they
certainly provide the underlying business logic to get things done.


I think this argument falls into the common fallacy that because its the
"latest and greatest", it must be hard to work with and more expensive. I
think there is a good deal of evidence (at least from my own experience and talking to others who have actually used .NET) that in this case the
opposite is true.

If so, I stand corrected. However, I can only go from my own experiences
and I find VB.net to be a bit too detailed, too complex, for someone who
doesn't care about the details. Classic VB hid a lot of things that I think
VB.net exposes.


How would you react if I told you that with .NET you could produce a better product in a shorter amount of time with fewer people, and that product
would be easier/cheaper to maintain? Would you believe me or not? If not, why not?

I'd believe you. Problem is, the person producing those results needs to be
a programmer. They would require knowledge that currently is not required
using classic VB. Remember the old addage "KISS"?
The argument about programmers pushing a fancy new technology to keep
themselves employed seems like an ad-hominem (ferget my Latin pls) attack.
Actually, i see the opposite happening where teams can get smaller or stay
small and get more stuff done quicker.

Sorry if that is how I came across-not my intention.

I disagree with a couple of your assumptions here:
1. VB classic is the most productive tool for small businesses.
2. VB.NET is hard to learn.
Also, your reasoning is contradictory here: youre saying that your old VB
apps will continue to run on future OS's, yet you will be forced into a
costly rewrite of all your apps? If it doesnt make economic sense to
rewrite your existing apps, the solution is simple: don't. That is what
MSFT recommends, and also what it does... you didnt see them rush out a
completely rewritten Office suite built with C# did you? And if an
organization regularly comes to the possibly rational conclusion that
technology upgrades have no economic benefit, then you probably do not need to worry about them upgrading their OS either. So problem is doubly solved!
I don't think a single classic VBer will state that VB.net is a step
backward. In fact, I believe just the opposite. Regardless of people's
impressions, the dissension isn't about VB.net. It isn't about being able to accept change. It's about all the $$$ that will be required to move
from
'Neandethal' to 'Cro Magnon' and about all the companies that are being
FORCED to do this without any real help from MS.

Your central assumptions are wrong IMO, because .NET development is

cheaper in the long run, and no one is being forced to do anything that doesnt make economic sense. the only "forcing" that is going on is caused by natural
competition between businesses who can use technology (both the reality and the marketing) against their rivals. There are probably many industries
where Windows 3.1 and WordPerfect 5.1 are perfectly "good enough" and
competition between companies within those industries is not affected by
technology. If you find yourself to be a specialist in a field like that,
and youre happy with it, then good for you, i mean it!


Point taken. However, companies have a tool today that allow them to
produce results without the expense of hiring professional programmers.
This tool is no longer being developed, and it's replacement requires a
better knowledge of "real" programming. As such, these companies will be
FORCED to spend $$$ to produce the same RESULTS that classic VB produced.
Nov 21 '05 #39

P: n/a
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


Nov 21 '05 #40

P: n/a

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OH**************@TK2MSFTNGP15.phx.gbl...
"Michael C#" <xy*@abcdef.com> schrieb:
Most VB6 programmers (and I know a lot of them) are familiar with OO and
use OO techniques in other programming languages (C++, VB.NET, C#,
etc.). There are very few (except what I call "office developers") who
are not familiar with these techniques. So, skills and learning are not
the problem. "Getting out of the VB6 mindset" is just an easy answer
that doesn't apply in reality. It is based on symptoms, not the
reasons.

Agreed. But the so-called "office developers" who use VBA AFAIK aren't in
any danger of having the VBA engine pulled out from under them any time
soon. After all, the VBA engine hasn't been updated in what - almost a
decade? I haven't heard of any plans to move update it either... although
there definitely could be some.

If lack of knowledge and motivation are just symptoms, what is - in your
opinion - the real problem?
Unless you want to modify your previous list of three standpoints, these
people can only fall into the first category: people with large
investments in VB6.

It's doubtful that every individual or company has invested so largely in
VB6 that moving on to .NET is cost-prohibitive. Of those that are too
cost-prohibitive to "retool" their inventories of VB6 code, what's
stopping them from moving toward .NET for future development? It would
seem they already have - for the most part - the OO skills, so the
complexities of using Inheritance shouldn't be an issue to them...
For real application developers the move to .NET for new projects is not
such a big problem. However, to be able to do that, there must be a
seamless way to use existing VB6 code by the new .NET projects without a
rewrite. In addition to that, existing code still must be maintained for
years to satisfy the needs of the customers. On the other hand there is
the group of what I call "office developers", secretaries etc. who don't
have in-depth programming skills, and use VBA/VB simply for writing loops
and procedures. For them, OO increses complexity because it detracts from
the "simple" problem they want to solve.


I won't even get into the problems often caused by applications developed by
"office developers" who dabble in programming. I've seen large
organizations hire outside consultants to audit years' of financial data,
because a broken VBA macro caused their numbers to not match. I don't think
OO "detracts from the 'simple' problem they want to solve." I do think,
that in many respects, it forces you to think a problem through more
thoroughly before you jump in and hack out a half-arsed solution. I agree
that an "office developer" might not be able to put out as much poor quality
code using true OO models as they could with VBA, but the code they do put
out could be of considerably higher quality. Besides, I maintain that .NET
hides a lot of the complexity of OO programming from the user for simple
projects; unlike unmanaged C++, where you have a lot of internal management
issues to take care of in addition to the basic functionality you're trying
to implement.
IMHO, it boils down to the "VB6 mindstate". They are comfortable
programming VB6, and don't feel the need to upgrade their skill sets.


That's true for office developers who I wouldn't consider to be real
developers mostly. However, OO is not the right tool for them.


It might be, it might not be. They're not currently faced with having to
change anytime soon, however.
An opposing viewpoint - the VB6 programmers with little or no OO
experience - might be the minority, but these people are the ones who are
going to get hit the hardest. And I do know some of these types,
including your VBA developers. They seem to make the most noise about
not wanting to change.


Imagine you are a carpenter and use a little handsaw. This tool is
opmtimized for the work you do, so there is absolutely no need for a
change of the tool.


To take your analogy further, to apply it to VBA "office developers", the
ability to use your handsaw to cut 100 pieces of wood each day may make you
feel that the tool is "optimized for the work you do"; but in the end, if
those 100 pieces of wood were cut wrong, what difference does it make how
efficiently you can turn large pieces of wood into small pieces of wood?
Would you learn how to use the power saw if it doesn't fit your needs as
exactly as the handsaw did, or would you consider to buy a new handsaw
from another manufacturer instead? Would you buy a tool that is
dysfunctional because you cannot use it to do your work? I think it's
absolutely clear that those people don't want to change.


I wouldn't disavow the existence of the power saw just because I've spent
money on "Handsaw" attachments. I would use the handsaw where it worked,
and use the powersaw where it applied. Same thing I personally do with
programming languages right now. For me personally, however, VB6 and VB.NET
are two different versions of the same type of saw; not two completely
different tools altogether - as would be unmanaged C++ and VB.NET.
Now, on the topic of support for VB6 - as opposed to "not wanting to port
code to .NET" or "not wanting to learn the new technology" - I have
different feelings. I think that VB6 should continue to be supported by
MS, as there are a lot of businesses and individuals who are still
running VB6 code. I feel that VB6 will eventually phase itself out, just
like other older technologies like WFW... But I don't think it will be
dictated merely by Microsoft's force of will, but rather by the forces of
the market.


That's exactly what I think.


I think the support issue is more or less the main issue they're going to
have to deal with more than anything else. Like you said, a lot of
businesses and individuals have installed a lot of $$$ in VB6-based COM
technology and among those people, I can understand the unhappiness about
the lack of support for COM from MS. There are better ways than COM to get
the job done, but like you said, it's hard to justify upgrading to new
technology when the old technology appears to work just fine.
Nov 21 '05 #41

P: n/a
> "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. 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.) It's like
saying that investing in a college degree is "standing still". The graduate
may not have a job the day he gets his diploma, but the investment allows
him to gain that reward. So to does an investment in an upgrade from VB6 to
VB.NET set you up for the rewards of using all of the benefits of VB.NET.
(BTW, I'm not saying that it makes economic sense in all cases to convert
from VB6 to VB.NET. But to say outright that you are standing still by
doing this conversion is just plain silly.)

- Mitchell S. Honnert

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:Os*************@TK2MSFTNGP12.phx.gbl... "Michael C#" <xy*@abcdef.com> schrieb:
The key to me is that VB6 programmers moving to .NET need to first get
out of the VB6 mindset. And those that refuse to learn the new
technology, and change with the business world, will end up missing out
on a lot of business opportunities.


Most VB6 programmers (and I know a lot of them) are familiar with OO and
use OO techniques in other programming languages (C++, VB.NET, C#, etc.).
There are very few (except what I call "office developers") who are not
familiar with these techniques. So, skills and learning are not the
problem. "Getting out of the VB6 mindset" is just an easy answer that
doesn't apply in reality. It is based on symptoms, not the reasons.

<URL:http://www.joelonsoftware.com/items/2005/03/14.html>

"If you spend the money to upgrade to VB.NET, well, you just spent a lot
of money to stand still. And companies don't like to spend a lot of money
to stand still, so while you're spending the money, it probably makes
sense to consider the alternatives that you can port to that won't put you
at the mercy of a single vendor and won't be as likely to change
arbitrarily in the future. So as soon as people with large code bases
start hearing that they're going to have to work to port their apps from
VB to VB.NET with WinForms, and then they start hearing that WinForms
isn't really the future, the future is really this Avalon thing nobody has
yet, they start wondering whether it isn't time to find another
development platform."

Revolutionary change instead of evolutionary adaption (rewrite instead of
reuse) has a negative impact on overall productivity and slows down
adoption of new technology. Stability of both languages and technology
have a crucial role in software development.

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

Nov 21 '05 #42

P: n/a
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
The people and companies who have invested a lot of $$$ in VB6
development may have a valid reason to stick with it for backwards
compatibility

Exactly! But again, I didn't reference any migration issues because I
personally was looking for a more objective, side-by-side comparison,
rather than the issues of going from one to another. (Which apparently
warrants its own thread!)


One point that Herfried did bring up, which I think is relevant to any
objective side-by-side comparison, is the migration of COM technologies. A
lot of businesses did invest a lot of money in COM, DCOM, COM+, etc., and MS
has relegated it to step-child status. There are better technologies
available in .NET that do the same job (Remoting, Web Services), but COM
development was an expensive and complex proposition to begin with. Among
professional programmers, some of the ranting and raving is probably due to
aggravation over the lack of support for the COM technology they've invested
so much in. I can't see the reason for not moving forward with the newer
technology for future projects, but support for COM components that are
currently in production seems rather lacking.
Nov 21 '05 #43

P: n/a
"Keith Seeley" <ks*****@worldnet.att.net> wrote in message
news:mJ****************@bgtnsc04-news.ops.worldnet.att.net...
Hi Stephany,
. 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.

:) 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.

Now look how we hang on the same way to VB5/6.

VB3 fit the needs of the day but the day moved on and we had to start
working with the enterprise and the internet ... things that VB3 didn't
understand because it was made before those things were important.

VB5/6 was made with the things we thought were important in 1996. 10 years
later there are features that users want that we didn't know about in 1996
.... and deadlines that were no way as tight as they were 9 years ago. So
the tool was re-made to fit the needs of the developer today.

In 5 years we'll all be right back here pissing and moaning that MS is
destroying the world because we don't like VB10. (But I'm lookng foreward
to VB9 for Refactoring, a JAVA helper that VBers today simply aren't aware
that they can't live without)

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)

All the best

Robert Smith
Kirkland, WA
www.smithvoice.com
Nov 21 '05 #44

P: n/a
Being a fan of analogy, I had to comment on yours...
Imagine you are a carpenter and use a little handsaw. This tool is
opmtimized for the work you do, so there is absolutely no need for a
change of the tool. One day the handsaw doesn't work any more and the
manufacturer of the saw wants to sell you a huge power saw and doesn't
sell handsaws any more because power saws are, in his eyes, an
improvement. There is a fatal flaw in the above analogy. VB6 will not stop working on
the day that mainstream support ends. I've seen this point brought up a few
times, but haven't seen a real response. Neither your VB6 applications nor
the VB6 development tool itself will stop working "one day". To use your
analogy, the carpenter can continue to use his little handsaw all he wants.
The manufacturer may stop selling the little handsaw, but they aren't going
to come to the construction site and take it away from him. A more
appropriate analogy would be a carpenter that uses a little handsaw while
the young whippersnappers around him are using huge power saws. And to
extend on the analogy, the huge power saw may be overkill for certain small
jobs, but because the younger carpenters have become expert in its use, they
can apply the huge power saw to large or small jobs without having to go
back to the truck and exchange tools.

- Mitchell S. Honnert

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:OH**************@TK2MSFTNGP15.phx.gbl... "Michael C#" <xy*@abcdef.com> schrieb:
The key to me is that VB6 programmers moving to .NET need to first get
out of the VB6 mindset. And those that refuse to learn the new
technology, and change with the business world, will end up missing out
on a lot of business opportunities.

Most VB6 programmers (and I know a lot of them) are familiar with OO and
use OO techniques in other programming languages (C++, VB.NET, C#,
etc.). There are very few (except what I call "office developers") who
are not familiar with these techniques. So, skills and learning are not
the problem. "Getting out of the VB6 mindset" is just an easy answer
that doesn't apply in reality. It is based on symptoms, not the
reasons.


Unless you want to modify your previous list of three standpoints, these
people can only fall into the first category: people with large
investments in VB6.

It's doubtful that every individual or company has invested so largely in
VB6 that moving on to .NET is cost-prohibitive. Of those that are too
cost-prohibitive to "retool" their inventories of VB6 code, what's
stopping them from moving toward .NET for future development? It would
seem they already have - for the most part - the OO skills, so the
complexities of using Inheritance shouldn't be an issue to them...


For real application developers the move to .NET for new projects is not
such a big problem. However, to be able to do that, there must be a
seamless way to use existing VB6 code by the new .NET projects without a
rewrite. In addition to that, existing code still must be maintained for
years to satisfy the needs of the customers. On the other hand there is
the group of what I call "office developers", secretaries etc. who don't
have in-depth programming skills, and use VBA/VB simply for writing loops
and procedures. For them, OO increses complexity because it detracts from
the "simple" problem they want to solve.
IMHO, it boils down to the "VB6 mindstate". They are comfortable
programming VB6, and don't feel the need to upgrade their skill sets.


That's true for office developers who I wouldn't consider to be real
developers mostly. However, OO is not the right tool for them.
An opposing viewpoint - the VB6 programmers with little or no OO
experience - might be the minority, but these people are the ones who are
going to get hit the hardest. And I do know some of these types,
including your VBA developers. They seem to make the most noise about
not wanting to change.


Imagine you are a carpenter and use a little handsaw. This tool is
opmtimized for the work you do, so there is absolutely no need for a
change of the tool. One day the handsaw doesn't work any more and the
manufacturer of the saw wants to sell you a huge power saw and doesn't
sell handsaws any more because power saws are, in his eyes, an
improvement. Would you learn how to use the power saw if it doesn't fit
your needs as exactly as the handsaw did, or would you consider to buy a
new handsaw from another manufacturer instead? Would you buy a tool that
is dysfunctional because you cannot use it to do your work? I think it's
absolutely clear that those people don't want to change.
Now, on the topic of support for VB6 - as opposed to "not wanting to port
code to .NET" or "not wanting to learn the new technology" - I have
different feelings. I think that VB6 should continue to be supported by
MS, as there are a lot of businesses and individuals who are still
running VB6 code. I feel that VB6 will eventually phase itself out, just
like other older technologies like WFW... But I don't think it will be
dictated merely by Microsoft's force of will, but rather by the forces of
the market.


That's exactly what I think.

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

Nov 21 '05 #45

P: n/a
Keith,

In past there were sail ship companies, some of them changed to steam ships
and after that too transport companies, from the last many still exist.

In past in the US there were stagecoach companies some of them changed to
transport, from the last many still exist.

Do these samples fit better?

Cor
Nov 21 '05 #46

P: n/a
Herfried,

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.

While he is with that loosing a lot of time and can spend better his time
with migrating it to VBNet.

Just my 2 Ecents

Cor
Nov 21 '05 #47

P: n/a
fix: "and deadlines that *are far tighter than* they were 9 years ago." :)

-s
"smith" <rc********@smithvoiceTAKEOUT.com> wrote in message
news:Di*****************@newsread3.news.pas.earthl ink.net...
"Keith Seeley" <ks*****@worldnet.att.net> wrote in message
news:mJ****************@bgtnsc04-news.ops.worldnet.att.net...
Hi Stephany,
. 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.

:) 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.

Now look how we hang on the same way to VB5/6.

VB3 fit the needs of the day but the day moved on and we had to start
working with the enterprise and the internet ... things that VB3 didn't
understand because it was made before those things were important.

VB5/6 was made with the things we thought were important in 1996. 10
years later there are features that users want that we didn't know about
in 1996 ... and deadlines that were no way as tight as they were 9 years
ago. So the tool was re-made to fit the needs of the developer today.

In 5 years we'll all be right back here pissing and moaning that MS is
destroying the world because we don't like VB10. (But I'm lookng foreward
to VB9 for Refactoring, a JAVA helper that VBers today simply aren't aware
that they can't live without)

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)

All the best

Robert Smith
Kirkland, WA
www.smithvoice.com

Nov 21 '05 #48

P: n/a
"Cor Ligthert" <no************@planet.nl> schrieb:
However telling with that, as you do now with this message agreeing with
Richard, that all my messages are gibberish (Kauderwelsch) is a little bit
going too far in my opinion.


I didn't agree with Richard!

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

Nov 21 '05 #49

P: n/a
Herfried,

I didn't agree with Richard!

That was all I wanted to see.

:-)

Cor
Nov 21 '05 #50

66 Replies

This discussion thread is closed

Replies have been disabled for this discussion.