Microsoft MVPs Say They Want Old VB Back

[Paul Clement]

¤ > Its strange then that C++ has been most carefully managed such that
¤ > Microsoft's own codebase has been protected, to the extent that
¤ > Microsoft's C++ compilers have edged very slowly towards full standards
¤ > compliance. How would you explain that?
¤ To be honest, I don't know enough about C++ to make a judgment. Perhaps you
¤ can tell me: was C++ so much ahead of its time that it didn't *need* the
¤ radical makeover that VB6 received? Did this dramatic change already happen
¤ from C to C++? I honestly don't know.

C++ just had fewer proprietary implementations. But, I think if you talked to some C++ programmers
they would tell you that they have suffered some grief in the past with respect to upgrades. In
addition, C++ *does* have some compatibility issues when using the managed extensions. It isn't the
perfect world that those who don't use the language would lead you to believe, even though they
probably fair much better than Classic Visual Basic developers.


Paul
~~~~
Microsoft MVP (Visual Basic)

 

[Mitchell S. Honnert]

If a reasonable migration path were available, there would be no need to.
And if pigs had wings, they could fly. At this point in the conversation,
the question isn't *if* there is a "reasonable migration path" as you define
it, but *should* there be one as you define it. Sure, if VB.COM existed
right now, many people would find it easier to eventually convert over to
VB.NET. But the question at hand is if Microsoft *should*, either from a
moral or financial standpoint, make VB.COM available

The migration path is perfectly do-able. It would (for instance) be a
perfectly feasible project to do a language using most of the VB6 syntax
that compiled to .NET itself.

Just because a project is "do-able" and "feasible", doesn't mean that it's
economically justifiable. Sure, if Microsoft chose to do so, it could
develop VB.COM. But from the very fact that they haven't done so by this
point clearly indicates that Microsoft doesn't believe that such a project
would be the proper use of its resources. They *could* develop VB.COM, they
just don't think it's worth it.

It such a product could still have access to everything in the framework.
There really is ver little about the framework that would necessitate a
difference in behavior - the change in object management from
deterministic finalization to garbage collection is about the only
significant issue.

I somehow think that the implementation of VB.COM would be more than just a
matter of overcoming a couple of insignificant behavior differences between
VB6 and .NET. In fact, much of my opposition to VB.COM arises not so much
out of a sense that Microsoft couldn't do more to support VB6 (they could
and *should*), but from the idea that this approach is overkill. Because
the creation of VB.COM would be such a major undertaking, it would steal
resources away from enhancing the current generation of VB development tool,
VB.NET.

I would accept that, Microsoft does not have an obligation to provide
eternal support for little-used languages. But Visual Basic hardly came
into that category!

I noticed you added the "little-used" qualifier in there. Therein lies the
key to our differences on this particular aspect of the argument. I believe
Microsoft's obligation to support a product, even an application development
tool, is a function purely of time, whereas you apparently believe it should
be a function of usage.

Your key point here seems to be "it doesn't matter how many people are
currently using VB6". In practical terms, that it not true.

Obviously Microsoft doesn't agree with you; they think it *is* true.

It is in Microsoft's own best interest to get the large number of
developers still using VB6 to move to current tools, if only because
Microsoft can make money from selling those tools.

If we're discussing what's in Microsoft's best interest (and no longer about
what they *should* do), then I would still have to disagree. I think that
in Microsoft's mind, they don't have to do much of anything more than what
they've already done and people will eventually switch over to and buy
VS.NET. I don't pretend to know that Microsoft's internal motivation is,
but if I had to guess, I'd say that the whole idea of VB.COM would be viewed
as a bad investment. The expression "Why buy the cow when you can get the
milk for free" comes to mind. In other words, why would Microsoft undertake
a huge project to help people to convert from VB6 to VB.NET when they'll be
forced to do so anyway? From a purely capitalistic viewpoint, not paying
for a huge VB.COM project is in Microsoft's best interest.

- Mitchell S. Honnert

 

[Mitchell S. Honnert]

Thanks for the extra info, Paul. As I've said, I'm no expert in C++, but
what you say makes sense on an intuitive level. To me, it seems only
natural that a language that operates on a level closer to the internal
functioning of the computer (C++) would have to change less with a
change/upgrade of the OS. Visual Basic of course hides much of the internal
workings of the computer, so of course it's more susceptible to OS changes.

