"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:OAoSx1LMFHA.2748@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
>
>

"Michael C#" <x**@yomomma.com> wrote in message
news:egKJQ$LMFHA.580@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:OAoSx1LMFHA.2748@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
>>
>>
>
>

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:O$6IsoNMFHA.3336@TK2MSFTNGP10.phx.gbl...
> Mitchell,
>
> "Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb:
> >> a lot of VB programmers were really in their comfort zone with 6.
> >
> > You've hit on one of main points of my thoughts on this topic.  I
> > hypothesize that the people who think that VB6 is easier than VB.NET are
> > those who were/are "in the VB6 zone".  They had become accustomed to all
> > of the workarounds necessary to get anything done in VB6, so they
> > mistakenly believe that VB6 is easier because it's easier for *them*.
>
> I have to disagree.  It's not easier for them because they know
workarounds
> to do things the language was not designed for, but because the tool its
set
> of features is more appropriate for the work they are doing.  Take a look
at
> Office automation code -- most of this code doesn't use any "hacks", it
> simply uses the Office object model to get certain things done.
>
> --
>  M S   Herfried K. Wagner
> M V P  <URL:http://dotnet.mvps.org/>
>  V B   <URL:http://classicvb.org/petition/>
>

"Michael C#" <x**@yomomma.com> wrote in message
news:egKJQ$LMFHA.580@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:OAoSx1LMFHA.2748@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
>>
>>
>
>

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

"David" <dfos***@woofix.local.dom> wrote in message
news:slrnd45u5a.8tq.dfoster@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.
>
>
>

"Stephany Young" <noone@localhost> wrote in message
news:OnKNzqMMFHA.3512@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#" <x**@yomomma.com> wrote in message
> news:egKJQ$LMFHA.580@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:OAoSx1LMFHA.2748@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
> >>
> >>
> >
> >
>
>

"Cor Ligthert" <notmyfirstn***@planet.nl> wrote in message
news:ud4APHRMFHA.3420@tk2msftngp13.phx.gbl...
> Richard
> > Stephany,
> >
> > Your post makes you seem like a sh*thead.
> >
> 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 Ligthert" <notmyfirstn***@planet.nl> wrote in message
news:uJRshSSMFHA.1172@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 sh*thead.
>
> >Richard
>
> The message from Stephany is in my opinion very much On thread.
>
> Cor
>
>

"Richard Myers" <f***@address.com> wrote in message
news:u1qFlXYMFHA.3708@TK2MSFTNGP14.phx.gbl...
>> >> As a species (homo sapien), we are comfortable with what we know. The
>> >> inverse is also true - we are NOT comfortable with what we DON'T know.
>> > This truism has been proved again and again throughout the course of
> history.
>
> she suggests what follows is going to back her so called truism.
>
>> >> Because of this, change tends to resisted, (especially in the early
>> > stages),until such time as there is a widespread understanding of the
> 'technology'
>> >> behind the change.
>
> Change does not "tend to be resisted". It simply isn't always immediately
> accepted until its benefits have been sufficiently communicated, witnessed
> and understood.

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:u7wEgmNMFHA.3420@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.)

"Michael C#" <x**@abcdef.com> wrote in message
news:JQK0e.409$tu6.130@fe11.lga...
>
> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
> news:u7wEgmNMFHA.3420@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.
>

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:OstCQZOMFHA.732@TK2MSFTNGP12.phx.gbl...
> "Michael C#" <x**@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.

"Michael C#" <x**@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...

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

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:OHZSxYTMFHA.2940@TK2MSFTNGP15.phx.gbl...
> "Michael C#" <x**@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/>

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:OstCQZOMFHA.732@TK2MSFTNGP12.phx.gbl...
> "Michael C#" <x**@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/>

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:OxwFhAWMFHA.568@TK2MSFTNGP09.phx.gbl...
> "Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb:
>>> "If you spend the money to upgrade to VB.NET, well, you just spent a lot
>>> of money to stand still."
>> I admit that I haven't read the entire article, but this particular quote
>> is patently ridiculous.  Even if you only duplicate existing
>> functionality in the new VB.NET application, you have gained the ability
>> to take advantage of all of VB.NET's features.
>
> It seems that you missed the point.  Code which has been tested for more
> than one decade will rarely be changed or extended.  It just works.  There
> is no need for VB.NET's features (which are in many cases limited and
> different compared to VB6's features, for example, the lack of arbitrary
> array bounds in .NET), a rewrite would cost a lot (about 60 percent of
> original development cost) and would introduce new bugs, which cannot be
> accepted in real-world application.  There actually are valid reasons why
> COBOL code which is decades old is still used in banking and for financial
> transactions.  A rewrite would hold a risk.
>
>> For any future development, you have the new IDE, you have the ease of
>> extending an OO application, you have all of the other myriad of benefits
>> that VB.NET has over VB6.  (Not to mention, all of the benefits that
>> would come from redesigning the underlying code.)
>
> For new projects it's always a good idea to use state-of-the-art tools.
> However, this doesn't imply that it's always the best solution to rewrite
> the existing code.  That's rarely a good solution because of cost and
> risk, and should be avoided whenever possible.
>
> --
> M S   Herfried K. Wagner
> M V P  <URL:http://dotnet.mvps.org/>
> V B   <URL:http://classicvb.org/petition/>

