Microsoft MVPs Say They Want Old VB Back

[Herfried K. Wagner [MVP]]

Mitchell,

so long. I was firmly in the camp of people who applauded Microsoft for
the revolutionary change from VB6 to VB.NET, even if it meant introducing
all of the compatibility issues between the two languages.

Just to make one thing clear: I think that VB.NET is a very powerful
programming language and I am happy that this programming language exists.
VB.NET and Classic VB are my favourite programming languages. I don't think
that the compatibility issues are really a problem as long as Microsoft
doesn't tell VB6 users that VB.NET is VB6's successor, which is definitely
not true. <URL:http://vb.mvps.org/tips/stability.asp> describes pretty well
what language stabilty means and why it is broken with the VB6 -> VB.NET
transition.

Since switching to VB.NET, I've been fortunate enough (for the most part)
not to work at clients or companies that required me to use VB6.

That's all your personal preference. Other people had and still have other
preferences.

I believe that one of your main points is that Microsoft is
not properly accounting for the high number of programmers who,
like you, have to maintain or enhance systems written in VB6. I can
sympathize with that situation, but can you see that, from the standpoint
of someone who doesn't have to use VB6 on a daily basis, a petition which
suggests that Microsoft should spend its resources on a major upgrade to
VB6 is overkill?

I can understand this point of view; however, I am expecting solidarity in
the whole developer community. There is no guarantee that the same incident
that happed for VB6 (a product used and requested by a large number of
customers is discontinued without providing a viable upgrade path) will
happen again for VB.NET in a few years. That's my fear and that's why I
think that it's important that people sign the petition. The higher the
number of signatories the more noticeable is the sign shown to Microsoft
that the approach taken for VB6 (and which will likely be taken for VB.NET
too) is not accepted by the customers.

I'm not familiar with the bugs you allude to in SP6, but I wouldn't
doubt that there still bugs in VB6 even after all this time.

On the one hand, SP6 introduces a few new bugs that didn't exist in previous
versions/SPs of Visual Basic. On the other hand, there are certain "bugs"
or non-compliant behavior when running VB6 applications on Windows XP and
other newer versions of Windows. There is the runtime update problem too,
which Bill McCarthy describes (I posted the link in one of the previous
posts).

No change as big as what would be required by VB.COM exists
in a vacuum. The costs would be very large.

What you are ignoring is that there is a large number of
companies/developers who would pay for the product and support included with
this product. Microsoft could easily make a survey to check how many
licenses of VS including VB.COM they could sell.

It just doesn't seem like the problems described warrant the suggested
remedy. Yes, Microsoft supports other languages in VS.NET and no, I
wouldn't want VB.NET to be eliminated to that MS could focus on C#, but
this doesn't avoid the simple fact that adding another language to VS.NET
would incur huge additional costs for Microsoft.

Well, the whole discussion is not about adding another J# that rarely
anybody uses. It's about adding a language which is strongly requested by a
large number of customers, a language that already existed and that was a
bestseller.

In my opinion, the natural reaction of the programmer who uses VB.NET
exclusively to a call for VB.COM is "Why waste the effort enhancing the
previous generation's development tool when we already have the next
generation tool?" Perhaps I am reading too much into the wording of the
petition, but when I see the terms "enhance" and "extend" featured so
prominently, I don't think of service packs and free support calls.

Nobody is requesting VB.COM to be available for free. I am confident that
many of the people who signed the petition would even buy a full VS license
if VS includes VB.COM. This would mean that Microsoft could sell some
millions of additional VS licenses.

What comes to mind for me is adding new features and capabilities to the
language. I think much of the negative feedback regarding the petition is
that it appears to be calling for a major upgrade to VB6, whereas most
people (especially those who no longer use VB6) would not think that
Microsoft is responsible in any way to enhance and extend such an old
product.

Surveys are showing that there are currently more people using Classic VB
than VB.NET. Wouldn't the logical impliciation be removing VB.NET and
enhancing and extending VB6? I don't like any of the two ways of
discontinuing either Classic VB or VB.NET. Both programming languages are
requested and used by a large number of constomers, so they should be kept
alive.

 

[Mitchell S. Honnert]

I don't think that the compatibility issues are really a problem as long

as Microsoft doesn't tell VB6 users that VB.NET is VB6's successor, which
is definitely not true. <URL:http://vb.mvps.org/tips/stability.asp>
describes pretty well what language stabilty means and why it is broken
with the VB6 -> VB.NET transition.

Well, "successor" is quite subjective. To me, it would be more accurate to
call VB.NET the successor to VB6 than the next "version" of Visual Basic.
"Successor" has the vague kind of meaning that could include the
next-in-line, even if it is a radical and revolutionary departure from its
predecessor. "Version" to me would imply language stability as described at
the link you provided. But that's all just terminology; what's important
are the underlying ideas.

Incidentally, I haven't run across any instances where Microsoft stated that
there was "language stability" between VB6 and VB.NET. Because of the beta
period for .NET and from all that I read at the time, I knew full well that
VB.NET was such a drastic change from VB6 that it was all but a new
language, albeit one with similar syntax and keywords. I get the impression
that you would have preferred that there was language stability between VB6
to VB.NET, but I don't ever recall this being Microsoft's position.

That's all your personal preference. Other people had and still have
other preferences.

Hmmm. Are you saying that you don't have a personal preference between
using VB.NET or VB6? Perhaps this warrants another thread, but I find it
inconceivable that an experienced programmer would actually choose, all
other things being equal, to use VB6 instead of VB.NET.

I can understand this point of view; however, I am expecting solidarity in
the whole developer community. There is no guarantee that the same
incident that happed for VB6 (a product used and requested by a large
number of customers is discontinued without providing a viable upgrade
path) will happen again for VB.NET in a few years. That's my fear and
that's why I think that it's important that people sign the petition.

You know, to be consistent with my opinion, I would say that if the
situation you describe happens, I would be OK with it. For example, let's
say that in a couple of years or so, Microsoft comes out with a
revolutionary new programming language that uses a BASIC-like syntax.
(Let's hope that if this happens, they'd come up with a better, less
confusion-causing name than .NET.) Who knows, perhaps there will be some
new style of programming that would require this kind of radical break from
the past. If I tried this new language out and thought its improvements
were worth the break in language stability, I'd switch over to it, make it
my personal language-of-choice, and seek out employers that used it. If I
didn't, I'd stick with VB.NET and hope for the best.

The point is that I think it is perfectly natural for programming languages
to go through a long phase of incremental change (which can support language
stability) followed by an instance of revolutionary change (which obviously
would not support language stability.) I think this is what happened with
VB6 and VB.NET and I personally think that it is inevitable that it will
happen to VB.NET. In my personal opinion, programming languages
periodically need to make changes that exist on such a fundamental level
that language stability cannot be maintained. The alternative is
stagnation. Perhaps not a complete stagnation, but the kind that would only
allow for incremental changes rather than the revolutionary changes that are
required to implement revolutionary programming techniques.

What you are ignoring is that there is a large number of
companies/developers who would pay for the product and support included
with this product. Microsoft could easily make a survey to check how many
licenses of VS including VB.COM they could sell.

Perhaps you are correct that people would be willing to pay for it. Again,
maybe it's my literal reading of the petition, but I certainly didn't get
the impression that it was asking for a new product for which people would
have to pay. I wonder how the reaction to the petition would change if
people knew they had to pay for VB.COM.

Surveys are showing that there are currently more people using Classic VB
than VB.NET. Wouldn't the logical impliciation be removing VB.NET and
enhancing and extending VB6?

No, it certainly is not the logical implication. One cannot just look at
the existing usage numbers to justify future development and support
efforts. Not to get too far off the subject, but a good example is
religion. There are billions of people who believe in a set of mutually
exclusive religions. By the definition of each respective holy books, only
one of these religions can be right, which means that the remaining billions
are wrong. So, sheer numbers doesn't make something right. If this logic
were applied to VB.NET, then it would never have been developed because 100%
of the developers at the time were using VB6. You have to, of course, look
at the relative merits of each individual language, not merely how many
people are currently using the language.