I'm guessing that there might be a parallel in the C++ world and the VB
world when a new version of Windows is released. Specifically that a VB6
developer might have to port their application to VB.NET or find some other
workaround in order for their application to run on the new OS, whereas the
C++ developer would have to rewrite or update one of their customized
libraries in order to account for the changes in the OS. In both cases,
there could be a significant amount of work, but because it's at the
programming language level with VB6 (instead of the custom library level),
the necessary rework is perceived as more of the "fault" of Microsoft.
Maybe I'm reading too much into the information in your post, but the
scenario I describe sounds plausible.

- Mitchell S. Honnert

 

[Doug Taylor]

And if pigs had wings, they could fly. At this point in the conversation,
the question isn't *if* there is a "reasonable migration path" as you define
it, but *should* there be one as you define it. Sure, if VB.COM existed
right now, many people would find it easier to eventually convert over to
VB.NET. But the question at hand is if Microsoft *should*, either from a
moral or financial standpoint, make VB.COM available

Just because a project is "do-able" and "feasible", doesn't mean that it's
economically justifiable. Sure, if Microsoft chose to do so, it could
develop VB.COM. But from the very fact that they haven't done so by this
point clearly indicates that Microsoft doesn't believe that such a project
would be the proper use of its resources. They *could* develop VB.COM, they
just don't think it's worth it.

I somehow think that the implementation of VB.COM would be more than just a
matter of overcoming a couple of insignificant behavior differences between
VB6 and .NET. In fact, much of my opposition to VB.COM arises not so much
out of a sense that Microsoft couldn't do more to support VB6 (they could
and *should*), but from the idea that this approach is overkill. Because
the creation of VB.COM would be such a major undertaking, it would steal
resources away from enhancing the current generation of VB development tool,
VB.NET.

I noticed you added the "little-used" qualifier in there. Therein lies the
key to our differences on this particular aspect of the argument. I believe
Microsoft's obligation to support a product, even an application development
tool, is a function purely of time, whereas you apparently believe it should
be a function of usage.

Obviously Microsoft doesn't agree with you; they think it *is* true.

If we're discussing what's in Microsoft's best interest (and no longer about
what they *should* do), then I would still have to disagree. I think that
in Microsoft's mind, they don't have to do much of anything more than what
they've already done and people will eventually switch over to and buy
VS.NET. I don't pretend to know that Microsoft's internal motivation is,
but if I had to guess, I'd say that the whole idea of VB.COM would be viewed
as a bad investment. The expression "Why buy the cow when you can get the
milk for free" comes to mind. In other words, why would Microsoft undertake
a huge project to help people to convert from VB6 to VB.NET when they'll be
forced to do so anyway? From a purely capitalistic viewpoint, not paying
for a huge VB.COM project is in Microsoft's best interest.

- Mitchell S. Honnert

I've been following this debate at a distance, surely the whole thing
comes down to economics. Microsoft are not selling any more new VB 6
licenses so there is a zero revenue stream. They have in place a new
tool with a migration path (perhaps not ideal, but it exists)
generating a revenue stream.

A few users want a new migration path, lets do some costing, guesses
only
1) development of new tool 2,000,000
2) testing and QA 500,000
3) marketing 100,000
4) profit 400,000 to make it easy

so we have a total aimed minimum return of 3,000,000
I've seen figures of around 1000 people are demanding this so the
minimum price after corporate discounts needs to be 3,000 are people
going to pay this for a migration tool, probably not enough so the
project doesn't go ahead.

Doug Taylor.

 

[Doug Taylor]

Thanks for the extra info, Paul. As I've said, I'm no expert in C++, but
what you say makes sense on an intuitive level. To me, it seems only
natural that a language that operates on a level closer to the internal
functioning of the computer (C++) would have to change less with a
change/upgrade of the OS. Visual Basic of course hides much of the internal
workings of the computer, so of course it's more susceptible to OS changes.

I'm guessing that there might be a parallel in the C++ world and the VB
world when a new version of Windows is released. Specifically that a VB6
developer might have to port their application to VB.NET or find some other
workaround in order for their application to run on the new OS, whereas the
C++ developer would have to rewrite or update one of their customized
libraries in order to account for the changes in the OS. In both cases,
there could be a significant amount of work, but because it's at the
programming language level with VB6 (instead of the custom library level),
the necessary rework is perceived as more of the "fault" of Microsoft.
Maybe I'm reading too much into the information in your post, but the
scenario I describe sounds plausible.

