VB6 easier than VB.NET?

[Mitchell S. Honnert]

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

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

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

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

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

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

- Mitchell S. Honnert

 

[Michael C#]

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]

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

 

[David]

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]

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

 

[Charles Law]

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

 

[Herfried K. Wagner [MVP]]

Mitchell,

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?

 

[Herfried K. Wagner [MVP]]

Mitchell,

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.

 

[Richard Myers]

Stephany,

Your post makes you seem like a shithead.

Richard

 

[Michael C#]

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.

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.

 

[Michael C#]

Richard,

Your post erases all doubt.

 

[Herfried K. Wagner [MVP]]

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.

 

[Stephany Young]

I rest my case.

Stephany,

Your post makes you seem like a shithead.

Richard

 

[Keith Seeley]

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.

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

 

[Richard Myers]

I rest my case.

On what im not sure but.... thank God either way.

 

[Stephany Young]

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.

 

[Richard Myers]

'Inexpensive' and 'Cost Effective' do not mean the same thing.

Yes they do.

 

[Michael C#]

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.

 

[JiangZemin]

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

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!

 

[smith]

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