In my opinion, VB6 is an awful language. In the name of language stability,
it was patched and kludged together in such a way that it ended up as a heap
of chicken wire, duct tape, and band-aids. With VB.NET, Microsoft was able
to make a clean break with the past and incorporate object oriented design
principles into the language at a fundamental level. I think the reason
that there are more people using VB6 than VB.NET has more to do with the
inertia of an existing system than any distinct merit of the language
itself.

I don't like any of the two ways of discontinuing either Classic VB or
VB.NET. Both programming languages are requested and used by a large
number of constomers, so they should be kept alive.

In general I would agree with you, but I think the difference in opinion is
based on the definition of "kept alive". To me, keeping VB6 alive means VB6
should be kept on life support i.e. we should not "pull the plug".
Specifically, I think this means that Microsoft owes it to the licensees of
VB6 to ensure that it is bug free on the generation of Windows that was out
at the time. It necessarily follows that Microsoft should allow those
companies to run those legacy versions of Windows without being strong-armed
into upgrading to a version which might break the VB6 app. But once again,
I don't think that it's Microsoft's responsibility to extend and enhance VB6
in the way described by the petition.

On a more practical note, I think there is a very significant reason, based
not on technology, but instead on human nature, that VB.COM will never get
developed. Simply put, what Microsoft employee would want to work on
VB.COM? Not to sound too harsh, but I think any developer at Microsoft
would consider it an insult to be assigned to a project to enhance a product
as old as VB6. It my experience, the best and brightest programmers would
naturally gravitate towards newer products like VS.NET.

I don't believe that Microsoft is ignoring the number of people who are
currently using VB6. I just happen to think that Microsoft taking more than
just current developers into account in the decision on where to spend its
finite resources. Specifically, I think that on one side of the scale are
all of the current VB6 developers and on the other side of the scale are all
of the current VB.NET developers and every single *future* VB.NET developer.
Sure, VB6 developers may outnumber existing VB.NET developers, but current
programmers will pale in comparison to all of the new developers who will
come along and, in all likelihood, choose VB.NET over VB6.

Therein lies the heart of this debate. I think this petition is not
forward-thinking. It admits a shackling to the past. Microsoft approach is
properly accounting for the overwhelming number of future developers, albeit
at the expense of current developers. I know you are looking for solidarity
among the VB community, but I honestly don't think you are going to get it.
I believe there are just too many people that would view the kind of effort
the petition implies, even if it were paid for, as a waste of effort. I
would agree.

- Mitchell S. Honnert

 

[Herfried K. Wagner [MVP]]

Mitchell,

Well, "successor" is quite subjective. To me, it would be more accurate
to call VB.NET the successor to VB6 than the next "version" of Visual
Basic. "Successor" has the vague kind of meaning that could include the
next-in-line, even if it is a radical and revolutionary departure from its
predecessor. "Version" to me would imply language stability as described
at the link you provided. But that's all just terminology; what's
important are the underlying ideas.

I am not a native English speaker, so please excuse my occasional
inappropriate choice of words.

Incidentally, I haven't run across any instances where Microsoft stated
that there was "language stability" between VB6 and VB.NET.

VB.NET is VB 7.0, which means that it is a newer version of Visual Basic.
However, that's not the case. A name like B# version 1.0 would have been
more appropriate and would have caused much less confusion.

Because of the beta period for .NET and from all that I read at the time,
I knew full well that VB.NET was such a drastic change from VB6 that it
was all but a new language, albeit one with similar syntax and keywords.
I get the impression that you would have preferred that there was language
stability between VB6 to VB.NET, but I don't ever recall this being
Microsoft's position.

A version of real VB7 exists that was demonstrated at the BASTA conference
in Munich, Germany in 1999. However, this version has never been published.
So, Microsoft originally wanted to release a "real" VB7 which is a newer
version of the Visual Basic programming language. Later, development of
this version was stopped and instead VB.NET was marketed as the "new Visual
Basic".

Hmmm. Are you saying that you don't have a personal preference between
using VB.NET or VB6?

Definitely no. Do you have a preference between Assembler and Visual Basic
..NET? Both serve different purposes and are used by different people.
That's the reason why /you/ don't agree with the VB.COM position. You seem
to work in a different area and thus don't see where Classic VB is still
more appropriate than VB.NET. Nevertheless, that's not the point of the
petition. The petition is not about "is VB.NET better than Classic VB or
vice versa".

Perhaps this warrants another thread, but I find it inconceivable that an
experienced programmer would actually choose, all other things being
equal, to use VB6 instead of VB.NET.

There are situations without the possibility to choose, for example, when
maintaining existing code. I would prefer VB.NET in most cases for
developing /new/ applications, but my choice is limited to VB6 when editing
VB6 code. A rewrite of the code is not an option.

situation you describe happens, I would be OK with it. For example, let's
say that in a couple of years or so, Microsoft comes out with a
revolutionary new programming language that uses a BASIC-like syntax.
(Let's hope that if this happens, they'd come up with a better, less
confusion-causing name than .NET.) Who knows, perhaps there will be some
new style of programming that would require this kind of radical break
from the past. If I tried this new language out and thought its
improvements were worth the break in language stability, I'd switch over
to it, make it my personal language-of-choice, and seek out employers that
used it. If I didn't, I'd stick with VB.NET and hope for the best.