- Mitchell S. Honnert

C++ had an external controlling body setting standards and was a
designed language, VB for all its strengths was a language that had
grown organically and had gone down a number of dead ends.

Perhaps more importantly, Anders Heijlsberg who heads up the .Net
project wanted all four of the mainstream .net languages (c#, C++, VB
and Delphi) to have a basically the same functionality so the common
core would be the same and only the syntax varied. Also Anders was a
founder of Borland and designer of their Pascal and Delphi languages,
so he didn't have any allegience to VB.

VB had to change the most to acheive this end, for example it has gone
from a language (8K Basic) with no typing and global scope, to a
language with strong typing and very tight scope rules.

Doug Taylor

 

[Jonathan West]

I've been following this debate at a distance, surely the whole thing
comes down to economics. Microsoft are not selling any more new VB 6
licenses so there is a zero revenue stream. They have in place a new
tool with a migration path (perhaps not ideal, but it exists)
generating a revenue stream.

A few users want a new migration path, lets do some costing, guesses
only
1) development of new tool 2,000,000
2) testing and QA 500,000
3) marketing 100,000
4) profit 400,000 to make it easy

so we have a total aimed minimum return of 3,000,000
I've seen figures of around 1000 people are demanding this so the
minimum price after corporate discounts needs to be 3,000 are people
going to pay this for a migration tool, probably not enough so the
project doesn't go ahead.

Even assuming your figures for the cost of doing it, I suspect that your
figures for the number of people to whom it could be marketed are way on the
low side.

Already, nearly 4000 people have signed the petition.