"Richard Myers" <f***@address.com> wrote in message
news:%237mIaKOMFHA.1096@tk2msftngp13.phx.gbl...
> Stephany,
>
> Your post makes you seem like a sh*thead.
>
> Richard
>
> "Stephany Young" <noone@localhost> wrote in message
> news:OnKNzqMMFHA.3512@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#" <x**@yomomma.com> wrote in message
>> news:egKJQ$LMFHA.580@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:OAoSx1LMFHA.2748@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
>> >>
>> >>
>> >
>> >
>>
>>
>
>

>
>
> "Richard Myers" <f***@address.com> wrote in message
> news:%237mIaKOMFHA.1096@tk2msftngp13.phx.gbl...
> > Stephany,
> >
> > Your post makes you seem like a sh*thead.
> >
> > Richard
> >
> > "Stephany Young" <noone@localhost> wrote in message
> > news:OnKNzqMMFHA.3512@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#" <x**@yomomma.com> wrote in message
> >> news:egKJQ$LMFHA.580@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:OAoSx1LMFHA.2748@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
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>

"Charles Law" <bl***@nowhere.com> wrote in message
news:eEC72INMFHA.1144@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" <dfos***@woofix.local.dom> wrote in message
> news:slrnd45u5a.8tq.dfoster@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.
> >
> >
> >
>
>

"Keith Seeley" <ksee***@worldnet.att.net> wrote in message
news:ZuL0e.451367$w62.247005@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.

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

"smith" <rcsTAKE***@smithvoiceTAKEOUT.com> wrote in message
news:DiW0e.4221$H06.1726@newsread3.news.pas.earthlink.net...
> "Keith Seeley" <ksee***@worldnet.att.net> wrote in message
> news:mJV0e.7280$cg1.623@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
>

"Keith Seeley" <ksee***@worldnet.att.net> wrote in message
news:mJV0e.7280$cg1.623@bgtnsc04-news.ops.worldnet.att.net...
> Hi Stephany,
>
>>
>> The same type of situation occured early last century when companies were
>> dragged kicking and screaming from using horse-drawn transport to
> motorised
>> transport. Regardless of the rights, wrongs or indifferences of it, it
>> happened. Those that embraced motorised transport tended to propsper and
>> those that didn't saw their profits dwindle until they did. Did the world
>> stop turning? No!
>>
>
> Pespective.  Companies shouldn't have to care about the technology, only
> the
> results that are produced.
> Motorized transport produced better results than horse drawn carriages and
> as such replaced the older technology.  Will VB.net produce better RESULTS
> for the customer?  AFAIK VB.net changes the METHOD to produce software,
> not
> the results PRODUCED by the software.  And that METHOD requires a greater
> skill set than classic VB.  1+1= 2 and in any language.
>
> The main point I was trying to make is that classic VB was (sorry, is) a
> tool that creates solutions rapidly (RAD), and a degree in computer
> programming was not required.  Thus it allowed people to produce RESULTS
> for
> their company quickly and inexpensively (sorry again, cost effectively)
> even
> if the METHOD (the actual code) used wasn't optimal.  Classic VB
> accomplished this by hiding much of the underlying technical details from
> the programmer.  VB.net may fit this bill (not from what I've seen yet),
> but
> it appears that the product requires a lot MORE knowledge of what goes on
> under the hood than classic VB.  And as I stated previously, this isn't
> necessarily a bad thing but what it does is take the tool away from casual
> programmers ("bad" programmers according to some).
>
>
>>
>> In your penultimate paragraph you allude to 'VB Classic' being phased
>> out.
>> I'm interested as to what inside information you have that the rest of us
>> aren't privy to. We are all aware that mainstream for VB6 ceases as at
>> the
>> the end of this month but I have not seen any information about VB6 being
>> phased out any earlier than planned. The whole point is that VB6 is NOT
>> being taken away, anyone who uses it today will still be able to use it
> next
>> month, and that nobody is being FORCED to change. Those that want to
> change
>> can and those that don't, (having been made aware of the situation and
>> therefore making their decision on an infomed basis), can continue on as
>> they do now.
>>
>
> Perspective.  MS chose to stop development of an excellent tool for casual
> programmers that allowed them to "cost effectively" produce results for
> their employer.  The replacement tool requires more in-depth knowledge of
> "real" programming and I suspect it will not be as accessible as classic
> VB.
> The result is that more companies will have to hire professional
> developers
> to do their work, which is an expenditure that previously didn't exist.
> VB.net will mean more $$$ to small businesses who DO want to keep up with
> current technology.  In this respect, companies WILL be FORCED to spend
> more
> money to keep up with the "latest and greatest", even though the RESULTS
> produced will be no different than before.
>
> Perspective.  It's about the RESULTS for the CUSTOMER, not about the
> details
> of being a professional programmer.  I realize it's tough for the
> participants of this group to understand, but there are many people who do
> NOT program for a living yet do so anyway to achive results for their
> employers.  It's these people and their companies who are losing big
> time -
> their tool is being phased out and they will have to hire someone to do
> the
> work for them.  Good for you folks, bad for them.
>
>
>

