VB6 easier than VB.NET?

[Michael C#]

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

If lack of knowledge and motivation are just symptoms, what is - in your
opinion - the real problem?

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

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

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

It might be, it might not be. They're not currently faced with having to
change anytime soon, however.

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

To take your analogy further, to apply it to VBA "office developers", the
ability to use your handsaw to cut 100 pieces of wood each day may make you
feel that the tool is "optimized for the work you do"; but in the end, if
those 100 pieces of wood were cut wrong, what difference does it make how
efficiently you can turn large pieces of wood into small pieces of wood?

Would you learn how to use the power saw if it doesn't fit your needs as
exactly as the handsaw did, or would you consider to buy a new handsaw
from another manufacturer instead? Would you buy a tool that is
dysfunctional because you cannot use it to do your work? I think it's
absolutely clear that those people don't want to change.

I wouldn't disavow the existence of the power saw just because I've spent
money on "Handsaw" attachments. I would use the handsaw where it worked,
and use the powersaw where it applied. Same thing I personally do with
programming languages right now. For me personally, however, VB6 and VB.NET
are two different versions of the same type of saw; not two completely
different tools altogether - as would be unmanaged C++ and VB.NET.

That's exactly what I think.

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

 

[Mitchell S. Honnert]

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

of money to stand still."

I admit that I haven't read the entire article, but this particular quote is
patently ridiculous. Even if you only duplicate existing functionality in
the new VB.NET application, you have gained the ability to take advantage of
all of VB.NET's features. For any future development, you have the new IDE,
you have the ease of extending an OO application, you have all of the other
myriad of benefits that VB.NET has over VB6. (Not to mention, all of the
benefits that would come from redesigning the underlying code.) It's like
saying that investing in a college degree is "standing still". The graduate
may not have a job the day he gets his diploma, but the investment allows
him to gain that reward. So to does an investment in an upgrade from VB6 to
VB.NET set you up for the rewards of using all of the benefits of VB.NET.
(BTW, I'm not saying that it makes economic sense in all cases to convert
from VB6 to VB.NET. But to say outright that you are standing still by
doing this conversion is just plain silly.)

- Mitchell S. Honnert

 

[Michael C#]

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

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

 

[smith]

Hi Stephany,

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

 

[Mitchell S. Honnert]

Being a fan of analogy, I had to comment on yours...

Imagine you are a carpenter and use a little handsaw. This tool is
opmtimized for the work you do, so there is absolutely no need for a
change of the tool. One day the handsaw doesn't work any more and the
manufacturer of the saw wants to sell you a huge power saw and doesn't
sell handsaws any more because power saws are, in his eyes, an
improvement.

There is a fatal flaw in the above analogy. VB6 will not stop working on
the day that mainstream support ends. I've seen this point brought up a few
times, but haven't seen a real response. Neither your VB6 applications nor
the VB6 development tool itself will stop working "one day". To use your
analogy, the carpenter can continue to use his little handsaw all he wants.
The manufacturer may stop selling the little handsaw, but they aren't going
to come to the construction site and take it away from him. A more
appropriate analogy would be a carpenter that uses a little handsaw while
the young whippersnappers around him are using huge power saws. And to
extend on the analogy, the huge power saw may be overkill for certain small
jobs, but because the younger carpenters have become expert in its use, they
can apply the huge power saw to large or small jobs without having to go
back to the truck and exchange tools.

- Mitchell S. Honnert

 

[Cor Ligthert]

Keith,

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

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

Do these samples fit better?

Cor

 

[Cor Ligthert]

Herfried,

I don't think that this is true for most VB6 users, at least not for them
using VB6 in a professional manner.

Certainly not, are you afraid for VBNet. An inventive professional will
maybe wait a while; however not rely on an old product from Microsoft
anymore. He does not even know if the bugs created by the new updates can
harm his old product and has to work again to repair that.

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

Just my 2 Ecents

Cor

 

[smith]

fix: "and deadlines that *are far tighter than* they were 9 years ago."

-s

 

[Herfried K. Wagner [MVP]]

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

I didn't agree with Richard!

 

[Cor Ligthert]

Herfried,

I didn't agree with Richard!

That was all I wanted to see.



Cor

 

[Herfried K. Wagner [MVP]]

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.

 

[Mitchell S. Honnert]

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

results that are produced.

If you are referring to an indifference to what the underlying code at the
expense of the end result (say, from the end-users perspective), I would
have to disagree. I think that what a purely results-focused model does not
properly account is maintenance. Yes, you may have a VB6 system and a
VB.NET system that are functionally identical, but I believe that the VB.NET
code would be much easier to maintain and support. If for no other reason
than today it's more likely you'll be able to find a programmer who can (and
wants to) program in VB.NET. So, to be cost-effective, a company *does*
have to be concerned with the technology, at least in this respect.

The main point I was trying to make is that classic VB was (sorry, is) a
tool that creates solutions rapidly (RAD), and a degree in computer
programming was not required. Thus it allowed people to produce RESULTS
for
their company quickly and inexpensively (sorry again, cost effectively)
even
if the METHOD (the actual code) used wasn't optimal.

This brings up the distinction inexpensive and cost-effective again. I
think that VB6, in may ways, gave a false sense of empowerment to the
dilettante programmer. It made them think they were easilly (there's that
word "easy" again) creating a working program, but what they were really
creating was the worst kind of program there is, one that looks like it's
working properly but isn't. On the other hand, I personally believe that
the same thing could be said of VB.NET. I don't think this condition is
particular to VB6. The point is that just because something is inexpensive,
doesn't mean that it's cost-effective. If the guy in accounting whips out a
quick little intra-office app which turns out to have been giving incorrect
data for a year, is that really inexpensive in the long run?

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

- Mitchell S. Honnert

 

[Mitchell S. Honnert]

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

than one decade will rarely be changed or extended. It just works. There
is no need for VB.NET's features

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

- Mitchell S. Honnert

 

[Cor Ligthert]

Herfried,

There actually are valid reasons why COBOL code which is decades old is
still used in banking and for financial transactions. A rewrite would hold
a risk.

Good point, what I did not expect from you (that very positive meant) ,
however see my other message at the end of this thread.

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

I agree as well, see the same message.

Cor

 

[Michael C#]

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

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

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

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

 

[Keith Seeley]

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

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

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

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

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

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

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

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

 

[Cor Ligthert]

Michael,

I have done many program languages. They are evaluating.

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

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

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

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

I like your contributions in this newsgroup by the way.

Cor

 

[Mitchell S. Honnert]

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

- Mitchell S. Honnert

 

[Herfried K. Wagner [MVP]]

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

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

 

[Richard Myers]

He did not understand the message

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

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

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

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

This is complete bullocks. In much the same way as the victor in war tends
to rewrite history to suit themselves, those who do change and fail as a
result of this "early adoption" are simply discarded and forgotten.
Therefore only those who experience success thru change prosper. Change
itself is no guarantee for success. Stephanie seems to be completely blind
to all the change "failures" of which there would be many many more than
change successes..
consequently the species did not survive.

What has biological evolution got to do with "comfort zones", vb6 or
vb.net? Can a duck tap play guitar? No. According to Stephanie this makes
the duck "lazy". Its simply staying within its comfort zone. More likely
its because its... just a duck. Being "unable to change" has nothing to do
with being not willing to change even after a better alternative has been
communicated, witnessed and understood.
without the range of textiles that we take for granted in our everyday life
if
Again most of this is just unneccessary dribble. Her whole post reeks of
someone who spent the morning @ a doctors waiting room reading time
magazine/natures journal and now decided that she will tell us all what she
thinks she knows regardless of what the actual topic is. All so she can
make this point
unreasonably resists change.

Which is completely out of context. "Unreasonably resists change". Whats
unreasonable about a company with a VB6 library developed over 10 years
using 100s' if not 1000's of man hours to produce, a library which is
*fully* debugged, in production, one that is perhaps even considered a sub
platform for their products and services not converting to dotNet? Sounds
like common sense business logic to me. Sounds very reasoned and well
thought out. As for "comfort zone"....try "livelihood" = mortgage paid,
food in their kids mouths. If they dont need dotNet, or haven;t yet had the
benefits of some dotNet related technologies explained to them, then they
can hardly be called a "Luddite".

What has any of this passage got to do with anything? If its supposed to
set up some argument that its better for everyone if we move to dotNet then
it failed.
"The rights of the indivdual sacrosanct". Just more my waffle that
completely misses the point that someone using VB6 does not prevent someone
from using dotNet. The greater good is not at all comprimised which should
be very obvious to Stephanie considering that she early postulated that
"those who dont change, wont survive anyway". So shes basically just
contridicting herself.

I dont what shes trying to paraphase here but its just another ridiculous
inclusion that serves no purpose and has nothing to do with vb6, vb.net or
"comfort zones".

Well first off...im not sure of the ergonomics of Stepahines working
environment but it seems a little ambitious to be telling the developer
community to "get off their backsides" and expect a result. Whats more they
are in the "real world", not some Microsofty wet dream whereby everyone
works in some completely standardised homogeneous environment and
immediately upgrades every tme Microsoft releases a new version of product
xxx. You see in the real world Stephanie we have constraints....the biggest
one is more generally referred to as "economics".

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

And as for [personal libraries of esoteric VB6 code], maybe Stephanies'
doodlings fit into those catagories but some companies *in the real world*
actually have those libraries in production, running bug free, and they
dont want to have to redevelop and redeploy. Since we're talking about the
"real world" and all.

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

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

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

Richard