According to a Visual Expert survey recently
(http://www.visual-expert.com/us/info/survey_vb_2004_results.htm) 80% of VB
developers are still using VB5 or VB6 as their primary version of VB.

Microsoft used to claim that there were 6 million VB developers. Let's
assume for the purpose discussion that 5 million of those are hobbyists who
Microsoft has decided to there is no money to be made out of, and
concentrate on the million writing significant code. According to the
survey, 80% of them are still on VB6, or roughly 800,000 serious developers.
Maybe half of them would pay for and make use of a decent upgrading tool if
one was available. That means there is a market of about 400,000. So, to get
a total return of 3,000,000, Microsoft needs a sales margin per user of
$7.50. I think that is achievable. And in doing so, they would increase the
adoption of modern platforms among the developers and their customers.
Win-win.


--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org

 

[Cor Ligthert]

Jonathan,

Already, nearly 4000 people have signed the petition.

So accoording too your message have 0.007% of the users signed it

Than is that not really much in my opinion.

When it is that important that they want to pay for it, it would have been
probably much more.

Just my thought,

Cor

 

[Herfried K. Wagner [MVP]]

Cor,

So accoording too your message have 0.007% of the users signed it

Than is that not really much in my opinion.

When it is that important that they want to pay for it, it would have been
probably much more.

Many VB6 developers are not aware of the petition. They do their work 10
hours the day, go home, eat something, watch a football match on TV, and
then go to bed. In other words, they are not active in communities and thus
have not yet heard about the petition. In addition to that, there are very
few VB6-oriented magazines available in the meantime, so VB6 developers are
"disconnected" from each other.

 

[Cor Ligthert]

Herfried,

Many VB6 developers are not aware of the petition. They do their work 10
hours the day, go home, eat something, watch a football match on TV, and
then go to bed. In other words, they are not active in communities and
thus have not yet heard about the petition. In addition to that, there
are very few VB6-oriented magazines available in the meantime, so VB6
developers are "disconnected" from each other.

I know your point of view, however as most developers I like it when
somebody shows "facts" to debate that with other "facts".

From the more than probably 12000 messages we did in this newsgroup together
in the last 12 months you should know that I in my idea.



Cor

 

[Mitchell S. Honnert]

While I would certainly agree that there are more people out there that want
a VB.COM-like tool than have signed the petition, I still hold to the idea
that it wouldn't be enough to make it an economically worthwhile proposition
to Microsoft. We can quibble about our cost and profit estimates, but
regardless of what the actual total costs are, it's going to be more than
$0, which is what Microsoft will currently have to spend to get achieve its
target market share for VB.NET without doing *any* more development of VB6.

I know I mentioned this before, but besides the economic issues there is the
issue of the human nature of the average Microsoft employed developer. Any
programmer assigned to the VB.COM project at Microsoft would view this as a
punishment. "What did I do to deserve this? God, why me?"

For so many reasons, VB.COM is just not going to happen.

- Mitchell S. Honnert

 

[Jim Hubbard]

While I would certainly agree that there are more people out there that
want a VB.COM-like tool than have signed the petition, I still hold to the
idea that it wouldn't be enough to make it an economically worthwhile
proposition to Microsoft. We can quibble about our cost and profit
estimates, but regardless of what the actual total costs are, it's going
to be more than $0, which is what Microsoft will currently have to spend
to get achieve its target market share for VB.NET without doing *any* more
development of VB6.

I know I mentioned this before, but besides the economic issues there is
the issue of the human nature of the average Microsoft employed developer.
Any programmer assigned to the VB.COM project at Microsoft would view this
as a punishment. "What did I do to deserve this? God, why me?"

For so many reasons, VB.COM is just not going to happen.

- Mitchell S. Honnert

Why don't we do a little experiment?

Why don't we put together an email that you can send to classic VB
developers that you know that tells them about the petition, where to sign
up and asks them to forward the email to friends of theirs who are classic
VB programmers?

This is surely the most efficient method of getting the word out, and should
give us (within a month) a real idea of how many classic VB developers want
a better migration tool and extended support for classic VB.

It should be relatively short and simple. I'll post a suggested message in
a little while.......

Jim Hubbard

 

[Mitchell S. Honnert]

I don't know anyone who still programs in VB6 and even if I did, I certainly
wouldn't want to do anything that would encourage them to sign the VB.COM
petition. I personally think that the petition is a bad idea. And even if
I thought it was a good thing, I don't see Microsoft following the
recommendation.

- Mitchell S. Honnert

 

[Jim Hubbard]

I don't know anyone who still programs in VB6 and even if I did, I
certainly wouldn't want to do anything that would encourage them to sign
the VB.COM petition. I personally think that the petition is a bad idea.
And even if I thought it was a good thing, I don't see Microsoft following
the recommendation.

- Mitchell S. Honnert

Whether Microsoft backs down or not, I think it would be good for us and
Microsoft to get as good a count of the classic VB users that are
disappointed in .Net. Then we'd know if we are just a vocal few or if
Microsoft really pissed off millions of VB users.

Maybe Microsoft would at least put more effort into a methodology that would
allow VB6 programs to be upgraded to VB.Net.

Microsoft is (much to their credit) already realizing that they screwed up
the whole RAD feel of VB in VB.Net and are trying to bring some of that back
with VB.Net 2005.

I've got the beta of VB.Net 2005, and I like it MUCH more than VB.Net 2003.

As much as it may seem like I am anti-Microsoft, I most certainly am not.
Microsoft has done more right than it has wrong. It charges too much for
its software and listens to its own developers over its customer base - but
those things can be fixed.

I am very vocal about screw ups - but, isn't that what we're supposed to
do - squeal when we need grease?

I know that (as a business owner myself) I love my customers that point out
where we can be better or where we have changed something that they loved
the way it was...they keep me in line with our customers' needs and wishes.
But, I don't make them scream about it - I actually have a menu item for a
customer to submit a help ticket or to simply submit a "Wish List" of things
they want added to the application.

I am not anti-.Net. I just want the RAD development environment that we
enjoyed with classic VB back and I want to be able to port my old VB
programs more easily so that I can take advantage of the new features
available in the .Net framework. Is that too much to ask?

I am impressed with the improvements in Vb.Net 2005. I can't wait to try
out the full version.

Jim Hubbard

 

[Mitchell S. Honnert]

Whether Microsoft backs down or not, I think it would be good for us and

Microsoft to get as good a count of the classic VB users that are
disappointed in .Net.

Well, I guess we still disagree. I think the effort is fruitless.
Microsoft isn't going to go out of its way to find out there is a demand to
do something it doesn't want to do nor thinks would be a bad idea.

Microsoft is (much to their credit) already realizing that they screwed up
the whole RAD feel of VB in VB.Net

Jim, I'll fully admit that this may be a matter of perspective, but I
personally couldn't disagree with you more that Microsoft "screwed up"
anything. I think the exact opposite, in fact. I have some pet peeves with
VB.NET, sure, but on the whole I think they did an incredible job at
improving Visual Basic, including RAD.

and are trying to bring some of that back with VB.Net 2005.

I'd like to get your impressions of VB.NET 05, specifically what features of
VB6 that VB.NET 05 is "bringing back". I tried Beta 1 of VB.NET 05 on my
machine for a bit and while I too was quite impressed with the improvements,
I didn't recognize them as being features of VB6 that didn't make it into
VB.NET. Can you give an example of such a feature? (I'm not denying they
are they; I just didn't notice any.)

- Mitchell S. Honnert

 

[Herfried K. Wagner [MVP]]

I know I mentioned this before, but besides the economic issues there is
the issue of the human nature of the average Microsoft employed developer.
Any programmer assigned to the VB.COM project at Microsoft would view this
as a punishment. "What did I do to deserve this? God, why me?"

Do you think that developers working on Win32/COM code in Windows and most
other Microsoft products see their work the same way?!

 

[Herfried K. Wagner [MVP]]

Jim,

I don't know anyone who still programs in VB6 and even if I did, I
certainly wouldn't want to do anything that would encourage them to sign
the VB.COM petition. I personally think that the petition is a bad idea.
And even if I thought it was a good thing, I don't see Microsoft following
the recommendation.
[...]

Whether Microsoft backs down or not, I think it would be good for us and
Microsoft to get as good a count of the classic VB users that are
disappointed in .Net. Then we'd know if we are just a vocal few or if
Microsoft really pissed off millions of VB users.

I agree that there are lots of customers who fell really pissed off by what
Microsoft did with VB6, but I doubt that most of them are disappointed by
..NET. .NET has its right to exist, but so does Classic VB.

I know that (as a business owner myself) I love my customers that point
out where we can be better or where we have changed something that they
loved the way it was...they keep me in line with our customers' needs and
wishes. But, I don't make them scream about it - I actually have a menu
item for a customer to submit a help ticket or to simply submit a "Wish
List" of things they want added to the application.

The FAQ to the petition lists the reason why the MVPs who initiated the
petition did this step into the public instead of talking to Microsoft about
this issue again.

I am not anti-.Net. I just want the RAD development environment that we
enjoyed with classic VB back and I want to be able to port my old VB
programs more easily so that I can take advantage of the new features
available in the .Net framework. Is that too much to ask?

No, that's not too much. I think it's a customer's right to give the
manufacturer feedback about products and product lifecycles.

I am impressed with the improvements in Vb.Net 2005. I can't wait to try
out the full version.

Full ACK. But this doesn't solve the VB6 issue.

 

[Herfried K. Wagner [MVP]]

Well, I guess we still disagree. I think the effort is fruitless.
Microsoft isn't going to go out of its way to find out there is a demand
to do something it doesn't want to do nor thinks would be a bad idea.

Jim, I'll fully admit that this may be a matter of perspective, but I
personally couldn't disagree with you more that Microsoft "screwed up"
anything. I think the exact opposite, in fact. I have some pet peeves
with VB.NET, sure, but on the whole I think they did an incredible job at
improving Visual Basic, including RAD.

Microsoft didn't improve Visual Basic, it created a /new/ programming
language (language stability is broken). That's what the whole discussions
about VB6/VB.NET are about.

 

[Jim Hubbard]

Well, I guess we still disagree. I think the effort is fruitless.
Microsoft isn't going to go out of its way to find out there is a demand
to do something it doesn't want to do nor thinks would be a bad idea.

Then don't pass it along. I think we can manage.

Jim, I'll fully admit that this may be a matter of perspective, but I
personally couldn't disagree with you more that Microsoft "screwed up"
anything. I think the exact opposite, in fact. I have some pet peeves
with VB.NET, sure, but on the whole I think they did an incredible job at
improving Visual Basic, including RAD.

It seems that Microsoft noticed the problem, along with us classic VB users.
"...Somasegar gave details of some of the company's efforts to keep existing
customers of older versions of VB6 in the Microsoft fold. With Visual Studio
2005, which is code-named Whidbey, developers will be able to use prewritten
components, called controls, that worked with VB6, he said.

"To be fair, we did lose a little bit of the VB experience when made
transition from VB6 to VB.Net," Somasegar said. "Whidbey Visual Basic is
going to provide the best RAD (rapid application development) experience
that they have ever seen."

I'd like to get your impressions of VB.NET 05, specifically what features
of VB6 that VB.NET 05 is "bringing back". I tried Beta 1 of VB.NET 05 on
my machine for a bit and while I too was quite impressed with the
improvements, I didn't recognize them as being features of VB6 that didn't
make it into VB.NET. Can you give an example of such a feature? (I'm not
denying they are they; I just didn't notice any.)

It's the RAD experience that was missing. VB was originally meant to be a
RAD tool....not a challenger to C/C++. In keeping it a RAD tool Microsoft
could cover the professional developers with C/C++ and everyone else with
Visual Baisc. By trying to make VB as powerful as C#, they are screwing up
their lineup.

But, back to your question........In VB.Net 2005, you can turn off seeing or
stepping through code that you did not write. Speaking as a clsssic VB
programmer.... Who really wants to see that code anyway? I never had to
step through forms or control code before. For less experienced
programmers, it is simply confusing. For more experienced cVB programmers,
extra code is simply an aggravation - one more thing I have to contend with
that I don't need.

EDIT AND CONTINUE! For the love of God.....why did this ever leave?

A simplified IDE. Why? Because the goals of most Visual Basic programmers
are simply to solve business or personal problems in the most efficient
manner possible. Their goals do NOT usually include becoming a programming
guru (although that frequently happens as a side effect of writing so many
applications with a RAD tool).

Just these 3 things get us closer to the RAD feel we enjoyed with classic
VB. I think that I speak for most classic VB programmers when I say that I
don;t give a rat's * if the language uses a runtime or framework. I want to
solve my business problems and make my life easier ASAP. That requires a
RAD-centered design.....not pushing me to become a .Net framework expert.

I haven't played with it as much as I need to.....but I like what I see so
far. I will let you know more as I continue to test (when I have the time
to).

Jim Hubbard

 

[Jim Hubbard]

Jim,

I don't know anyone who still programs in VB6 and even if I did, I
certainly wouldn't want to do anything that would encourage them to sign
the VB.COM petition. I personally think that the petition is a bad idea.
And even if I thought it was a good thing, I don't see Microsoft
following the recommendation.
[...]

Whether Microsoft backs down or not, I think it would be good for us and
Microsoft to get as good a count of the classic VB users that are
disappointed in .Net. Then we'd know if we are just a vocal few or if
Microsoft really pissed off millions of VB users.

I agree that there are lots of customers who fell really pissed off by
what Microsoft did with VB6, but I doubt that most of them are
disappointed by .NET. .NET has its right to exist, but so does Classic
VB.

I agree. I should've been more clear in my response. The dissappointments
in .Net that I see are 3-fold.

1) .Net is not backwards compatible with my VB6 programs and offers no real
migration tool. At best, the migration tool supplied simply tells you why
(anything but a VERY simple application ) will not run in VB.Net. In larger
applications, a complete re-write takes less time than upgrading.

2) The RAD feel/ability to develop applications is gone. Edit and continue
was great - and should be back in VB.Net 2005. Make it simple! Our jobs
are already hard enough. We want a tool that helps us make making a living
easier - not a tool that demands we become a .Net framework expert to create
a simple IM application.

3) The .Net framework distribution. Do we really have to lug this beast
everywhere we distribute applications? Thinstall can wrap all needed .Net
framework components into a single exe with no external dependencies - sure
it lareger, but it will never be missing a component or get broken because a
component or portion of .Net was upgraded. You'd have to make fundamental
changes to the OS to screw Thinstall apps up. (Not that that couldn't
happen, but it is more unlikely than a change to the .Net framework.)