Well, I would not be OK with it. The evolutionary approach chosen in the
past which tried to /extend/ the existing programming language and
/deprecate/ language features that don't make sense any more in the new
environment (for example, direct memory access can be deprecated when the
new platform the program runs on doesn't support that) has one big
advantage: Almost full preservation of assets, no need for a rewrite. This
approach has been chosen by Microsoft up to VB6, and for almost all (I don't
know an exception) other programming languages. In contrast to that there
is the revolutionry approach that typically causes a lost of assets for
those who own code written in the "artificially obsoleted" programming
language. Notice that the evolutionary approach typically doesn't slow down
the introduction of new technology. Instead, by providing the direct
ability to reuse existing code with at max. a few changes resources can be
spent on extending the existing code instead of rewriting it. I already
included the quote of Gartner about migration cost in one of my posts to
this thread.

The point is that I think it is perfectly natural for programming
languages to go through a long phase of incremental change (which can
support language stability) followed by an instance of revolutionary
change (which obviously would not support language stability.) I think
this is what happened with VB6 and VB.NET and I personally think that it
is inevitable that it will happen to VB.NET.

Innovative new features can be introduced into most programming languages
without actually breaking existing code. For example, in VB.NET 'Wend' was
changed to 'End While', which doesn't have any rational reason. Changes
like this one only break existing code and make migration harder without
adding any benefits to the new programming language. There can be many more
samples found in the VB6 -> VB.NET transition, like changing 'Integer' ->
'Short', etc.

In my personal opinion, programming languages periodically need to make
changes that exist on such a fundamental level that language stability
cannot be maintained. The alternative is stagnation. Perhaps not a
complete stagnation, but the kind that would only allow for incremental
changes rather than the revolutionary changes that are required to
implement revolutionary programming techniques.

Please give me some samples where existing programming languages were
revolutionarily changed and then marketed as simply "the next version" of
the existing programming language.

Perhaps you are correct that people would be willing to pay for it.
Again, maybe it's my literal reading of the petition, but I certainly
didn't get the impression that it was asking for a new product for which
people would have to pay. I wonder how the reaction to the petition would
change if people knew they had to pay for VB.COM.

I feel sorry, but when asking for a new version of a product, it's obvious
that this new version would not be available for free.

Surveys are showing that there are currently more people using Classic VB
than VB.NET. Wouldn't the logical impliciation be removing VB.NET and
enhancing and extending VB6?

No, it certainly is not the logical implication. One cannot just look at
the existing usage numbers to justify future development and support
efforts. [...] So, sheer numbers doesn't make something right. If this
logic were applied to VB.NET, then it would never have been developed
because 100% of the developers at the time were using VB6.

VB.NET now exists for about four years. I doubt that the number of users
will increase more quickly than it did in the last four years. The number
of VB6 users decreased, but only for the reason that Microsoft never
released a "real" VB7.

In my opinion, VB6 is an awful language. In the name of language
stability, it was patched and kludged together in such a way that it ended
up as a heap of chicken wire, duct tape, and band-aids.

That's not the case. VB6 is simply an object-based programming language,
you cannot expect a full set of built-in OO features in it, for example.

With VB.NET, Microsoft was able to make a clean break with the past and
incorporate object oriented design principles into the language at a
fundamental level.

What's more clean with 'Wend' -> 'End While'?
What's more clean with 'Integer' being a 32-bit data type in VB.NET?
....

There have been so many changes that would not have been necessary and don't
make the language cleaner.

It's late in the night in Austria, that's why I'll not answer the rest of
your test...

BTW: There is an updated version of the petition's FAQ available:

Classic VB Petition FAQ
<URLhttp://classicvb.org/petition/faq.asp>

 

[Jim Hubbard]

The blog to which I referred is at http://poderthis.blogspot.com/.

 

[Jonathan West]

For those who are interested in the facts behind the petition, the petition
site now includes a FAQ page which answers most of the questions that have
been asked in this thread.

http://classicvb.org/petition/faq.asp

I am one of the signatories and I helped to draft the wording of the
petition. If anybody has questions that are not covered by the FAQ, I intend
to remain subscribed to the group for a while and answer any further
questions you may have.

Even if you make no use of VB6, I would still recommend that you sign the
petition. This is because Microsoft made changes to the VB syntax in the
move from VB6 to VB.NET that far exceeded the needs of "compatibility with
the platform". I'm not talking about new features and extensions, I am
talking about changed syntax and behavior that broke existing code.

Microsoft clearly believed that this was a sensible thing to do, and if they
are not disabused of that notion, they are likely to further "improve" the
language next time there is a platform change. Platforms come and go, and
..NET will not last for ever. If Microsoft, on introducing the successor to
..NET, decides to change the languages to the extent that even
platform-independent business logic code has to be rewritten, how will you
feel about the need to rewrite everything you have done since VB.NET was
introduced? Even more pertinent, how will you your employer feel about
having to pay you to write it all over again, and not add any new fetures
until the rewrite has been completed?


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

 

[Mitchell S. Honnert]

Herfried, thanks again for your reply. This deep into the thread, it's
probably just me and you reading the posts, nonetheless I've enjoyed the
exchange of ideas. Anyway...

VB.NET is VB 7.0, which means that it is a newer version of Visual Basic.
However, that's not the case. A name like B# version 1.0 would have been
more appropriate and would have caused much less confusion.

I'm not sure what you mean here. In point of fact, VB.NET is *not* VB 7.0.
Your argument would make more sense if they called it VB 7.0, which would
imply language stability. But Microsoft instead chose to give it an name
altogether outside of the standard version number convention. I personally
think that VB.NET is an extremely silly name, but the fact remains that the
".NET" implies a dramatic departure from its predecessor.

Definitely no. Do you have a preference between Assembler and Visual
Basic .NET? Both serve different purposes and are used by different
people. That's the reason why /you/ don't agree with the VB.COM position.
You seem to work in a different area and thus don't see where Classic VB
is still more appropriate than VB.NET.

I certainly do have a preference. Without a doubt, it's VB.NET. But just
because I have a personal preference, doesn't mean that I'm not aware of
business situations where other languages (assembler, C++, VB6, etc) would
be appropriate. I understand perfectly the situation where a company has
invested heavily VB6 development, it is not financially viable to convert
over to VB.NET. But personally, I do my best to avoid those environments
and, if given the choice (for example, if programming an application for my
own benefit), I would choose VB.NET.

The evolutionary approach chosen in the past which tried to /extend/ the
existing programming language and /deprecate/ language features that don't
make sense any more in the new environment (for example, direct memory
access can be deprecated when the new platform the program runs on doesn't
support that) has one big advantage: Almost full preservation of assets,
no need for a rewrite.

I guess we just disagree here. When I heard that VB.NET was going to be
built from the ground up as a new language, my reaction was "Hallelujah!
It's about time!" I was so sick of all of the little inconsistencies that
had crept into the language over time during its evolutionary enhancement,
that I thought a complete overhaul was long overdue. I'm not trying to get
into which is better, VB6 or VB.NET, but instead pointing out the reason why
VB.NET is so much better relates to the revolutionary changes in VB.NET.
Microsoft was able to start fresh and design a clean, consistent system that
without all of the baggage from VB6. Were some of the keyword changes
frivolous? Sure. But for the most part, I believe the actual improvements
that this approach allowed far outweigh the disadvantage of breaking
language stability.

I'm looking at these improvements from the standpoint of the new programmer,
not the experienced VB6 programmer. When teaching a new developer how to
program in VB6, I remember having to spend half the time teaching them the
rule and the other time teaching them all of the exceptions to the rule or
the "gotchas" to watch out for. It was maddening. But because VB.NET
started fresh, the architecture was so much simpler, that in my opinion,
it's much easier to teach a new programmer VB.NET than VB6. To a seasoned
VB6 programmer, who is already accustomed to all of the quirks in VB6,
eliminating the quirks seems like a waste of effort. But from the
perspective of all of the new programmers entering the field, why should
they have to learn all of these weird little peculiarities? To me, this
single aspect makes the leap to VB.NET worth all of the headaches.

Please give me some samples where existing programming languages were
revolutionarily changed and then marketed as simply "the next version" of
the existing programming language.

I did not intend to imply the situation you describe above exists, so I do
not have an example. The example I *do* have, which does relate to what I
was trying to convey, is of course the very topics of this discussion: VB6
and VB.NET. Specifically, I believe that VB6 had evolved to a point where
it could not be improved in the way that I felt was needed using the
standard evolutionary means.

BTW: There is an updated version of the petition's FAQ available:
Classic VB Petition FAQ
<URLhttp://classicvb.org/petition/faq.asp>

I've read the FAQ and find much of the logic specious. I should try and
post my rebuttals in a new thread. Thanks for the link though.

- Mitchell S. Honnert

Mitchell,

Well, "successor" is quite subjective. To me, it would be more accurate
to call VB.NET the successor to VB6 than the next "version" of Visual
Basic. "Successor" has the vague kind of meaning that could include the
next-in-line, even if it is a radical and revolutionary departure from
its predecessor. "Version" to me would imply language stability as
described at the link you provided. But that's all just terminology;
what's important are the underlying ideas.

I am not a native English speaker, so please excuse my occasional
inappropriate choice of words.

Incidentally, I haven't run across any instances where Microsoft stated
that there was "language stability" between VB6 and VB.NET.

VB.NET is VB 7.0, which means that it is a newer version of Visual Basic.
However, that's not the case. A name like B# version 1.0 would have been
more appropriate and would have caused much less confusion.

Because of the beta period for .NET and from all that I read at the time,
I knew full well that VB.NET was such a drastic change from VB6 that it
was all but a new language, albeit one with similar syntax and keywords.
I get the impression that you would have preferred that there was
language stability between VB6 to VB.NET, but I don't ever recall this
being Microsoft's position.

A version of real VB7 exists that was demonstrated at the BASTA conference
in Munich, Germany in 1999. However, this version has never been
published. So, Microsoft originally wanted to release a "real" VB7 which
is a newer version of the Visual Basic programming language. Later,
development of this version was stopped and instead VB.NET was marketed as
the "new Visual Basic".

Hmmm. Are you saying that you don't have a personal preference between
using VB.NET or VB6?

Definitely no. Do you have a preference between Assembler and Visual
Basic .NET? Both serve different purposes and are used by different
people. That's the reason why /you/ don't agree with the VB.COM position.
You seem to work in a different area and thus don't see where Classic VB
is still more appropriate than VB.NET. Nevertheless, that's not the point
of the petition. The petition is not about "is VB.NET better than Classic
VB or vice versa".

Perhaps this warrants another thread, but I find it inconceivable that an
experienced programmer would actually choose, all other things being
equal, to use VB6 instead of VB.NET.

There are situations without the possibility to choose, for example, when
maintaining existing code. I would prefer VB.NET in most cases for
developing /new/ applications, but my choice is limited to VB6 when
editing VB6 code. A rewrite of the code is not an option.

situation you describe happens, I would be OK with it. For example,
let's say that in a couple of years or so, Microsoft comes out with a
revolutionary new programming language that uses a BASIC-like syntax.
(Let's hope that if this happens, they'd come up with a better, less
confusion-causing name than .NET.) Who knows, perhaps there will be some
new style of programming that would require this kind of radical break
from the past. If I tried this new language out and thought its
improvements were worth the break in language stability, I'd switch over
to it, make it my personal language-of-choice, and seek out employers
that used it. If I didn't, I'd stick with VB.NET and hope for the best.

Well, I would not be OK with it. The evolutionary approach chosen in the
past which tried to /extend/ the existing programming language and
/deprecate/ language features that don't make sense any more in the new
environment (for example, direct memory access can be deprecated when the
new platform the program runs on doesn't support that) has one big
advantage: Almost full preservation of assets, no need for a rewrite.
This approach has been chosen by Microsoft up to VB6, and for almost all
(I don't know an exception) other programming languages. In contrast to
that there is the revolutionry approach that typically causes a lost of
assets for those who own code written in the "artificially obsoleted"
programming language. Notice that the evolutionary approach typically
doesn't slow down the introduction of new technology. Instead, by
providing the direct ability to reuse existing code with at max. a few
changes resources can be spent on extending the existing code instead of
rewriting it. I already included the quote of Gartner about migration
cost in one of my posts to this thread.

The point is that I think it is perfectly natural for programming
languages to go through a long phase of incremental change (which can
support language stability) followed by an instance of revolutionary
change (which obviously would not support language stability.) I think
this is what happened with VB6 and VB.NET and I personally think that it
is inevitable that it will happen to VB.NET.

Innovative new features can be introduced into most programming languages
without actually breaking existing code. For example, in VB.NET 'Wend'
was changed to 'End While', which doesn't have any rational reason.
Changes like this one only break existing code and make migration harder
without adding any benefits to the new programming language. There can be
many more samples found in the VB6 -> VB.NET transition, like changing
'Integer' -> 'Short', etc.

In my personal opinion, programming languages periodically need to make
changes that exist on such a fundamental level that language stability
cannot be maintained. The alternative is stagnation. Perhaps not a
complete stagnation, but the kind that would only allow for incremental
changes rather than the revolutionary changes that are required to
implement revolutionary programming techniques.

Please give me some samples where existing programming languages were
revolutionarily changed and then marketed as simply "the next version" of
the existing programming language.

Perhaps you are correct that people would be willing to pay for it.
Again, maybe it's my literal reading of the petition, but I certainly
didn't get the impression that it was asking for a new product for which
people would have to pay. I wonder how the reaction to the petition
would change if people knew they had to pay for VB.COM.

I feel sorry, but when asking for a new version of a product, it's obvious
that this new version would not be available for free.

Surveys are showing that there are currently more people using Classic
VB than VB.NET. Wouldn't the logical impliciation be removing VB.NET
and enhancing and extending VB6?

No, it certainly is not the logical implication. One cannot just look at
the existing usage numbers to justify future development and support
efforts. [...] So, sheer numbers doesn't make something right. If this
logic were applied to VB.NET, then it would never have been developed
because 100% of the developers at the time were using VB6.

VB.NET now exists for about four years. I doubt that the number of users
will increase more quickly than it did in the last four years. The number
of VB6 users decreased, but only for the reason that Microsoft never
released a "real" VB7.

In my opinion, VB6 is an awful language. In the name of language
stability, it was patched and kludged together in such a way that it
ended up as a heap of chicken wire, duct tape, and band-aids.

That's not the case. VB6 is simply an object-based programming language,
you cannot expect a full set of built-in OO features in it, for example.

With VB.NET, Microsoft was able to make a clean break with the past and
incorporate object oriented design principles into the language at a
fundamental level.

What's more clean with 'Wend' -> 'End While'?
What's more clean with 'Integer' being a 32-bit data type in VB.NET?
...

There have been so many changes that would not have been necessary and
don't make the language cleaner.

It's late in the night in Austria, that's why I'll not answer the rest of
your test...

BTW: There is an updated version of the petition's FAQ available:

Classic VB Petition FAQ
<URLhttp://classicvb.org/petition/faq.asp>

 

[Jonathan West]

I guess we just disagree here. When I heard that VB.NET was going to be
built from the ground up as a new language, my reaction was "Hallelujah!
It's about time!" I was so sick of all of the little inconsistencies that
had crept into the language over time during its evolutionary enhancement,
that I thought a complete overhaul was long overdue. I'm not trying to
get into which is better, VB6 or VB.NET, but instead pointing out the
reason why VB.NET is so much better relates to the revolutionary changes
in VB.NET. Microsoft was able to start fresh and design a clean,
consistent system that without all of the baggage from VB6. Were some of
the keyword changes frivolous? Sure. But for the most part, I believe the
actual improvements that this approach allowed far outweigh the
disadvantage of breaking language stability.

The problem with this is that if they had wanted to make the break
completely, there are many other changes that the could have made (and
probably wanted to make) such as the cast of True to 1 instead of -1 (which
was in Beta 1 and changed for Beta 2.)

If you're going to have a new language, you might as well make it thoroughly
new. And that, more or less, is what they did with C#.

But with VB.NET, they neither made it new enough to be as good as it might
be as a new language nor made it compatible enough to be a reasonable
upgrade and bring the VB6 codebase to .NET. So they were landed with the
worst of all possible worlds. We did try and warn them.


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

 

[Mitchell S. Honnert]

The problem with this is that if they had wanted to make the break

completely, there are many other changes that the could have made (and
probably wanted to make) such as the cast of True to 1 instead of -1
(which was in Beta 1 and changed for Beta 2.)

LOL. It's very ironic that you mention this particular issue, because I
used it as an example in an essay I wrote about how, at the time of the
VS.NET betas, I believed MS was pandering too much to the VB6 developer in
designing VB.NET. My basic contention was that they were breaking language
stability anyway, so why not go all of the way and eliminate these kinds of
legacy inconsistencies.

(If you're interested, the essay is here
http://home.fuse.net/honnert/imho/SunkCosts.htm.)

But even though I felt I had a "technologically righteous" justification for
my opinion, I begrudgingly admitted to myself that I understood the
reasoning that Microsoft was using. Personally, I think they knew they
could only stretch the rubber band so far before it broke. Specifically,
they were already making so many other changes, that they would occasionaly
"throw the dog a bone" by caving on one of these issue in an attempt to
appease the crowd who wanted VB.NET to be VB7. Microsoft was playing the
political game of trying to make everyone happy.

Another good example (which I used as well) was the change in the
shortcircuiting behavior of the "And" and "Or" operators during the betas.
Instead of putting its foot down and saying, "No, it is wrong to expect that
all of the parts of an expression be evaluated", Microsoft caved and added
the silly OrElse and AndAlso operators. In fact, this is a perfect example
of why I believe that a fundamental change was required to truly bring a
revolutionary change to Visual Basic, one that broke language stability. In
my opinion, short-circuiting of logical operators should be the natural
behavior. But that would have meant that people would not have been able to
port VB6 code straight into VB.NET code; there would have been no way to
tell if you were using VB6's lack of short-circuiting logic. So, they made
VB.NET more complex than it had to be in order to appease VB6 programmers.

But with VB.NET, they neither made it new enough to be as good as it might
be as a new language nor made it compatible enough to be a reasonable
upgrade and bring the VB6 codebase to .NET. So they were landed with the
worst of all possible worlds. We did try and warn them.

While I admit to disagreeing with some of Microsoft's decisions about how to
best redesign Visual Basic, I wouldn't go so far as to say it's the worst of
all possible worlds. I believe that no matter what Microsoft did, they
would have had thousdands, if not millions of people who disagreed. I
personally think they gave too much consideration to the existing (at the
time) langauge, but in general, they did a very good job with the redesign.

- Mitchell S. Honnert

 

[Jonathan West]

Hi Mitchell

LOL. It's very ironic that you mention this particular issue, because I
used it as an example in an essay I wrote about how, at the time of the
VS.NET betas, I believed MS was pandering too much to the VB6 developer in
designing VB.NET. My basic contention was that they were breaking
language stability anyway, so why not go all of the way and eliminate
these kinds of legacy inconsistencies.

I think you may need to realise a few things

1. You seem to be making the mistake of assuming that because C/C++ does
things in a particular way, it is necessarily right for all other languages
to do the same.

2. The way Basic has handled this feature has been perfectly consistent
since long before Windows existed. What you were arguing against was not a
"legacy inconsistency" but simply a lack of consistency with the way C++ and
Java programmers are used to doing things. The way this works makes perfect
sense if you realise that the VB boolean operators are bitwise. Take a look
here for a fuller treatment of the issue. http://vb.mvps.org/tips/truth.asp

3. Microsoft made a big mistake in thinking that doing a token reversal of
two or three changes would remove the underlying problems of
incompatibility. The Beta 1 rollbacks were clearly necessary if VB.NET were
going to be made a practical upgrade path, but it was always clear that they
were far from sufficient. Microsoft was told this at the time, but took no
notice, with predictably dire results.

4. It clearly *was* Microsoft's original intention to make VB.NET compatible
with VB6. But something got lost along the way. The following was the
Statement of principles which was included in the Beta 1 documentation for
VB.NET

"The design of Visual Basic 7.0 encompasses the following principles, in
relative order of importance:

- Visual Basic 7.0 is recognizable as the descendent of previous versions of
Visual Basic, and an existing Visual Basic programmer will feel an immediate
familiarity with the language.

- Visual Basic 7.0 syntax and semantics are simple, straightforward and easy
to understand. The language avoids features that cause unexpected behavior.

- Visual Basic 7.0 allows developers to take advantage of the major features
of the NGWS Frameworks and Runtime and is consistent with the its
conventions.

- Visual Basic 7.0 is reasonably "upgradeable" from previous versions of
Visual Basic. That is, it is possible in a significant number of cases to
take existing Visual Basic code and, with a well-defined set of
transformations, produce a working Visual Basic 7.0 program.

- Because the NGWS Runtime is explicitly designed to support multiple
computer languages, Visual Basic 7.0 is designed to work well in a
multi-language environment.

- Visual Basic 7.0 is as compatible with previous versions of Visual Basic
as possible. Whenever practical, Visual Basic 7.0 has the same syntax, the
same semantics and the same runtime behavior as its predecessors."

I think that all of this documentation has been removed from the final
product documentation and from the MSDN website.


But whether or not Microsoft intended breaking compatibility, the fact
remains that they achieved it, leaving many substantial VB6 projects with no
practical migration path to updated development tools. The petitioners are
looking to reverse the damage that has been caused.

By the way, don't assume that means that the petitioners would like to see
VB.NET as it currently stands discontinued. We would not wish you to have to
go through the same experience. But if Microsoft thinks that changing
platform means that they can and should change languages, then that is what
will happen to you when .NET is superseded. If you want to avoid this, I
would suggest you sign the petition.

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

 

[Mitchell S. Honnert]

Hello Jonathan. You bring up some interesting points. Please see below for
comments.

1. You seem to be making the mistake of assuming that because C/C++ does
things in a particular way, it is necessarily right for all other
languages to do the same.

I'm not sure how you got this from what I've stated. I've done some C/C++
coding in my day, but it's been so little that I don't think it's skewed my
concept of what I think is "right" for all programming languages.

2. The way Basic has handled this feature has been perfectly consistent
since long before Windows existed. What you were arguing against was not a
"legacy inconsistency" but simply a lack of consistency with the way C++
and Java programmers are used to doing things. The way this works makes
perfect sense if you realise that the VB boolean operators are bitwise.
Take a look here for a fuller treatment of the issue.
http://vb.mvps.org/tips/truth.asp

I find it ironic that you are emphasizing the concept of consistency so
much, whereas the whole point I was trying to get across (in both my post
and my original essay) is that there are more important issues than being
consistent with the previous generation. Up to VB.NET, True always
evaluated to -1. Does that make it right just because "that's the way we've
always done it around here"? Independent of whether certain languages
handle a certain feature, I believe there are objective rights and wrongs in
language design. Specifically, in deciding on how a particular language
feature should function, one should take into account what has been done in
the past, but not let it dictate the design. I'll have to read the article
at that link you provided more carefully, but I still believe that True
evaluating to -1 is wrong. The point is academic given the proper use of
Booleans, but I still found it extremely inconsistent that one of the most
fundamental principles in the field of computing -- that 1 is True and 0 is
False -- should be not be reflected in VB6. I understand you have a very
nice explanation about the underlying technical reason that True is -1 in
VB6, but to me it smacks too much of letting the internal operations of the
computer dictate language design. It's the tail wagging the dog.

4. It clearly *was* Microsoft's original intention to make VB.NET
compatible with VB6. But something got lost along the way. The following
was the Statement of principles which was included in the Beta 1
documentation for VB.NET

This is my personal opinion, but what I think "got lost along the way" was
the albatross around Microsoft's neck of backwards compatibility and
language stability. Not to get too melodramatic here, but what I think
happened is that during the development of .NET, Microsoft broke the chains
that had enslaved it to the collective kludge known as Visual Basic 6. I
don't doubt for a minute that Microsoft started out the design of VS.NET
with the statement of principles you listed. But somewhere along the way,
someone must have said something like, "You know what? We can't truly take
VB to the next level unless we scrap all of the quirky, eccentric,
inconsistent stuff in VB6. We have to start fresh."

But whether or not Microsoft intended breaking compatibility, the fact
remains that they achieved it, leaving many substantial VB6 projects with
no practical migration path to updated development tools. The petitioners
are looking to reverse the damage that has been caused.

It's undisputed that Microsoft broke backward compatibility and language
stability between VB6 and VB.NET. What is at the heart of our disagreement
is whether the costs ("no practical migration path", etc) outweigh the
benefits (the logic, uniformity, and consistency of the .NET framework). On
that note, I don't think that Microsoft owes the licensees of VB6 a
"practical migration path to updated development tools". I've mentioned
this in this thread before, but I believe Microsoft does owe VB6 licensees
is bug fixes and the continued ability to develop and run their applications
on the generation of operating systems that was around during its standard
support period. In other words, I think Microsoft owes it to VB6 users to
fix broken functionality, not add new functionality or development tools.
To me this is the natural cost of the occasional revolutionary change in
development tools.

By the way, don't assume that means that the petitioners would like to see
VB.NET as it currently stands discontinued.

I certainly don't think that. On the other, I do believe that the
implementation of VB.COM would require Microsoft to spend so much time and
money to enhance the *previous* generation of VB, that there would be a
substantially reduced ability to enhance the *current* generation of VB. In
other words, the petitioners may not be stating that they want to
discontinue improving VB.NET, but the implication of what they are
suggesting would be a radical reduction in the continued improvement of
VB.NET. That is why I will not sign the petition in its current state, nor
do I believe anyone else should.

- Mitchell S. Honnert



We would not wish you to have to

 

[Jonathan West]

Hello Jonathan. You bring up some interesting points. Please see below
for comments.

I'm not sure how you got this from what I've stated. I've done some C/C++
coding in my day, but it's been so little that I don't think it's skewed
my concept of what I think is "right" for all programming languages.

OK, that might not be where you are coming from, but I assure you it is
where the Visual Studio development team (C++ coders, every one of them)
were coming from.

I find it ironic that you are emphasizing the concept of consistency so
much, whereas the whole point I was trying to get across (in both my post
and my original essay) is that there are more important issues than being
consistent with the previous generation. Up to VB.NET, True always
evaluated to -1. Does that make it right just because "that's the way
we've always done it around here"?

This depends on whether you are creating a new language or extending an
existing one.

If you are creating a new language, sure, jettison everything which gets in
the way of a perfect clean consistent design that can then be made to last
as long as possible.

But if you are creating an extension to an existing language, the only
possible purpose in doing so (rather than making a new language) is to
enable existing projects to make use of the new features you are offering.
As a purely practical necessity, this requires that existing projects can be
made to run in the new version with minimal rewriting. In turn, this
restricts the areas in which you can innovate.

Independent of whether certain languages handle a certain feature, I
believe there are objective rights and wrongs in language design.
Specifically, in deciding on how a particular language feature should
function, one should take into account what has been done in the past, but
not let it dictate the design. I'll have to read the article at that link
you provided more carefully, but I still believe that True evaluating
to -1 is wrong.

If we accept for the sake of argument that Microsoft's original intention
was to produce an upgrade, then whether is is right or wrong that True casts
to -1 is not the right question. The right question to ask is whether
changing it will break an unreasoable number of existing projects which have
depended on the -1 up to now, given that it has been a documented part of
the language definition all these years. If the answer to this us "yes",
then the change should not be made.

This is my personal opinion, but what I think "got lost along the way" was
the albatross around Microsoft's neck of backwards compatibility and
language stability. Not to get too melodramatic here, but what I think
happened is that during the development of .NET, Microsoft broke the
chains that had enslaved it to the collective kludge known as Visual Basic
6. I don't doubt for a minute that Microsoft started out the design of
VS.NET with the statement of principles you listed. But somewhere along
the way, someone must have said something like, "You know what? We can't
truly take VB to the next level unless we scrap all of the quirky,
eccentric, inconsistent stuff in VB6. We have to start fresh."

But they did start fresh - they wrote C#. I do rather wonder how they came
to the view that what they really, really needed was *two* new languages and
no upgrade path for their most popular language.

It's undisputed that Microsoft broke backward compatibility and language
stability between VB6 and VB.NET. What is at the heart of our
disagreement is whether the costs ("no practical migration path", etc)
outweigh the benefits (the logic, uniformity, and consistency of the .NET
framework). On that note, I don't think that Microsoft owes the licensees
of VB6 a "practical migration path to updated development tools". I've
mentioned this in this thread before, but I believe Microsoft does owe VB6
licensees is bug fixes and the continued ability to develop and run their
applications on the generation of operating systems that was around during
its standard support period. In other words, I think Microsoft owes it to
VB6 users to fix broken functionality, not add new functionality or
development tools. To me this is the natural cost of the occasional
revolutionary change in development tools.

They owe it to their customers - all their customers, and not just VB6
coders - not to damage the value of their data. By providing no practical
upgrade path, Microsoft has declared that VB6 code (an important and
valuable kind of data) is regarded by them as being disposable and not
having lasting value. Whose data will be next?

I certainly don't think that. On the other, I do believe that the
implementation of VB.COM would require Microsoft to spend so much time and
money to enhance the *previous* generation of VB, that there would be a
substantially reduced ability to enhance the *current* generation of VB.

Be careful what you ask for! If Microsoft cotinues to develop VB.NET in the
same way it moved from VB6, it won't be all that long before they decide to
modernise the lnmaguage all over again. And you may then find yourself
wishing they had spent a little less resource on it....

I genuinely hope that you never find yourself on the other side of that
equation and spoken to in the same vein by supporters of Microsoft's Next
Big Idea, and who have not made the investment in VB.NET that you are
currently making, or perhaps that your employers are making by paying you to
write VB.NET code.

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

 

[Mitchell S. Honnert]

Jonathan, thanks for your reply. I have some responses, but I have to start
with your last comment first, as I believe it gets to the very heart of our
difference of opinion, shedding a different light on the other points.

Be careful what you ask for! If Microsoft cotinues to develop VB.NET in
the same way it moved from VB6, it won't be all that long before they
decide to modernise the lnmaguage all over again. And you may then find
yourself wishing they had spent a little less resource on it....
I genuinely hope that you never find yourself on the other side of that
equation and spoken to in the same vein by supporters of Microsoft's Next
Big Idea, and who have not made the investment in VB.NET that you are
currently making, or perhaps that your employers are making by paying you
to write VB.NET code.

You appear as if you not only don't want there to be another major change to
VB, but are also assuming that other people don't want that change either.
The thing is, I *want* there to be another radical change to VB! I *want*
to go through all of the turmoil again of transferring to a revolutionary
new programming language based on VB. Why? For the simple reason that,
based on the historical precedence of the change from VB6 to VB.NET, the
only time that Microsoft makes these kinds of revolutionary changes to the
programming language is when there is a need to implement a radicaly
different programming approach. And if Microsoft were coming out with a new
version of VB that broke backward compatability and language stability, it
would mean that there must be some new programming style that would make
VB.NET as much better than VB.NET was over VB6. I would welcome this kind
of improvement, not dread it. I'd be the first one to download the demo,
the first one to convert my own programs over to the new language, and (if I
found it to be truly a worthy successor, like I did VB.NET), the first one
to pester my employer to use it for new development. I don't expect that
object oriented design is going to be replaced any time soon, but if it
were, I'd be right there, ready to give it a shot.

This depends on whether you are creating a new language or extending an
existing one.
If you are creating a new language, sure, jettison everything which gets
in the way of a perfect clean consistent design that can then be made to
last as long as possible.

But that's presicely what Microsoft did with VB.NET, create a new language.
That's why they didn't call it VB7, but something different, something that
would imply a dramatic departure from the current version. Regardless of
what the intent was at the start of development on what would become VB.NET,
it's indisputable that Microsoft ended up with the goal of creating a new
language.

But if you are creating an extension to an existing language, the only
possible purpose in doing so (rather than making a new language) is to
enable existing projects to make use of the new features you are offering.

The problem with the term "extension" (and "successor" and "next version",
for that matter) is that it's subjective and open to interpretation.
Regardless of what term you use, you would have to agree that the very point
of contention here is that Microsoft treated the development of VB.NET as if
it were a new language. We appear to be coming from the problem at
different angles. I view VB.NET as the successful creation of a completely
new language, albeit one that borrowed a lot from VB6, whereas you appear to
be viewing VB.NET as the failure of the creation of an extension of VB6. Is
this a fair summary?

If we accept for the sake of argument that Microsoft's original intention
was to produce an upgrade, then whether is is right or wrong that True
casts to -1 is not the right question. The right question to ask is
whether changing it will break an unreasoable number of existing projects
which have depended on the -1 up to now, given that it has been a
documented part of the language definition all these years. If the answer
to this us "yes", then the change should not be made.

The above point illistrates perfectly the affect of the different viewpoint
mentioned above. I do not accept that the *final* intention of Microsoft
was to produce an upgrade. (Their original intent is irrelevant given the
end result of what VB.NET became.) So, in my opinion, whether True casts
to -1 is the best design *is* the right question to ask regardless of how
this will affect legacy code.

But they did start fresh - they wrote C#. I do rather wonder how they came
to the view that what they really, really needed was *two* new languages
and no upgrade path for their most popular language.

I don't think I'm telling you anything you don't already know, but just for
the record, the reason that Microsoft created a .NET version of Visual Basic
was for the simple reason to appeal to Visual Basic developers. Microsoft
was creating a radically new language and, from a sociological standpoint,
they understood the best approach to gaining adoption was to appeal to
current VB6 developers. No mystery there. I, for one, am glad that I
wasn't forced to use C# to get the benefits of VS.NET. If given the choice
between C# and VB6, I would choose C# in a second, but fortunatelly for me,
Microsoft gave me VB.NET, a completely new language from one standpoint, but
one that was immediatly familiar given the similarity in syntax and
keywords. (Man, I hate C#'s squigly braces!)

They owe it to their customers - all their customers, and not just VB6
coders - not to damage the value of their data.

Microsoft is not damaging their "data"; *time* is. It is unreasonable to
expect that Microsoft continue to give, in perpetuity, the same level of
support to previous generations of product as they do to their current
generation.

By providing no practical upgrade path, Microsoft has declared that VB6
code (an important and valuable kind of data) is regarded by them as being
disposable and not having lasting value. Whose data will be next?

This is the point where we have some agreement. I personally think that
Microsoft made the right decision to make VB.NET into a radical departure
from VB6, even if it meant that simple, automated porting of VB6 code to
VB.NET code was impractical. Having said this, I would agree that Microsoft
owes orphaned products (which, in effect, VB6 is at this point) more than
just what a previous generation product would get. Where our disagreement
comes is in exactly what this level of support means. As I've stated
before, I believe it means making sure that the product can continue to work
as it did at the time of its "primary support period". In VB6's case, I
think one of the major issues would be to ensure that COM interop really
worked as advertised and to not punish or prevent companies from using
versions of Windows that are known to be compatible with VB6. But, the
major effort that would be required to create VB.COM? Sorry, but no.

On a more practical note, if I were in the unfortunate position of being a
VB6 developer these day, I might publicly agree with my employer about how
awful it was the Microsoft was pulling mainstream support, but internally,
I'd be jumping for joy. In fact, I'd want Microsoft to announce that the
next service pack of Windows would instantly break all versions of VB
previous to VB.NET. In other words, anything that forced my employer's hand
to make the switch from VB6 to VB.NET would be welcome, even if it was the
"hand of God" in the form of some Microsoft edict. I will fully admit that
this makes no sense from the employer's standpoint that has to pay the
programmers to make the switch, but if I were living the workday hell of
having to program VB6 once I'd "seen the light" and experienced how much
better it is to program in VB.NET, I wouldn't care how much it cost my
employer.

- Mitchell S. Honnert

 

[Jonathan West]

Jonathan, thanks for your reply. I have some responses, but I have to
start with your last comment first, as I believe it gets to the very heart
of our difference of opinion, shedding a different light on the other
points.

You appear as if you not only don't want there to be another major change
to VB, but are also assuming that other people don't want that change
either. The thing is, I *want* there to be another radical change to VB!
I *want* to go through all of the turmoil again of transferring to a
revolutionary new programming language based on VB.

That's great if you want to do the same work over & over again, especially
if you can con somebody into paying for it. Good luck to you! But I think
you may find that those who have long-lasting commercial applications take a
somewhat different view, particularly if they are business oweners trying to
make an honest profit rather than programmers wanting to play with the
latest toys.

The problem with the term "extension" (and "successor" and "next version",
for that matter) is that it's subjective and open to interpretation.
Regardless of what term you use, you would have to agree that the very
point of contention here is that Microsoft treated the development of
VB.NET as if it were a new language. We appear to be coming from the
problem at different angles. I view VB.NET as the successful creation of
a completely new language, albeit one that borrowed a lot from VB6,
whereas you appear to be viewing VB.NET as the failure of the creation of
an extension of VB6. Is this a fair summary?

It depends entirely on what Microsoft's intentions were. Based on their own
documentation in the beta, it appears that their intention was to make a new
version of VB, essentially the same language but on a new platform. Judging
by that stated intention, we you would agree that they failed.

Whether they succeeded in creating a great new language I will leave to you
to decide. Also, whether or not VB.NET is great, it would be hypocritical of
me to hope that its syntax is changed to break your code, and so I genuinely
hope that you and other VB.NET coders have the opportunity to continue
developing in VB.NET even after the .NET platform is superseded. I'm not all
that sanguine about the chances of it happening through.

I don't think I'm telling you anything you don't already know, but just
for the record, the reason that Microsoft created a .NET version of Visual
Basic was for the simple reason to appeal to Visual Basic developers.

Its a strange thing, but quite a lot of Visual Basic developers have
developed Visual Basic code which they are responsble for. Would you like to
explain to me how a radical new language which is incompatible with their
Visual Basic code to is going to appeal to these Visual Basic developers?
I've talked to a great many of them, and this appeal escapes them as
thoroughly as it has escaped me.

Microsoft was creating a radically new language and, from a sociological
standpoint, they understood the best approach to gaining adoption was to
appeal to current VB6 developers. No mystery there.

It would seem to me that the best approach to gaining adoption would have
been to make a language that could actually be used to extend existing
Visual Basic projects. 4 years after VB.NET was introduced, published
surveys indicate that VB6 is still in more widespread use than VB.NET.

Microsoft is not damaging their "data"; *time* is. It is unreasonable to
expect that Microsoft continue to give, in perpetuity, the same level of
support to previous generations of product as they do to their current
generation.

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?

On a more practical note, if I were in the unfortunate position of being a
VB6 developer these day, I might publicly agree with my employer about how
awful it was the Microsoft was pulling mainstream support, but internally,
I'd be jumping for joy. In fact, I'd want Microsoft to announce that the
next service pack of Windows would instantly break all versions of VB
previous to VB.NET. In other words, anything that forced my employer's
hand to make the switch from VB6 to VB.NET would be welcome, even if it
was the "hand of God" in the form of some Microsoft edict. I will fully
admit that this makes no sense from the employer's standpoint that has to
pay the programmers to make the switch, but if I were living the workday
hell of having to program VB6 once I'd "seen the light" and experienced
how much better it is to program in VB.NET, I wouldn't care how much it
cost my employer.

Well, it might cost your employer and you your job. I think I have you
pegged. You just like playing with new toys, and don't like the day-to-day
responsibility of managing and ongoing project. Well, each to his own, and
if you can make a living at it, good luck to you.


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

 

[Mitchell S. Honnert]

That's great if you want to do the same work over & over again, especially

if you can con somebody into paying for it. Good luck to you! But I think
you may find that those who have long-lasting commercial applications take
a somewhat different view, particularly if they are business oweners trying
to make an honest profit rather than programmers wanting to play with the
latest toys.

How does making a new programming language available require anyone to do
work "over & over"? I've stated that I believe that Microsoft owes it to
any orphaned product the ability to continue to run on that generation's
version of Windows. My reasoning for this is so that business owners don't
*have* to move to the next generation if they don't want to. If a business
owner wants to stick with what they have, then that's their business. They
have the right to do so and Microsoft owes them just enough support to keep
them going. But if they want the best of the latest generation -- what you
refer to as "toys" -- then and only then would they have to expend
additional work.

It depends entirely on what Microsoft's intentions were. Based on their
own documentation in the beta, it appears that their intention was to make
a new version of VB, essentially the same language but on a new platform.
Judging by that stated intention, we you would agree that they failed.

I honestly don't see why you are focusing so much on what Microsoft's
original intentions were. Microsoft obviously changed their mind after they
published that documentation in the beta. You appear to be judging them
based on statements that were pulled off of their web site. As much as you
may wish that Microsoft would have adhered to the principles listed, the
fact is that they changed their mind. Microsoft did not fail to create VB7;
they succeeded in creating VB.NET.

Its a strange thing, but quite a lot of Visual Basic developers have
developed Visual Basic code which they are responsble for. Would you like
to explain to me how a radical new language which is incompatible with
their Visual Basic code to is going to appeal to these Visual Basic
developers? I've talked to a great many of them, and this appeal escapes
them as thoroughly as it has escaped me.

It's quite simple really. If one is accustomed to the general syntax and
keywords of a language, then the transition to the next revolutionary step
in programming languages will be much easier if its language is similar to
your preferred language. So, VB6 developers were greatly benefited by
VB.NET in so much as they could use the new capabilities and OO features of
..NET without having to learn an entirely new language. I see it as a
natural thing that a programming language goes through a revolutionary
change after a period of evolutionary change. Using the previous generation
of language as the foundation from the new makes this periodic transition
easier.

It would seem to me that the best approach to gaining adoption would have
been to make a language that could actually be used to extend existing
Visual Basic projects.

But the intent wasn't to get users to adopt to the just any new version of
Visual Basic. The main goal was not increased adoption, but increased
adoption of a substantially better product over an entrenched product.

4 years after VB.NET was introduced, published surveys indicate that VB6
is still in more widespread use than VB.NET.

This statistic is meaningless. Of course VB6 is more widespread than
VB.NET. I won't even bother to ask if "widespread" is defined by distinct
applications, by users, or by companies, because it doesn't matter. It's
only obvious that the end-version of a language set that has been around for
years will have more of an established base than a relative newcomer.

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.

Well, it might cost your employer and you your job.

True enough. For me personally, however, I have had the luck/luxury of
being able to work at companies that don't require me to work with VB6 any
more. Don't get me wrong. At the time, it was a great tool. But now that
something so much its superior is around, I personally don't want anything
to do with VB6. I realize, though, that there are plenty of people who
still like working with VB6. I'm glad they are there, else there'd be more
of a chance that'd I'd have to deal with VB6.

I think I have you pegged. You just like playing with new toys, and don't
like the day-to-day responsibility of managing and ongoing project. Well,
each to his own, and if you can make a living at it, good luck to you.

Jonathan, you don't have to insult me. We obviously have our differences of
opinion, but this kind of attack is uncalled for. I happen to rather enjoy
the responsibility of managing professional projects on a day-to-day basis.
In fact, as you may have guessed from my dedication to this thread, I'm
rather passionate about technology and the advancement thereof. I will
admit to a desire to use new technology to its fullest benefit, but then
again, I perfectly understand the conflict between ideology and economics.
In other words, I may personally abhor working with VB6 now, but I
understand the economic constraints which prevents companies from switching
to VB.NET.

- Mitchell S. Honnert

 

[Herfried K. Wagner [MVP]]

How does making a new programming language available require anyone to do
work "over & over"? I've stated that I believe that Microsoft owes it to
any orphaned product the ability to continue to run on that generation's
version of Windows.

Well, there are already problems when running VB6 applications on Windows XP
which were never fixed and which will be most likely never fixed...

 

[Ray Cassick \(Home\)]

But I never saw anything that stated MS promised that VB6 apps would run on
newer platforms.

Obviously things in XP have changed (and thankfully so IMHO) so what is the
deal there? People want to make their apps run on Windows XP that had
problems just released a service pack to their apps that fixed the problem.
The same darn thing happened to several apps when Windows XP SP2 came out
for crying out loud.

Over time everything will change and it is up to us a developers to embrace
that and change with it.

Tons of people make the argument that states they have C++ code that has
been running for years without ever having to be changed no matter what
platform it has been run on. That is a testament to the low level nature of
C++ for sure, but VB6 (and VB.NET as well as C# and managed C++ now) have a
layer in there to worry about. Get used to it. One more ting to worry about
I guess. It will be the price we pay for having two different parts of a
platform (OS and upper level framework) to get along with until it all
becomes one.

 

[Herfried K. Wagner [MVP]]

Ray,

But I never saw anything that stated MS promised that VB6 apps would run
on newer platforms.

Obviously things in XP have changed (and thankfully so IMHO) so what is
the deal there? People want to make their apps run on Windows XP that had
problems just released a service pack to their apps that fixed the
problem. The same darn thing happened to several apps when Windows XP SP2
came out for crying out loud.

Over time everything will change and it is up to us a developers to
embrace that and change with it.

The bug/problem I am thinking of is in VB's forms implementation. It's not
the developer's fault that certain things do not work on Windows XP as they
should. Notice that the VB6 runtime is still supported, however, not all
known bugs get fixed!!!

As a consequence, the developer can choose from (1) rewriting the
application (or at least the UI layer) in another programming language,
which doesn't base its forms model on a faulty library or (2) searching for
a "hack" that solves the problem, but may introduce further problems, or (3)
don't changing anything. (1) is too expensive if there is no suitable
upgrade path (the current situation for many VB6 projects), (2) will reduce
the quality of the implementation/source code because it now contains a
workaround for a bug in a library it uses, and (3) is not an option too
because the customer will experience faulty behavior in the application.

 

[Jonathan West]

How does making a new programming language available require anyone to do
work "over & over"? I've stated that I believe that Microsoft owes it to
any orphaned product the ability to continue to run on that generation's
version of Windows. My reasoning for this is so that business owners
don't *have* to move to the next generation if they don't want to. If a
business owner wants to stick with what they have, then that's their
business. They have the right to do so and Microsoft owes them just
enough support to keep them going. But if they want the best of the
latest generation -- what you refer to as "toys" -- then and only then
would they have to expend additional work.

That's not really good enough. There is no reason to assume that algorithms
and business logic all have a life lasting only as long as the generation of
Windows in which they were first written. If they have a life exceeding
that, then there is a need to recompile the source code onto a new platform.
If that involves a rewrite, then that is an unnecessary duplication of
effort. if that has to happen every time Microsoft brings out a new
platform, then the work has to be done "again and again".

It's one thing to extend a project to make use of the latest platform
features. It is quite another to have to rewrite it altogether in order to
get it to run at all on a new platform even before any new features are
added. But this is what a language change means. Those who are responsible
for paying programmers or for making a business case for moving to a new
platform may take a much dimmer view of this than you do.


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

 

[Mitchell S. Honnert]

There is no reason to assume that algorithms and business logic all have a

life lasting only as long as the generation of Windows in which they were
first written.

But algorithms and business logic don't exist in a vacuum; they of course
exist in the context of a programming language. And there is *every* reason
to believe that a programming language, like any application, has a finite
lifetime. We can discuss where the cutoff point is, but surely you would
agree that Microsoft shouldn't have to support VB6 on *every* future version
of Windows. I've granted that ideologically, a company may want to move to
VB.NET, but economically may not be able to do so. Can't you see the
parallel that Microsoft may ideologically want to fully support all previous
programming languages, but has to make an economic decision at some point to
reduce the full level of support? If they didn't do this, they'd be crushed
under the weight of supporting so many legacy languages that they'd have no
time for any development on new languages.

I believe that your counter to this argument would be that there are so many
more companies who are still using VB6 at this point than expected, that
Microsoft should not only stop, but reverse this "phase out" process. I
would disagree. As long as Microsoft doesn't use some kind of strong-arm
licensing scheme to force a company to move to the latest OS (this may be a
different thread altogether), then it doesn't matter how many people are
currently using VB6. It's ultimately up to them if they want to use it on
the supported OS or gamble on a new and not fully-supported OS.

If they have a life exceeding that, then there is a need to recompile the
source code onto a new platform. If that involves a rewrite, then that is
an unnecessary duplication of effort. if that has to happen every time
Microsoft brings out a new platform, then the work has to be done "again
and again".

But a company doesn't *have* to move to the new platform just because
Microsoft makes it available. It's their choice whether to move to that new
platform. And one of the major aspects of that decision is whether that
company has mission critical applications written in a language not
supported by the new platform. You may view this as a Hobson's choice, but
I do not. If the company wants to move to each new generation of OS, then
they might have to do some work "again and again" to move to the next
generation of application development tool. But it's their choice. This
seems obvious and natural to me.

- Mitchell S. Honnert

 

[Jonathan West]

But algorithms and business logic don't exist in a vacuum; they of course
exist in the context of a programming language. And there is *every*
reason to believe that a programming language, like any application, has a
finite lifetime. We can discuss where the cutoff point is, but surely you
would agree that Microsoft shouldn't have to support VB6 on *every* future
version of Windows.

If a reasonable migration path were available, there would be no need to.
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. 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've granted that ideologically, a company may want to move to VB.NET, but
economically may not be able to do so. Can't you see the parallel that
Microsoft may ideologically want to fully support all previous programming
languages, but has to make an economic decision at some point to reduce
the full level of support? If they didn't do this, they'd be crushed
under the weight of supporting so many legacy languages that they'd have
no time for any development on new languages.

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! It was far and away Microsoft's most popular language
product, with estimates of the number of users being between 3 million and 6
million, depending on who you listened to. It was no more aged than the
C/C++ language grouping, and that is being preserved most carefully.

I believe that your counter to this argument would be that there are so
many more companies who are still using VB6 at this point than expected,
that Microsoft should not only stop, but reverse this "phase out" process.
I would disagree. As long as Microsoft doesn't use some kind of
strong-arm licensing scheme to force a company to move to the latest OS
(this may be a different thread altogether), then it doesn't matter how
many people are currently using VB6. It's ultimately up to them if they
want to use it on the supported OS or gamble on a new and not
fully-supported OS.

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. 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 Microsoft had made a better job of the
migration, the petition would never have happened and we wouldn't be having
this conversation.

But a company doesn't *have* to move to the new platform just because
Microsoft makes it available. It's their choice whether to move to that
new platform. And one of the major aspects of that decision is whether
that company has mission critical applications written in a language not
supported by the new platform. You may view this as a Hobson's choice,
but I do not. If the company wants to move to each new generation of OS,
then they might have to do some work "again and again" to move to the next
generation of application development tool. But it's their choice. This
seems obvious and natural to me.

I agree that it's their choice. It's also obvious to me that it is in
Microsoft's interest to encourage people to move up. And on this particular
occasion, they have made a hash of it, and raised to the cost of moving on
in a way that is significantly against their own best interest. I hope they
learn from the experience. I hope they now do the right thing and go back
and do what can be done to fix the mess.


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