M
Mitchell S. Honnert
[I apologize for the length of this post. It started out as being a summary
of some of my other posts about the petition, but grew into something
larger. Also, this post is not meant to be flamebait. I have an honest
disagreement of opinion in regards to the petition and I felt this was an
appropriate forum to have a reasoned discussion about the issue.
- Mitchell S. Honnert]
In my opinion, people should not sign the the "VB.COM" petition at
http://classicvb.org/petition/, at least not in its current form. The
objectives
listed in the petition are either already being met by the current version
of
VB6 or, when they are valid, could be much more easily resolved with a
far less dramatic solution than the one proposed.
First, let's go through the objectives listed in the petition...
"1. Preservation of assets
Future versions of VB6/VBA should:
Use existing VB6/VBA projects without extensive conversion;
Support the core VB6/VBA Visual Basic language and syntax;
Compile existing projects and produce identical results."
The *current* version of VB6 meets these criteria, so what's the
justification for a "future version"?
"2. Continued support for the Visual Basic language
Microsoft should demonstrate a commitment to the core Visual Basic
language. This core should be enhanced and extended, and changes
should follow a documented deprecation process."
be that MS is committed to the "core Visual Basic language." Microsoft
could have let the Visual Basic language flounder in the form of VB6, but it
instead chose to take the language to the next level. Now *that's*
commitment. Surely the petition authors aren't so arrogant as to view
VB6 as the sole representative of the "core Visual Basic language".
extending of VB6. All "extending" and "enhancing" will be to
VB.NET. Simple.
"3. Ease of migration of unmanaged VB/VBA code to VB.NET
The decisions of if, how, and when to migrate code to .NET should lie
with the customer. Some may choose to remain with unmanaged VB,
especially for legacy code bases. Some will use only VB.NET, others
a mix. A future version of VB6/VBA should treat all these options as
valid, while making it easy to move among them."
Microsoft's suggested upgrade path (a combination of COM interop and
code conversion) is not sufficient given the number of existing VB6 systems,
but to suggest that there is no choice at all is an outright falsehood. If
what the petitioners mean is that they want *more* choice, better
solutions from Microsoft, or more support, why don't they just
say this instead of implying there is *no* choice? This kind of hyperbole
is as needless as it is ineffective. It may be a *difficult* choice for a
company to stay with its existing VB6/Win98 solution or to convert and
upgrade to a VB.NET/WinXP solution, but it *is* a choice.
consider the economic decision that companies currently make to stick with
VB6 or move to VB.NET as "valid". If the petitioners believe that COM
interop doesn't work as well as it should or that the code upgrade
wizard does not work as well as it should or that an upgrade which breaks
language stability deserves a longer support period, why don't they just say
so instead of leaping ahead to the conclusion that a "future version" of
VB6 is warranted?
This text appeared before the objectives...
I took this to mean that the petitioners believed some enhancements to VB6
were required to solve the problems that would be detailed in the
Objectives. But what I instead found was a list of objectives that was
short on problems and heavy on solution. Instead of using the Objectives
section to describe the problems that would be overcome by the proposed
solution mentioned later in the petition, the objectives are instead a
description of what the petitioners want in the solution.
Perhaps, to the petition authors, the problems that justify a future version
of VB6 are so self-evident that they aren't worth mentioning explicitly in
the petition itself, but it's not so obvious to me. Instead of the
Objectives section being a foreshadowed specifications list for the
proposed solution, why didn't they actually say what they find deficient
with the current situation? As far as I could tell, none of the objectives
detailed any current problem, so how could they justify any kind of
solution?
Now, let's move onto the suggested solution to the aforementioned
"problems", the creation of "VB.COM".
"SUGGESTED APPROACH
We believe the best way to meet these objectives is for Microsoft to
include an updated version of VB6 inside the Visual Studio IDE. For
brevity we'll call this update "VB.COM".
VB.COM should use the same keywords, syntax and types as VB6, remain
COM-based, and compile to native code. Visual Studio would then support
both unmanaged VB.COM and managed VB.NET, as it now supports both
[unmanaged] C++ and [managed] C#.
With both VBs in the same IDE, it should be possible to extend the
development environment to provide a high degree of interoperation
between them. That will allow the developer to use both in the same
solution, with the interop handled seamlessly by the framework."
From this description, it appears as if the main point of VB.COM would be to
give VB6 developers the benefits of the VS.NET IDE, yet not change the
underlying VB6 language. There is no mention made of functional
deficiencies, so the assumption is that the petitioners want VB6 developers
to have the ease-of-use benefits of using the VS.NET IDE, such as
eliminating the need to ALT-TAB between the VB6 IDE and the VS.NET IDE,
better Intelisense, and auto code indenting.
Is this petition really about IDE enhancements? Is the touchy-feely goal of
"reaching out" to the VB6 developer by gently introducing them to the VS.NET
IDE seen as justifying the huge effort it would take to create VB.COM? If
not...if there are actual functional deficiencies in Microsoft's migration
path (COM interop and code conversion), why don't the petitioners just say
this instead of suggesting a solution that, by all indications in the
petition, is focused on the comparatively small IDE issues? I'm sorry, but
MS doesn't owe VB6 developers the IDE enhancement that come with
VS.NET even if they did do it for C++ and no matter how many people are
currently using VB6.
In my personal opinion (and that's all this post is, after all), I think
that the issues that are alluded to in the petition (but never directly
stated) could be addressed much more appropriately by improving on
Microsoft's current "upgrade path". So, instead of undertaking the
monumental task of integrating VB6 into the VS.NET IDE, Microsoft
could improve on COM interop and, probably more importantly, provide
a better code upgrade wizard. And to give the large number of VB6
users some extra breathing room required from the revolutionary change
from VB6 to VB.NET, Microsoft could extend its mainstream support
period, including the release of bug fixes. But because the perceived
problems are commingled in the petition with the proposed solution of
VB.COM, the reader is guided away from these otherwise obvious
alternative -- and in my opinion far more reasonable -- solutions.
I fully acknowledge that I may be focusing too much on the language of the
petition, rather than the underlying issues. But one of the things that
bothers me so much about the petition is how it treats the need for VB.COM
as a foregone conclusion. From previous threads on this newsgroup and from
the petition's FAQ, I got a sense of the issues the prompted the petition,
but this information wasn't obvious from reading the petition itself. It
would seem to me that the authors of the petition would have served their
purpose much better by being more explicit on *why* they believed that
Microsoft should create VB.COM rather than focusing so much on describing
*what* they want VB.COM to be.
Opponents of the petition have been accused of ignoring the huge number
of companies who still have active VB6 applications. For me, I would
say that I'm not ignoring them, just that I believe there is a solution that
is much more in proportion to the problems. In other words, it's not that
I disagree that there is a problem. (I personally think that Microsoft
should have supplied a much better automatic code conversion tool.) It's
just that I believe the creation of VB.COM would be overkill.
Maybe all the petitioners really want with VB.COM is a better IDE, but from
the language used in the petition and in related posts, it sure sound like a
whole lot more. All the talk of "extending" and "enhancing" gives me the
impression that the authors and signers don't just want VB6 to simply reside
in the .NET IDE, but that they want major new functionality added to VB6.
This is at the heart of my personal disagreement with the petition. I
personally don't feel that it is Microsoft's responsibility to supply the
features of the current generation of an application to the users of the
previous generation. If the problem is that the migration from one
generation to another is too difficult, then the solution should be to make
that migration easier, not to make that previous generation application
*into* the next generation application.
So, why is there such a discrepancy between the problems and the solution?
Are the petitioners using the standard bargaining technique of asking for
way more than you know you'll get, in the hopes that you'll get what you
really wanted in the first place? I don't think so. Here's my theory. I
have noticed that the most vocal proponents of VB.COM just so happen to
hold the opinion that Microsoft made a huge mistake by making VB.NET in
the first place. They either believe the advances in VB.NET were not worth
the cost in the break of language stability or that the advances could have
come without breaking language stability. In other words, they wanted MS
to create Visual Basic 7 instead of VB.NET.
Is this juxtaposition of attitudes a coincidence? Or could it be that the
reason that the petition's proposed solution is such overkill is because the
*unstated* problem is the existence of VB.NET itself and not the migration
path to VB.NET? I'm sure I'll get feedback to the contrary, but this is the
only logical explanation that I can see as to why the petition's proposal
goes so far beyond what would be necessary to resolve the implied migration
and support issues.
- Mitchell S. Honnert
of some of my other posts about the petition, but grew into something
larger. Also, this post is not meant to be flamebait. I have an honest
disagreement of opinion in regards to the petition and I felt this was an
appropriate forum to have a reasoned discussion about the issue.
- Mitchell S. Honnert]
In my opinion, people should not sign the the "VB.COM" petition at
http://classicvb.org/petition/, at least not in its current form. The
objectives
listed in the petition are either already being met by the current version
of
VB6 or, when they are valid, could be much more easily resolved with a
far less dramatic solution than the one proposed.
First, let's go through the objectives listed in the petition...
"1. Preservation of assets
Future versions of VB6/VBA should:
Use existing VB6/VBA projects without extensive conversion;
Support the core VB6/VBA Visual Basic language and syntax;
Compile existing projects and produce identical results."
The *current* version of VB6 meets these criteria, so what's the
justification for a "future version"?
"2. Continued support for the Visual Basic language
Microsoft should demonstrate a commitment to the core Visual Basic
language. This core should be enhanced and extended, and changes
should follow a documented deprecation process."
I view the creation of Visual Basic .NET as the best evidence there couldMicrosoft should demonstrate a commitment to the core Visual Basic
language. This core should be enhanced and extended
be that MS is committed to the "core Visual Basic language." Microsoft
could have let the Visual Basic language flounder in the form of VB6, but it
instead chose to take the language to the next level. Now *that's*
commitment. Surely the petition authors aren't so arrogant as to view
VB6 as the sole representative of the "core Visual Basic language".
The deprecation process is that there will be no new enhancement orand changes should follow a documented deprecation process.
extending of VB6. All "extending" and "enhancing" will be to
VB.NET. Simple.
"3. Ease of migration of unmanaged VB/VBA code to VB.NET
The decisions of if, how, and when to migrate code to .NET should lie
with the customer. Some may choose to remain with unmanaged VB,
especially for legacy code bases. Some will use only VB.NET, others
a mix. A future version of VB6/VBA should treat all these options as
valid, while making it easy to move among them."
It already *is* the decision of the customer. One can argue thatThe decisions of if, how, and when to migrate code to .NET should lie with
the customer.
Microsoft's suggested upgrade path (a combination of COM interop and
code conversion) is not sufficient given the number of existing VB6 systems,
but to suggest that there is no choice at all is an outright falsehood. If
what the petitioners mean is that they want *more* choice, better
solutions from Microsoft, or more support, why don't they just
say this instead of implying there is *no* choice? This kind of hyperbole
is as needless as it is ineffective. It may be a *difficult* choice for a
company to stay with its existing VB6/Win98 solution or to convert and
upgrade to a VB.NET/WinXP solution, but it *is* a choice.
This sounds like a pretty good description of what we have now. I wouldSome may choose to remain with unmanaged VB,
especially for legacy code bases. Some will use only VB.NET, others
a mix. A future version of VB6/VBA should treat all these options as
valid, while making it easy to move among them.
consider the economic decision that companies currently make to stick with
VB6 or move to VB.NET as "valid". If the petitioners believe that COM
interop doesn't work as well as it should or that the code upgrade
wizard does not work as well as it should or that an upgrade which breaks
language stability deserves a longer support period, why don't they just say
so instead of leaping ahead to the conclusion that a "future version" of
VB6 is warranted?
This text appeared before the objectives...
We ask that Microsoft further develop VB6 and VBA, in order to meet these
objectives (in order of perceived importance):
I took this to mean that the petitioners believed some enhancements to VB6
were required to solve the problems that would be detailed in the
Objectives. But what I instead found was a list of objectives that was
short on problems and heavy on solution. Instead of using the Objectives
section to describe the problems that would be overcome by the proposed
solution mentioned later in the petition, the objectives are instead a
description of what the petitioners want in the solution.
Perhaps, to the petition authors, the problems that justify a future version
of VB6 are so self-evident that they aren't worth mentioning explicitly in
the petition itself, but it's not so obvious to me. Instead of the
Objectives section being a foreshadowed specifications list for the
proposed solution, why didn't they actually say what they find deficient
with the current situation? As far as I could tell, none of the objectives
detailed any current problem, so how could they justify any kind of
solution?
Now, let's move onto the suggested solution to the aforementioned
"problems", the creation of "VB.COM".
"SUGGESTED APPROACH
We believe the best way to meet these objectives is for Microsoft to
include an updated version of VB6 inside the Visual Studio IDE. For
brevity we'll call this update "VB.COM".
VB.COM should use the same keywords, syntax and types as VB6, remain
COM-based, and compile to native code. Visual Studio would then support
both unmanaged VB.COM and managed VB.NET, as it now supports both
[unmanaged] C++ and [managed] C#.
With both VBs in the same IDE, it should be possible to extend the
development environment to provide a high degree of interoperation
between them. That will allow the developer to use both in the same
solution, with the interop handled seamlessly by the framework."
From this description, it appears as if the main point of VB.COM would be to
give VB6 developers the benefits of the VS.NET IDE, yet not change the
underlying VB6 language. There is no mention made of functional
deficiencies, so the assumption is that the petitioners want VB6 developers
to have the ease-of-use benefits of using the VS.NET IDE, such as
eliminating the need to ALT-TAB between the VB6 IDE and the VS.NET IDE,
better Intelisense, and auto code indenting.
Is this petition really about IDE enhancements? Is the touchy-feely goal of
"reaching out" to the VB6 developer by gently introducing them to the VS.NET
IDE seen as justifying the huge effort it would take to create VB.COM? If
not...if there are actual functional deficiencies in Microsoft's migration
path (COM interop and code conversion), why don't the petitioners just say
this instead of suggesting a solution that, by all indications in the
petition, is focused on the comparatively small IDE issues? I'm sorry, but
MS doesn't owe VB6 developers the IDE enhancement that come with
VS.NET even if they did do it for C++ and no matter how many people are
currently using VB6.
In my personal opinion (and that's all this post is, after all), I think
that the issues that are alluded to in the petition (but never directly
stated) could be addressed much more appropriately by improving on
Microsoft's current "upgrade path". So, instead of undertaking the
monumental task of integrating VB6 into the VS.NET IDE, Microsoft
could improve on COM interop and, probably more importantly, provide
a better code upgrade wizard. And to give the large number of VB6
users some extra breathing room required from the revolutionary change
from VB6 to VB.NET, Microsoft could extend its mainstream support
period, including the release of bug fixes. But because the perceived
problems are commingled in the petition with the proposed solution of
VB.COM, the reader is guided away from these otherwise obvious
alternative -- and in my opinion far more reasonable -- solutions.
I fully acknowledge that I may be focusing too much on the language of the
petition, rather than the underlying issues. But one of the things that
bothers me so much about the petition is how it treats the need for VB.COM
as a foregone conclusion. From previous threads on this newsgroup and from
the petition's FAQ, I got a sense of the issues the prompted the petition,
but this information wasn't obvious from reading the petition itself. It
would seem to me that the authors of the petition would have served their
purpose much better by being more explicit on *why* they believed that
Microsoft should create VB.COM rather than focusing so much on describing
*what* they want VB.COM to be.
Opponents of the petition have been accused of ignoring the huge number
of companies who still have active VB6 applications. For me, I would
say that I'm not ignoring them, just that I believe there is a solution that
is much more in proportion to the problems. In other words, it's not that
I disagree that there is a problem. (I personally think that Microsoft
should have supplied a much better automatic code conversion tool.) It's
just that I believe the creation of VB.COM would be overkill.
Maybe all the petitioners really want with VB.COM is a better IDE, but from
the language used in the petition and in related posts, it sure sound like a
whole lot more. All the talk of "extending" and "enhancing" gives me the
impression that the authors and signers don't just want VB6 to simply reside
in the .NET IDE, but that they want major new functionality added to VB6.
This is at the heart of my personal disagreement with the petition. I
personally don't feel that it is Microsoft's responsibility to supply the
features of the current generation of an application to the users of the
previous generation. If the problem is that the migration from one
generation to another is too difficult, then the solution should be to make
that migration easier, not to make that previous generation application
*into* the next generation application.
So, why is there such a discrepancy between the problems and the solution?
Are the petitioners using the standard bargaining technique of asking for
way more than you know you'll get, in the hopes that you'll get what you
really wanted in the first place? I don't think so. Here's my theory. I
have noticed that the most vocal proponents of VB.COM just so happen to
hold the opinion that Microsoft made a huge mistake by making VB.NET in
the first place. They either believe the advances in VB.NET were not worth
the cost in the break of language stability or that the advances could have
come without breaking language stability. In other words, they wanted MS
to create Visual Basic 7 instead of VB.NET.
Is this juxtaposition of attitudes a coincidence? Or could it be that the
reason that the petition's proposed solution is such overkill is because the
*unstated* problem is the existence of VB.NET itself and not the migration
path to VB.NET? I'm sure I'll get feedback to the contrary, but this is the
only logical explanation that I can see as to why the petition's proposal
goes so far beyond what would be necessary to resolve the implied migration
and support issues.
- Mitchell S. Honnert