The FAQ to the petition lists the reason why the MVPs who initiated the
petition did this step into the public instead of talking to Microsoft
about this issue again.

It should also be the core of the letter I suggested.

No, that's not too much. I think it's a customer's right to give the
manufacturer feedback about products and product lifecycles.


Full ACK. But this doesn't solve the VB6 issue.

True.

Neither does it answer the question of why Microsoft have spent more time
and energy keeping C/C++ backwards compatibility than it has done with
Visual Basic 6.

Microsoft themselves acknowledged Visual Basic as the world's most popular
programming language. They even realized that the majority of the
programmers in the world (Visual Basic programmers) were "task-oriented
developers" whereas C++ developers are "power-oriented".

Taken from
http://msdn.microsoft.com/vstudio/productinfo/whitepapers/default.aspx .....

---------
For its part, Microsoft offers four programming languages and associated
development environments, each designed to appeal to a particular school of
programmer:

a.. Visual Basic .NET, the latest version of the world's most popular
development tool and language. Visual Basic .NET delivers unsurpassed
productivity and unique language features for task-oriented developers
building solutions with the .NET Framework.


b.. Visual C++ .NET, the tool of maximum power and control. With the C++
language, power-oriented developers can bridge platform technologies and
build both native Windows-based and .NET-connected solutions with maximum
performance characteristics and enhanced functionality.