"Keith Seeley" <ksee***@worldnet.att.net> wrote in message
news:ZuL0e.451367$w62.247005@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 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!
>

>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

news:42441c45.6181338@msnews.microsoft.com...
> Look at one specific application, serial I/O.
>
> In VB6 there was the MSComm control that handled the OnComm events.
> In VB.Net, there is nothing built in.  You can shoe-horn the MSComm
> control in; or more recently you could use some of the posted
> solutions, but none of the posted solutions are as easy to use as the
> MSComm control, in my opinion.  Most of the posted solutions that I
> have seen only do polling, ...no event generation, which greatly
> limits the responsiveness.  I've resorted to mixed VB.NET and C
> programming for my solution.  If I were to write a class, I'd do it in
> C++, not VB.NET.
>
> On Thu, 24 Mar 2005 17:04:23 -0500, "Mitchell S. Honnert"
>>So, are there people out there that really think VB6 is easier than
>>VB.NET?
>>Why?  Do you think it depends on the size of the project?  Are there other
>>factors?  Help me understand because I just don't get this attitude.
>> - Mitchell S. Honnert
>

"Mitchell S. Honnert" wrote:

> In some recent posts, I've seen people who seem to be waxing nostalgic with
> respect to the "ease of use" of Visual Basic 6.  I can't quite put my finger
> on it, but they seem to be implying that VB6 was simpler to use than VB.NET,
> that it was somehow easier to write programs in VB6 than in VB.NET.  I have
> to admit I'm astonished by this attitude.  I can't see any rationality to
> the idea that, on the whole, VB6 is easier than VB.NET.
>
> I *can* see where someone who is entrenched in the VB6 language would find
> the switch to VB.NET daunting.   (VB.NET is, after all, a major departure
> from VB6.)  But what I can't see is someone making the judgment, from an
> objective standpoint, that VB6 is easier than VB.NET.  In other words, just
> because *you* happen to be so much more familiar with the collective set of
> eccentricities, peculiarities, and inconsistencies that is known as Visual
> Basic 6 that you can write applications faster in VB6 than VB.NET, it
> doesn't mean that VB6 is easier.
>
> I've heard it argued that a drawback to .NET's full support of object
> oriented programming is that it makes coding more difficult.  "I just want
> to get in there and write some code; I don't want to have to worry about all
> of that OO crap."  Perhaps the principle holds true for the "Hello World"
> type of application, but for any non-trivial application, I just don't see
> how the well-ordered, clean, and consistent implementation of OO principles
> in the .NET framework couldn't be seen as an easier environment in which to
> develop.
>
> I guess I'm looking at it from the perspective of teaching someone who is
> completely new to programming how to be a programmer.  In this case, which
> would be easier, VB6 or VB.NET?  There's not doubt in my mind that VB.NET
> would be easier.  In my opinion, in a relatively short period of time, I
> could teach someone the principles of object oriented programming and the
> basic layout of the .NET Framework.  But if I applied this same amount of
> time to teaching someone VB6 from scratch, I'd get so bogged down in telling
> them about all of the quirks, workarounds, and exceptions-to-the-rule that
> I'd run out of time before I could even get through the basics.  (I wouldn't
> even want to call this type of knowledge transfer "teaching".)
>
> The point is that even though there might be an initially steeper learning
> curve to get past the principles of object oriented programming, once you
> have the "OO epiphany" and truly grok the principles, the rest is smooth
> sailing.  But with VB6, you may get up and running a bit faster, but your
> daily process of coding is so taken up by finding workarounds to a seemingly
> endless series of quirky behaviors or things that just don't operate how you
> think they would, that the overall development time is actually much longer.
>
> So, are there people out there that really think VB6 is easier than VB.NET?
> Why?  Do you think it depends on the size of the project?  Are there other
> factors?  Help me understand because I just don't get this attitude.
>
>  - Mitchell S. Honnert
>
>
>