c.. Visual C# .NET, the modern and innovative programming language and
tool. Introduced in 2001, C# offers a familiar syntax, that is attractive to
C++ and Java developers, along with unique language constructs that offer
code-focused developers a more elegant experience when developing
applications for the .NET Framework.
-------


......it continues.....

-------
Visual Basic .NET
http://msdn.microsoft.com/vbasic

Visual Basic 1.0 revolutionized Windows development by lowering the barrier
to entry and making a broad audience of developers more productive than
ever. Building on this rich history, Visual Basic .NET offers task-oriented
programmers a human readable syntax, an intuitive user interface, and tools
and upgrade wizards that speed the development of Microsoft .NET-connected
applications. Visual Basic .NET takes advantage of the ease of development
espoused by its exceedingly popular predecessors, while adding new
capabilities that enable all manner of programmers, from the beginner to the
experienced corporate developer, to build applications for Windows, the Web,
and mobile devices.

Task-Oriented Development
Deadlines are nothing new to the software industry. For a large group of
programmers, deadlines are a daily fact of life. These programmers are often
charged with building opportunistic applications that address a specific
business need and require a modicum of planning and a fast track to
deployment. Sometimes such solutions will be tested rigorously, while other
times the application will be built and immediately deployed, freeing the
programmer for the next assignment. These task-oriented developers are
focused on delivering solutions quickly. Task-oriented development tools,
therefore, must place such a premium on productivity that it is acceptable
to abstract programmers from the nuances of the underlying platform and
empower them to conceive of an application, build it from scratch, and
quickly disseminate it across a business group.

Programmer Constituency
Visual Basic .NET is ideal for the following types of programmers who are
looking to use the .NET Framework to construct the next generation of
applications and services:

a.. Programmers looking for a fast and productive development tool for the
..NET Framework. Visual Basic .NET offers an easy-to-understand syntax and an
intuitive development environment to help programmers construct applications
quickly. Further, with a large and established community of programmers,
Visual Basic .NET programmers have a wealth of resources at their disposal
to help them get up to speed with Microsoft .NET.


b.. Programmers with existing Visual Basic skills or code assets. Visual
Basic .NET builds on the keywords, syntax, and nuances of the Visual Basic
language. Its case-insensitivity will be immediately familiar to traditional
Visual Basic developers, as will the human-readable syntax. Programmers with
a significant code investment in earlier versions of Visual Basic can move
their code forward using the built-in upgrade technology. Additionally, most
existing ActiveX® controls can continue to be used with Visual Basic .NET.


c.. Developers looking for familiar design-time and code editor paradigms.
Many of the principles of designing applications and writing code are
carried forward from the Visual Basic .NET predecessors, including
drag-and-drop design of applications, IntelliSense® for assistance in
writing code, and automatic code formatting for easier readability.


d.. Programmers looking to build applications with a more intuitive and
accessible language. Visual Basic .NET is designed to be accessible to a
full range of developers, from beginners to experts. Beginners will find
many unique features of the Visual Basic language as useful as the key
productivity enhancements of the Visual Basic environment.
Unique Language Features
Visual Basic .NET contains several unique language features that lend it an
aspect of productivity not found in the other Microsoft-supplied .NET
languages, including:

a.. Default variable initialization. Visual Basic .NET does not require
variables and members to be initialized prior to use, so beginning
programmers may not be frustrated by seemingly arcane use requirements as
found in other .NET languages.


b.. Implicit typing and late binding. Visual Basic .NET code need not
specify the type of a variable before it is used, helping programmers write
useful code with a minimum of training.


c.. Enumeration behavior. Visual Basic .NET offers more intuitive behavior
when using enumerated types.


d.. Default public access. By default, members of a Visual Basic .NET
class are declared to be public, which offers programmers a more intuitive
syntax.


e.. Use of shared members. Shared members may be accessed in Visual Basic
..NET through both the class name and an instance variable of the type to
which they belong, helping programmers write intuitive code. For example:
Dim x as new MyClassx.SharedMethod() ' works just as well as...

MyClass.SharedMethod()a.. Optional parameters. Visual Basic .NET supports
optional parameters, affording class designers more flexibility in designing
their libraries and giving programmers the ability to write useful code
without having to learn all the nuances of object-oriented programming.


b.. Filtered catch blocks. Visual Basic .NET offers flexible structured
exception handling errors. Filtered catch blocks enable developers to filter
errors based on the class of the exception, any conditional expression, or
an explicit error number.


c.. Parameterized properties. Properties in Visual Basic .NET may contain
parameters, making them more flexible than their C# counterparts.


d.. Declarative event handlers. Visual Basic .NET event handlers may
declare the events to which they are subscribed using the Handles keyword.


e.. Interface member redeclaration. Visual Basic .NET enables programmers
to rename a member of an interface when it is implemented in a class.
Unique Environment Features
Visual Basic .NET also includes a number of key environment enhancements
that enable programmers to more productively design and write compelling
applications and services. These enhancements are above and beyond the
Visual Studio® .NET features shared among all .NET languages:

a.. Background compilation. Background compilation works behind the
scenes, silently compiling your code while you are working. Visual Basic
..NET developers should be able to know immediately if they have errors in
their code.


b.. Pretty listing. The Visual Basic .NET code editor can (optionally)
automatically format your code as you type, saving you time. Pretty listing
can automatically align your code to the correct tab position, recase
keywords and variables, add a missing then to an if statement, and more.
Performance
A final area of great importance is performance. The Visual Basic .NET
compiler generates Intermediate Language (IL) code that is equal in
performance to the code generated by the C# compiler.

-------

So, what happened? It sounded like they knew what was needed, but VB.Net
(up to 2003) is a miserable failure at delivering on the requirements
Microsoft mentioned above. The only thing they needed to think about each
day, before they started work on VB.Net is "My users are task-oriented
developers." Maybe they should have a morning yoga session in which this is
their mantra.

Whatever it takes.....so far, thorough VS.Net 2003, VB.Net has definitely
NOT lived up to the "task oriented" language that was classic VB. I hope
that VB.Net will get us closer to that RAD environment that made classic VB
the #1 used development language in the world.

But, I think that Microsoft has severely screwed their chance of having such
a large following in the future. It's a matter of trust, and Microsoft has
trampled on that trust with no regard for the consequences to it's customer
base. At the same time, they went out of their way to incorporate VB-like
features and backwards compatibility into the C++, C and C# .Net
implementations.

Why not do the same for VB? There has still been no legitimate answer to
that question from Microsoft because there is no legitimate answer.

Plainly put. They spit in our faces.

I think Microsoft began listening to powerVB programmers and not so much to
the everyday (millions of them) VB programmers. Perhaps more feedback from
everyday programmers and less from (no offense intended) professional
developers, who make up the minority of classic Visual Basic programmers.

Jim Hubbard

 

[Mitchell S. Honnert]

Microsoft didn't improve Visual Basic, it created a /new/ programming

language (language stability is broken). That's what the whole
discussions about VB6/VB.NET are about.

Well, I suppose we could get into a detailed discussion about what the word
"improve" really means, but I think it can be reasonably applied to VB.NET.
"Visual Basic", as distinguished from its implementations in BASIC,
QuickBasic, VB6, or even VB.NET itself, can be defined in terms of a basic
set of keywords or syntax style. Separating out "Visual Basic" at this
level, VB.NET certainly can be seen as an improvement over VB6. I don't see
the term "improvement" being at all dependent on principles like language
stability or even easily portable code. Today's cars are vastly superior to
the Model T and other cars of that general era. There were evolutionary and
revolutionary changes along the way. But they're all cars.

- Mitchell S. Honnert