182  7332 
Mitchell,
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb: I've read the petition and find it a bit ironic that there was no mention
made of the end of "mainstream" support when this is what presumably
triggered the petition in the first place.
We didn't (publically) set an end date for the petition, so maybe it will
continue to be open for signing after March 31. In addition to that the
petition's topic is not limited to VB6, it includes VBA too. The end of
"mainstream" support was not the main force behind starting the petition.
Issues mentioned in the petition are not new and have been discussed for
some years now.
The petition instead appears to focus on the suggestion that VB6
should be "enhanced and extended" VB6 in order to extend its lifetime.
That's true. What we are currently facing is a difference in the upgrade
approach proposed by Microsoft and the path chosen by companies and people
who are using VB6. This implies that the proposed upgrade path is not
suitable and doesn't work in reality. VB.COM would enable people using VB6
to (1) migrate faster by reducing the gap between VB6 and VB.NET, and to (2)
strongly improve interoperability of VB6 code with VB.NET code, and to (3)
get support for some more years.
In short, what is the underlying reason for the petition? Is it because
VB6 currently contains bugs and it's not fair to make people pay for bug
fixes? (I would agree.)
The answer is yes. But it's not the main reason for the petition. More
information on the support issue can be found here:
<URL:http://msmvps.com/bill/archive/2005/03/13/38347.aspx>
<URL:http://msmvps.com/bill/archive/2005/03/13/38319.aspx>
Or is it because the signers do not agree that Microsoft's suggested
migration approach (a combination of code conversion and COM interop) is
sufficient given the established VB6 code base?
That's a very important reason for the petition. I believe that the
currently suggested migration path is not sufficient. It's still far too
expensive to migrate code, and although the technical infrastructure exists,
tools that make interop easier are missing. VB.COM is the answer to this
issue. By providing the possibility to manage and edit VB.COM projects
side-by-side with .NET projects within the VS IDE, the migration process
would be accelerated. Additionally, by providing further support people
would not be forced to rewrite existing code (which is always a costly
process) and can it without applying changes. The IDE will handle all the
interop for the developer, for example, by automatically generating .NET
wrappers around already existing COM classes.
Or something else?
Yes... Microsoft treats VB differently from its other programming tools.
It treats the VB community in an other way than the VC++, Visual FoxPro,
Visual J++, ... communities by discontinuing a product without providing a
product that evolutionarily extends the existing product without introducing
unneccessary changes which break existing code. VB.NET is a powerful
programming language, but it's not a successor of VB6.
My personal opinion is that much of the heated opposition to the petition
seems to revolve around the perception that the petition's recommended
solution, VB.COM, is overkill. If there is an outcry over the end of
mainstream support, I would think the focus of the related petition would
be to extend the support period until all of the legitiate outstanding
bugs were addressed.
VB6 SP6 has shown that Microsoft isn't really interested in supporting the
use of VB6 any more. VB6 opens more issues than it closes and introduces
several problems (see Bill McCarthy's article I referenced above). VB.COM
is only a suggestion, not a recommendation or a demand. Our experience with
other VB6 customers shows us that VB.COM would have the potential to solve
all the discussed problems.
For me, extending the support period for some more years and providing real
support (a /working/ SP7 that addresses several known bugs) is the /minimum/
I expect Microsoft to do. However, even an SP7 would not address the
migration issue.
Instead, the reminder that mainstream support is ending has prompted a
call for Microsoft to undergo a significant development process to create
what sounds like new major version of VB6.
The message of the petition to Microsoft should be that there needs to be a
change in how Microsoft treats its VB6 customers. It's up to Microsoft to
choose how to address the customer's problems and wishes. The petition
contains a proposed way that represents the best solution we could think of,
which is, giving VB a /future/.
I think it would be fair to call for Microsoft to address known bugs in
VB6, but I don't think it is fair to require the company to enhance and
extend a product that has been stated to be obsolete for quite some time
now.
Reality differes from Microsoft's plan and should cause Microsoft to rethink
the way it has chosen to go with VB6.
To me, the issue comes down to the decision on how Microsoft wants "spend"
its finite human resouces. Yes, they're Microsoft and they can afford
quite a bit, but at some point, you have make a decision on what's worth
it and what isn't. I happen to agree with the school of thought that
enhancing VB6 in the suggested way (VB.COM) is not worth it as it would
steal resources away from further development of VS.NET.
What would you say if a C# developer wants Microsoft to stop further
development of VB.NET and VFP in order to spend the money on C# development?
I feel sorry, but that's a very egoistic point of view that doesn't take
account of the needs and situation of other developers :-(.
I wouldn't put it so bluntly as others, but I can see where people would
think of VB.COM as a move to appease the camp that do not want to move
forward at the expense of those who do. To put it bluntly, I don't want
my new VB.NET features delayed by even a month even if it means that the
lifetime of VB6 will be extended by a year.
As I said in an earlier post: Imagine Microsoft discontinuing C# and
spending all the money on VB.NET development instead. Great idea? There
could be many more features in VB 2005 than there will be in VB 2005 with
Microsoft spending/"wasting" money on further development of C#. VB.COM
would have its own customers like C#, VB.NET, and VFP. Microsoft might have
a separate VB.COM team with separate resources.
I understand that the reality is that there is still a substantial amount
of VB6 code out there that needs to be supported. I just think that what
Microsoft owes the VB6 licensees is system that is bug-free that runs on
the operating systems that were around at the time. I emphatically
disagree with the notion that Microsoft owes the licensees a system that
will be "enhanced and extended" to be campatible with future version of
the Windows.
By discontinuing support for future operating systems, customers' assets
will be lost.
To give a specific example, if a company has developed a VB6 application
which runs on its standard OS build of Windows 98, I would consider it
perfectly reasonable for that company not to upgrade to Windows XP because
of incompatabilities between their app and WinXP.
This only works as long as the machine doesn't access the internet because
when the Windows version you are relying on isn't supported (which means
that bugs don't get fixed) any more, an upgrade will be mandatory.
What is unreasonable, in my opinion, is for that company to demand
that Microsoft continuously add new features to VB6 and to test
it under every new version of Windows that comes out ad infinitum.
Microsoft actually does that for VC++ and Visual FoxPro. There is no reason
not to do that for Visual Basic too.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Keith Seeley" <Keith Se****@discussions.microsoft.com> wrote in message
news:DF**********************************@microsof t.com...
<snip> For the vast majority of programmers that have only known classic VB or
have
never programmed - VB.Net is neither RAD nor simple. I know you'll look
down upon this statement, as you seem to be a very intelligent person,
easily capable of learning and excelling in any programming language that
you should choose. But, you are not the typical classic VB programmer.
Put
aside your talents for a moment and look at the majority of people that
used
and loved classic VB. Try and think of it in terms of why they loved it
and
how VB.Net has changed that for them.
Remember, for most of them, they don't get paid to write code.....they
get
paid to produce results. Classic VB was a RAD tool that frequently made
that easier. For most of them, VB.Net dosen't.
Well, Jim, I must say that you've described the real issue here much
better
than I could have. It may be the MVP's who are speaking the loudest, but
it
is for sure the "99%" of VB "part-time" programmers who are being left out
in
the cold without an easy-to-learn, easy-to-use RAD tool.
VB classic's ability to hide programming complexities on the surface, yet
expose them when needed, made the tool an outstanding choice for a wide
range
of users.
In VB.Net help, "What's new in the Visual Basic Language", this is the
first
sentence:
"Visual Basic 2005 has many new and improved language features - such as
inheritance, interfaces, overriding, shared members, and overloading -
that
make it a powerful object-oriented programming language. As a Visual Basic
developer, you can now create multithreaded, scalable applications using
explicit multithreading. Other new language features in Visual Basic 2005
include loop continuation, guaranteed resource disposal, mixed access
properties, unsigned data types, operator overloading, generic types, and
Common Language Specification (CLS) compliance."
Does this sound like a language that's geared toward RAD? Toward
PRODUCTIVITY? No! This reads like Buzz Word central! Most VBer's DON'T
CARE! We want to get the job DONE, and do it FAST! And if we did care
about
these things, we would do as some of the other posters suggested - use one
of
the other languages! Remember, computers are supposed to make things
EASIER,
not harder!
This .NET future, as I see it, will force most businesses to outsource
simple jobs that were once the mainstay of VB. And the fact that this
will
be a boon for the software industry is no coincidence - if MS's gamble
pays
off, loss of VB classic and growth in VB.Net will no doubt lead to more $
in
MS pockets and an increase in the IT trend to take more money from the
profits of REAL businesses.
Moral of the story - it's small bussinesses, once again, who are being
left
behind and dismissed as insignificant in Microsoft's move toward
"progress".
Exactly.
And those small businesses made up the majority of the classic Visual Basic
army.
This will go down in history as one of the greatest mistakes by a large
business ever.
The problem is that Microsoft did not (and still does not) know their
user-base. Instead of listening to the end-users - not Microsoft employees,
not Microsoft salesmen, managers or even coders. In fact, (not to denegrate
my friends like Herfried) they should not have even listened to their MVPs.
By listening to professional programmers (or pretending to anyway) they gave
the classic Visual Basic community a whole host of new features that 99% of
them neither asked for nor desired. In doing so, they killed classic Visual
Basic and abandoned the legions of lay-programmers that made Visual Basic
such a popular language to begin with.
This is a blunder on the scale of Windows Me.
To make a mistake (even a large one) is no shame. Every person (including
me) and every business (including mine) does so at some time or other. The
true measure of an organization is whether they can realize that they made a
mistake and whether they make strides to rectify it and retain their
customer base and standing in the IT community.
Let's hope Microsoft gets it right, for our sakes and theirs.
Jim Hubbard
(P.S. Although the MVPs have taken the lead in calling for the continuation
of classic Visual Basic - and I sincerely offer my thanks to each one of
them for that - take a look at the signatures being amassed at http://classicvb.org/petition/signatories.asp?lang=en and you will see that
the vast majority of the almost 2,000 signatories are not MVPs. *They* are
Microsoft's customer base. Let's hope Microsoft listens.)
Sorry about the "Buster" moniker above. I was teaching my sister how to use
the newsgroups and didn;t restore my settings.
Jim Hubbard
From an older article in 2002 - http://www.computerworld.com/softwar...,73332,00.html
---------------------------------------
"Reworking the Code
While the cost of scrapping an existing application and building a new one
is substantial, so is just reworking the old code. The cost of a simple
rewrite of a client/server application in VB 6 to VB .Net, without adding
new features, can run as high as 60% of the original cost of the
application, according to Gartner Inc. in Stamford, Conn.
That's because the changes in VB .Net are far more than skin deep. All .Net
programming languages use a common runtime framework. As a result, simple
Visual Basic operations, such as reading and writing a file, must be
reworked to use C++-like semantics. "
....
"But moving legacy programs to VB .Net isn't trivial, Lazar acknowledges. VB
..Net includes an upgrade wizard, but it's intended to be used as a learning
tool; it's not designed to automatically find and convert incompatible code.
"
---------------------------------------
Sad thing is that not much (if anything) has changed.
60% to convert...... Lot's of small businesses just can't afford to spend
60% of all their classic Visual Basic development to move to VB.Net.
If we are going to be force-fed Fred.Net, we need a better migration tool.
Hell, we just need a migration tool - period. For most business projects,
VB.Net only shows you why it can't upgrade - not how, and certainly it
doens't assist in the migration of a great deal of code.
Jim Hubbard
Microsoft wasn't just ignoring a small group of programmers when it trashed
classic Visual Basic......
As this May 2003 article
( http://www.builderau.com.au/program/...0274274,00.htm)
shows, 52% of all programmers surveyed in North America (600 programmers
were surveyed) used Visual Basic for some development.
Wow! It must be nice to be able to ignore 52% of your programmers and know
there's not a damned thing they can do about it.
Well, we could move to Linux. If we have to learn a whole new language, why
not go ahead and cut the cord completely and learn a new OS while we're at
it?
At least we'd have more control over our future than we have now..... We
could even develop our own RAD tool for Linux and never have to worry about
it being taken away.
Why didn't anyone in the Linux world take advantage of this opportunity?
52% of Windows programmers having the best RAD tool ever taken away and over
4,000,000 Visual Basic developers (using classic VB as the primary
development tool) completely abandoned! WOW! What an opportunity!!
Well, we can dream......
Jim Hubbard
One more comment......
Bill Gates is a great businessman. I mean it. He has built the largest
company in the world - and it wasn't just dumb luck.
The greatest lesson that Microsoft tools have taught me (beginning with
Windows 1.0) is that users eat up "dumbed down" products.
He dumbed down the DOS command line using Windows and made a freakin'
fortune! Visual Basic came along and dumbed down programming for the masses
and it became the WORLD's most popular programming language.
That's right, more classic Visual Basic programmers than any other langauge
in the world. Nothing else even came close (including C++ and JAVA).
So, why would Microsoft go in the exact opposite direction and increase the
complexity of the most popular langauge in the world in such a massive way
that it cannot be called a true extention of Visual Basic 6?
Let's see.....you have more programmers than any other language in the
world, and you *abandon* them? NOT cater to them - if even only as a means
to feed Microsoft's ever widening wallet.
If this isn't the craziest thing I have ever seen........
To quote my blog.....
"Microsoft has become like the TV and movie "stars" that we are all so
familiar with today. They live so far removed from everyday reality that it
begins to affect their ability to think rationally. They've surrounded
themselves with people whose very livelyhood depends on being liked enough
to be kept around and given a paycheck for agreeing that the star's every
idea is a stoke of genius.
Then they wind up on the front pages of the tabloids....and we all laugh at
the people we worshipped yesterday.
It's true. Microsoft developers have created their very own Neverland."
Jim Hubbard
> By discontinuing support for future operating systems, customers' assets will be lost.
Playing devil's advocate, this could be a good thing in the long run. In
idle moments, I sometimes dwell on whether there isn't a better way of doing
all of this. Usually when I'm battling with web apps. I'm sure I'm not
alone. But sometimes you have to make a big leap to get there and not small
incremental jumps.
Of course I appreciate the cost of the leap - I work for a small business
after all.
Rob.
Jim,
"Jim Hubbard" <re***@groups.please> schrieb: To quote my blog.....
What's the URL of your blog?
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
On Mon, 14 Mar 2005 23:31:38 +0100, "Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote:
¤ > The petition instead appears to focus on the suggestion that VB6
¤ > should be "enhanced and extended" VB6 in order to extend its lifetime.
¤
¤ That's true. What we are currently facing is a difference in the upgrade
¤ approach proposed by Microsoft and the path chosen by companies and people
¤ who are using VB6. This implies that the proposed upgrade path is not
¤ suitable and doesn't work in reality. VB.COM would enable people using VB6
¤ to (1) migrate faster by reducing the gap between VB6 and VB.NET, and to (2)
¤ strongly improve interoperability of VB6 code with VB.NET code, and to (3)
¤ get support for some more years.
¤
The only problem is that no one has actually identified how code migration from VB 6.0 to VB.NET
will actually be improved. Both versions of Visual Basic function in distinctly separate
environments that are architecturally different. Any IDE interop mechanism between the environments
would be limited to classes and components, and would not be available to stand alone executables.
The bottom line is that you would still ultimately need to rewrite your code. The petition, and
resulting conversations that have ensued, are suggesting a solution that would require enormous
Microsoft resources, a significant amount of time to implement (several years) with an end result
being a postponement of the inevitable.
The better solution is to have Microsoft continue to work on and improve the code migration process
from VB 6.0 to VB.NET, instead of attempting to marry two versions of a product that are almost
eight years apart in development and architecture.
Paul
~~~~
Microsoft MVP (Visual Basic)
Herfried, thank you for your thoughtful reply. I have some further replies,
but first a bit of background on why I (and perhaps others who are critical
of this petition) have the opinions I do. I started programming in BASIC on
a Commodore VIC-20, moved through to QuickBasic, and then onto most versions
of Visual Basic. In short, I have been working with BASIC in one form or
another for a long time and consider it an old friend in many ways. But...I
became so frustrated with the hodgepodge style evolution of VB that I
switched over to Delphi when it became available. The clean OO design that
creating a brand new language allowed appealed to me greatly. But when
VB.NET came out, I immediately switched back to my "old friend". To me,
VB.NET was better than Delphi because it not only had true OO, but also had
all of the familiar syntax and keywords to which I had been accustomed for
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.
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. (The one
case where I did have to go back to using VB6 was agonizing.) From my
perspective, I had moved onto the next level and didn't want to look back.
I may have been lucky in this way, but it sounds like you are forced to deal
on a regular basis with clients who are still using VB6. 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?
If I've read your previous comments correctly, it sounds like the major
issues you have with Microsoft's stance on VB6 is that there won't be any
further service packs to fix existing problems (some of which were
introduced by SP6) and that the COM interop does not work as well as it
should. Personally, I think it is wrong of Microsoft to leave VB6 in a
state where there are known bugs. 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. As for the COM interop, I don't have much need to use this
feature, so I'll take your word that it could be improved.
The point is, I believe far more people would be sympathetic to the call for
better support of VB6 if it were focused on the creation of future service
packs and improved .NET COM interop instead of a major overhaul to VB6 that
is implied by the notion of VB.COM. (I know you mentioned that VB.COM was
only a possible solution, but it features so prominently in the petition,
that one can only assume it is more than a suggestion.) No change as big as
what would be required by VB.COM exists in a vacuum. The costs would be
very large. 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.
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. 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.
The key distinction for me is the difference between the terms "extend" and
"enhance" and the term "fix". In spite of Microsoft's encouragement, the
reality is that there is still a substantial segment of the market out there
that use VB6. But even so, I don't think this means that Microsoft is
obligated to extend and enhance VB6. In my opinion, Microsoft is
responsible to fix known issues with current functionality, not add new
functionality. Again, this may not be the intent of the petition, but based
on my reading of it and some of the other reactions here and in blogs, it
certainly seems like it is.
- Mitchell S. Honnert
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:u3**************@TK2MSFTNGP09.phx.gbl... Mitchell,
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb: I've read the petition and find it a bit ironic that there was no mention
made of the end of "mainstream" support when this is what presumably
triggered the petition in the first place.
We didn't (publically) set an end date for the petition, so maybe it will
continue to be open for signing after March 31. In addition to that the
petition's topic is not limited to VB6, it includes VBA too. The end of
"mainstream" support was not the main force behind starting the petition.
Issues mentioned in the petition are not new and have been discussed for
some years now.
The petition instead appears to focus on the suggestion that VB6
should be "enhanced and extended" VB6 in order to extend its lifetime.
That's true. What we are currently facing is a difference in the upgrade
approach proposed by Microsoft and the path chosen by companies and people
who are using VB6. This implies that the proposed upgrade path is not
suitable and doesn't work in reality. VB.COM would enable people using
VB6 to (1) migrate faster by reducing the gap between VB6 and VB.NET, and
to (2) strongly improve interoperability of VB6 code with VB.NET code, and
to (3) get support for some more years.
In short, what is the underlying reason for the petition? Is it because
VB6 currently contains bugs and it's not fair to make people pay for bug
fixes? (I would agree.)
The answer is yes. But it's not the main reason for the petition. More
information on the support issue can be found here:
<URL:http://msmvps.com/bill/archive/2005/03/13/38347.aspx>
<URL:http://msmvps.com/bill/archive/2005/03/13/38319.aspx>
Or is it because the signers do not agree that Microsoft's suggested
migration approach (a combination of code conversion and COM interop) is
sufficient given the established VB6 code base?
That's a very important reason for the petition. I believe that the
currently suggested migration path is not sufficient. It's still far too
expensive to migrate code, and although the technical infrastructure
exists, tools that make interop easier are missing. VB.COM is the answer
to this issue. By providing the possibility to manage and edit VB.COM
projects side-by-side with .NET projects within the VS IDE, the migration
process would be accelerated. Additionally, by providing further support
people would not be forced to rewrite existing code (which is always a
costly process) and can it without applying changes. The IDE will handle
all the interop for the developer, for example, by automatically
generating .NET wrappers around already existing COM classes.
Or something else?
Yes... Microsoft treats VB differently from its other programming tools.
It treats the VB community in an other way than the VC++, Visual FoxPro,
Visual J++, ... communities by discontinuing a product without providing a
product that evolutionarily extends the existing product without
introducing unneccessary changes which break existing code. VB.NET is a
powerful programming language, but it's not a successor of VB6.
My personal opinion is that much of the heated opposition to the petition
seems to revolve around the perception that the petition's recommended
solution, VB.COM, is overkill. If there is an outcry over the end of
mainstream support, I would think the focus of the related petition would
be to extend the support period until all of the legitiate outstanding
bugs were addressed.
VB6 SP6 has shown that Microsoft isn't really interested in supporting the
use of VB6 any more. VB6 opens more issues than it closes and introduces
several problems (see Bill McCarthy's article I referenced above). VB.COM
is only a suggestion, not a recommendation or a demand. Our experience
with other VB6 customers shows us that VB.COM would have the potential to
solve all the discussed problems.
For me, extending the support period for some more years and providing
real support (a /working/ SP7 that addresses several known bugs) is the
/minimum/ I expect Microsoft to do. However, even an SP7 would not
address the migration issue.
Instead, the reminder that mainstream support is ending has prompted a
call for Microsoft to undergo a significant development process to create
what sounds like new major version of VB6.
The message of the petition to Microsoft should be that there needs to be
a change in how Microsoft treats its VB6 customers. It's up to Microsoft
to choose how to address the customer's problems and wishes. The petition
contains a proposed way that represents the best solution we could think
of, which is, giving VB a /future/.
I think it would be fair to call for Microsoft to address known bugs in
VB6, but I don't think it is fair to require the company to enhance and
extend a product that has been stated to be obsolete for quite some time
now.
Reality differes from Microsoft's plan and should cause Microsoft to
rethink the way it has chosen to go with VB6.
To me, the issue comes down to the decision on how Microsoft wants
"spend" its finite human resouces. Yes, they're Microsoft and they can
afford quite a bit, but at some point, you have make a decision on what's
worth it and what isn't. I happen to agree with the school of thought
that enhancing VB6 in the suggested way (VB.COM) is not worth it as it
would steal resources away from further development of VS.NET.
What would you say if a C# developer wants Microsoft to stop further
development of VB.NET and VFP in order to spend the money on C#
development? I feel sorry, but that's a very egoistic point of view that
doesn't take account of the needs and situation of other developers :-(.
I wouldn't put it so bluntly as others, but I can see where people would
think of VB.COM as a move to appease the camp that do not want to move
forward at the expense of those who do. To put it bluntly, I don't want
my new VB.NET features delayed by even a month even if it means that the
lifetime of VB6 will be extended by a year.
As I said in an earlier post: Imagine Microsoft discontinuing C# and
spending all the money on VB.NET development instead. Great idea? There
could be many more features in VB 2005 than there will be in VB 2005 with
Microsoft spending/"wasting" money on further development of C#. VB.COM
would have its own customers like C#, VB.NET, and VFP. Microsoft might
have a separate VB.COM team with separate resources.
I understand that the reality is that there is still a substantial amount
of VB6 code out there that needs to be supported. I just think that what
Microsoft owes the VB6 licensees is system that is bug-free that runs on
the operating systems that were around at the time. I emphatically
disagree with the notion that Microsoft owes the licensees a system that
will be "enhanced and extended" to be campatible with future version of
the Windows.
By discontinuing support for future operating systems, customers' assets
will be lost.
To give a specific example, if a company has developed a VB6 application
which runs on its standard OS build of Windows 98, I would consider it
perfectly reasonable for that company not to upgrade to Windows XP
because of incompatabilities between their app and WinXP.
This only works as long as the machine doesn't access the internet because
when the Windows version you are relying on isn't supported (which means
that bugs don't get fixed) any more, an upgrade will be mandatory.
What is unreasonable, in my opinion, is for that company to demand
that Microsoft continuously add new features to VB6 and to test
it under every new version of Windows that comes out ad infinitum.
Microsoft actually does that for VC++ and Visual FoxPro. There is no
reason not to do that for Visual Basic too.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Mitchell,
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb: 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.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
> 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]" <hi***************@gmx.at> wrote in message
news:eE**************@TK2MSFTNGP15.phx.gbl... Mitchell,
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb: 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.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Mitchell,
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb: 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.
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".
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?
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.
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.
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>
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
The blog to which I referred is at http://poderthis.blogspot.com/.
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:eh**************@TK2MSFTNGP15.phx.gbl... Jim,
"Jim Hubbard" <re***@groups.please> schrieb: To quote my blog.....
What's the URL of your blog?
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
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
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
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uT**************@TK2MSFTNGP09.phx.gbl... Mitchell,
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb: 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.
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".
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?
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.
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.
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>
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:e0**************@TK2MSFTNGP12.phx.gbl... 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
> 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" <jw***@mvps.org> wrote in message
news:u2*************@TK2MSFTNGP15.phx.gbl...
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:e0**************@TK2MSFTNGP12.phx.gbl...
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
Hi Mitchell
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:ep**************@TK2MSFTNGP14.phx.gbl... 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.
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
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 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.
"Jonathan West" <jw***@mvps.org> wrote in message
news:eP**************@TK2MSFTNGP14.phx.gbl... Hi Mitchell
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:ep**************@TK2MSFTNGP14.phx.gbl... 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.
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" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:uW****************@TK2MSFTNGP15.phx.gbl... 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.
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.
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"?
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.
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 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.
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.
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?
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.
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
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" <jw***@mvps.org> wrote in message
news:Ox**************@TK2MSFTNGP10.phx.gbl...
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:uW****************@TK2MSFTNGP15.phx.gbl... 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.
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.
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"?
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.
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 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.
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.
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?
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.
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" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:OU****************@TK2MSFTNGP14.phx.gbl... 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.
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.
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?
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.
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.
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.
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.
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
>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
"Jonathan West" <jw***@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:OU****************@TK2MSFTNGP14.phx.gbl... 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.
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.
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?
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.
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.
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.
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.
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" <news@honnert~R~E~M~O~V~E~.com> schrieb: 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.
Well, there are already problems when running VB6 applications on Windows XP
which were never fixed and which will be most likely never fixed...
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
>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
"Jonathan West" <jw***@mvps.org> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:OU****************@TK2MSFTNGP14.phx.gbl... 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.
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.
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?
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.
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.
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.
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.
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" <news@honnert~R~E~M~O~V~E~.com> schrieb: 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.
Well, there are already problems when running VB6 applications on Windows XP
which were never fixed and which will be most likely never fixed...
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
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]" <hi***************@gmx.at> wrote in message
news:%2***************@TK2MSFTNGP09.phx.gbl... "Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb: >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.
Well, there are already problems when running VB6 applications on Windows
XP which were never fixed and which will be most likely never fixed...
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
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]" <hi***************@gmx.at> wrote in message
news:%2***************@TK2MSFTNGP09.phx.gbl... "Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb: >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.
Well, there are already problems when running VB6 applications on Windows
XP which were never fixed and which will be most likely never fixed...
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Ray,
"Ray Cassick (Home)" <rc************@enterprocity.com> schrieb: 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.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Ray,
"Ray Cassick (Home)" <rc************@enterprocity.com> schrieb: 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.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:uO****************@TK2MSFTNGP15.phx.gbl... 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.
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
>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" <jw***@mvps.org> wrote in message
news:ey**************@TK2MSFTNGP09.phx.gbl...
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:uO****************@TK2MSFTNGP15.phx.gbl... >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.
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" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... 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.
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.
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.
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
On Fri, 18 Mar 2005 18:10:54 -0500, "Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote:
¤ > Its strange then that C++ has been most carefully managed such that
¤ > Microsoft's own codebase has been protected, to the extent that
¤ > Microsoft's C++ compilers have edged very slowly towards full standards
¤ > compliance. How would you explain that?
¤ To be honest, I don't know enough about C++ to make a judgment. Perhaps you
¤ can tell me: was C++ so much ahead of its time that it didn't *need* the
¤ radical makeover that VB6 received? Did this dramatic change already happen
¤ from C to C++? I honestly don't know.
C++ just had fewer proprietary implementations. But, I think if you talked to some C++ programmers
they would tell you that they have suffered some grief in the past with respect to upgrades. In
addition, C++ *does* have some compatibility issues when using the managed extensions. It isn't the
perfect world that those who don't use the language would lead you to believe, even though they
probably fair much better than Classic Visual Basic developers.
Paul
~~~~
Microsoft MVP (Visual Basic)
> If a reasonable migration path were available, there would be no need to.
And if pigs had wings, they could fly. At this point in the conversation,
the question isn't *if* there is a "reasonable migration path" as you define
it, but *should* there be one as you define it. Sure, if VB.COM existed
right now, many people would find it easier to eventually convert over to
VB.NET. But the question at hand is if Microsoft *should*, either from a
moral or financial standpoint, make VB.COM available The migration path is perfectly do-able. It would (for instance) be a
perfectly feasible project to do a language using most of the VB6 syntax
that compiled to .NET itself.
Just because a project is "do-able" and "feasible", doesn't mean that it's
economically justifiable. Sure, if Microsoft chose to do so, it could
develop VB.COM. But from the very fact that they haven't done so by this
point clearly indicates that Microsoft doesn't believe that such a project
would be the proper use of its resources. They *could* develop VB.COM, they
just don't think it's worth it.
It such a product could still have access to everything in the framework.
There really is ver little about the framework that would necessitate a
difference in behavior - the change in object management from
deterministic finalization to garbage collection is about the only
significant issue.
I somehow think that the implementation of VB.COM would be more than just a
matter of overcoming a couple of insignificant behavior differences between
VB6 and .NET. In fact, much of my opposition to VB.COM arises not so much
out of a sense that Microsoft couldn't do more to support VB6 (they could
and *should*), but from the idea that this approach is overkill. Because
the creation of VB.COM would be such a major undertaking, it would steal
resources away from enhancing the current generation of VB development tool,
VB.NET.
I would accept that, Microsoft does not have an obligation to provide
eternal support for little-used languages. But Visual Basic hardly came
into that category!
I noticed you added the "little-used" qualifier in there. Therein lies the
key to our differences on this particular aspect of the argument. I believe
Microsoft's obligation to support a product, even an application development
tool, is a function purely of time, whereas you apparently believe it should
be a function of usage.
Your key point here seems to be "it doesn't matter how many people are
currently using VB6". In practical terms, that it not true.
Obviously Microsoft doesn't agree with you; they think it *is* true.
It is in Microsoft's own best interest to get the large number of
developers still using VB6 to move to current tools, if only because
Microsoft can make money from selling those tools.
If we're discussing what's in Microsoft's best interest (and no longer about
what they *should* do), then I would still have to disagree. I think that
in Microsoft's mind, they don't have to do much of anything more than what
they've already done and people will eventually switch over to and buy
VS.NET. I don't pretend to know that Microsoft's internal motivation is,
but if I had to guess, I'd say that the whole idea of VB.COM would be viewed
as a bad investment. The expression "Why buy the cow when you can get the
milk for free" comes to mind. In other words, why would Microsoft undertake
a huge project to help people to convert from VB6 to VB.NET when they'll be
forced to do so anyway? From a purely capitalistic viewpoint, not paying
for a huge VB.COM project is in Microsoft's best interest.
- Mitchell S. Honnert
"Jonathan West" <jw***@mvps.org> wrote in message
news:u1**************@TK2MSFTNGP10.phx.gbl...
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... >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.
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.
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.
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
Thanks for the extra info, Paul. As I've said, I'm no expert in C++, but
what you say makes sense on an intuitive level. To me, it seems only
natural that a language that operates on a level closer to the internal
functioning of the computer (C++) would have to change less with a
change/upgrade of the OS. Visual Basic of course hides much of the internal
workings of the computer, so of course it's more susceptible to OS changes.
I'm guessing that there might be a parallel in the C++ world and the VB
world when a new version of Windows is released. Specifically that a VB6
developer might have to port their application to VB.NET or find some other
workaround in order for their application to run on the new OS, whereas the
C++ developer would have to rewrite or update one of their customized
libraries in order to account for the changes in the OS. In both cases,
there could be a significant amount of work, but because it's at the
programming language level with VB6 (instead of the custom library level),
the necessary rework is perceived as more of the "fault" of Microsoft.
Maybe I'm reading too much into the information in your post, but the
scenario I describe sounds plausible.
- Mitchell S. Honnert
"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:ei********************************@4ax.com... On Fri, 18 Mar 2005 18:10:54 -0500, "Mitchell S. Honnert"
<news@honnert~R~E~M~O~V~E~.com> wrote:
¤ > Its strange then that C++ has been most carefully managed such that
¤ > Microsoft's own codebase has been protected, to the extent that
¤ > Microsoft's C++ compilers have edged very slowly towards full
standards
¤ > compliance. How would you explain that?
¤ To be honest, I don't know enough about C++ to make a judgment. Perhaps
you
¤ can tell me: was C++ so much ahead of its time that it didn't *need* the
¤ radical makeover that VB6 received? Did this dramatic change already
happen
¤ from C to C++? I honestly don't know.
C++ just had fewer proprietary implementations. But, I think if you talked
to some C++ programmers
they would tell you that they have suffered some grief in the past with
respect to upgrades. In
addition, C++ *does* have some compatibility issues when using the managed
extensions. It isn't the
perfect world that those who don't use the language would lead you to
believe, even though they
probably fair much better than Classic Visual Basic developers.
Paul
~~~~
Microsoft MVP (Visual Basic)
On Tue, 22 Mar 2005 14:07:11 -0500, "Mitchell S. Honnert"
<news@honnert~R~E~M~O~V~E~.com> wrote: If a reasonable migration path were available, there would be no need to.
And if pigs had wings, they could fly. At this point in the conversation,
the question isn't *if* there is a "reasonable migration path" as you define
it, but *should* there be one as you define it. Sure, if VB.COM existed
right now, many people would find it easier to eventually convert over to
VB.NET. But the question at hand is if Microsoft *should*, either from a
moral or financial standpoint, make VB.COM available
The migration path is perfectly do-able. It would (for instance) be a
perfectly feasible project to do a language using most of the VB6 syntax
that compiled to .NET itself.
Just because a project is "do-able" and "feasible", doesn't mean that it's
economically justifiable. Sure, if Microsoft chose to do so, it could
develop VB.COM. But from the very fact that they haven't done so by this
point clearly indicates that Microsoft doesn't believe that such a project
would be the proper use of its resources. They *could* develop VB.COM, they
just don't think it's worth it.
It such a product could still have access to everything in the framework.
There really is ver little about the framework that would necessitate a
difference in behavior - the change in object management from
deterministic finalization to garbage collection is about the only
significant issue.
I somehow think that the implementation of VB.COM would be more than just a
matter of overcoming a couple of insignificant behavior differences between
VB6 and .NET. In fact, much of my opposition to VB.COM arises not so much
out of a sense that Microsoft couldn't do more to support VB6 (they could
and *should*), but from the idea that this approach is overkill. Because
the creation of VB.COM would be such a major undertaking, it would steal
resources away from enhancing the current generation of VB development tool,
VB.NET.
I would accept that, Microsoft does not have an obligation to provide
eternal support for little-used languages. But Visual Basic hardly came
into that category!
I noticed you added the "little-used" qualifier in there. Therein lies the
key to our differences on this particular aspect of the argument. I believe
Microsoft's obligation to support a product, even an application development
tool, is a function purely of time, whereas you apparently believe it should
be a function of usage.
Your key point here seems to be "it doesn't matter how many people are
currently using VB6". In practical terms, that it not true.
Obviously Microsoft doesn't agree with you; they think it *is* true.
It is in Microsoft's own best interest to get the large number of
developers still using VB6 to move to current tools, if only because
Microsoft can make money from selling those tools.
If we're discussing what's in Microsoft's best interest (and no longer about
what they *should* do), then I would still have to disagree. I think that
in Microsoft's mind, they don't have to do much of anything more than what
they've already done and people will eventually switch over to and buy
VS.NET. I don't pretend to know that Microsoft's internal motivation is,
but if I had to guess, I'd say that the whole idea of VB.COM would be viewed
as a bad investment. The expression "Why buy the cow when you can get the
milk for free" comes to mind. In other words, why would Microsoft undertake
a huge project to help people to convert from VB6 to VB.NET when they'll be
forced to do so anyway? From a purely capitalistic viewpoint, not paying
for a huge VB.COM project is in Microsoft's best interest.
- Mitchell S. Honnert
"Jonathan West" <jw***@mvps.org> wrote in message
news:u1**************@TK2MSFTNGP10.phx.gbl...
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl... >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.
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.
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.
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
I've been following this debate at a distance, surely the whole thing
comes down to economics. Microsoft are not selling any more new VB 6
licenses so there is a zero revenue stream. They have in place a new
tool with a migration path (perhaps not ideal, but it exists)
generating a revenue stream.
A few users want a new migration path, lets do some costing, guesses
only
1) development of new tool 2,000,000
2) testing and QA 500,000
3) marketing 100,000
4) profit 400,000 to make it easy
so we have a total aimed minimum return of 3,000,000
I've seen figures of around 1000 people are demanding this so the
minimum price after corporate discounts needs to be 3,000 are people
going to pay this for a migration tool, probably not enough so the
project doesn't go ahead.
Doug Taylor.
On Tue, 22 Mar 2005 15:31:47 -0500, "Mitchell S. Honnert"
<news@honnert~R~E~M~O~V~E~.com> wrote: Thanks for the extra info, Paul. As I've said, I'm no expert in C++, but
what you say makes sense on an intuitive level. To me, it seems only
natural that a language that operates on a level closer to the internal
functioning of the computer (C++) would have to change less with a
change/upgrade of the OS. Visual Basic of course hides much of the internal
workings of the computer, so of course it's more susceptible to OS changes.
I'm guessing that there might be a parallel in the C++ world and the VB
world when a new version of Windows is released. Specifically that a VB6
developer might have to port their application to VB.NET or find some other
workaround in order for their application to run on the new OS, whereas the
C++ developer would have to rewrite or update one of their customized
libraries in order to account for the changes in the OS. In both cases,
there could be a significant amount of work, but because it's at the
programming language level with VB6 (instead of the custom library level),
the necessary rework is perceived as more of the "fault" of Microsoft.
Maybe I'm reading too much into the information in your post, but the
scenario I describe sounds plausible.
- Mitchell S. Honnert
C++ had an external controlling body setting standards and was a
designed language, VB for all its strengths was a language that had
grown organically and had gone down a number of dead ends.
Perhaps more importantly, Anders Heijlsberg who heads up the .Net
project wanted all four of the mainstream .net languages (c#, C++, VB
and Delphi) to have a basically the same functionality so the common
core would be the same and only the syntax varied. Also Anders was a
founder of Borland and designer of their Pascal and Delphi languages,
so he didn't have any allegience to VB.
VB had to change the most to acheive this end, for example it has gone
from a language (8K Basic) with no typing and global scope, to a
language with strong typing and very tight scope rules.
Doug Taylor
"Paul Clement" <Us***********************@swspectrum.com> wrote in message
news:ei********************************@4ax.com.. . On Fri, 18 Mar 2005 18:10:54 -0500, "Mitchell S. Honnert"
<news@honnert~R~E~M~O~V~E~.com> wrote:
¤ > Its strange then that C++ has been most carefully managed such that
¤ > Microsoft's own codebase has been protected, to the extent that
¤ > Microsoft's C++ compilers have edged very slowly towards full
standards
¤ > compliance. How would you explain that?
¤ To be honest, I don't know enough about C++ to make a judgment. Perhaps
you
¤ can tell me: was C++ so much ahead of its time that it didn't *need* the
¤ radical makeover that VB6 received? Did this dramatic change already
happen
¤ from C to C++? I honestly don't know.
C++ just had fewer proprietary implementations. But, I think if you talked
to some C++ programmers
they would tell you that they have suffered some grief in the past with
respect to upgrades. In
addition, C++ *does* have some compatibility issues when using the managed
extensions. It isn't the
perfect world that those who don't use the language would lead you to
believe, even though they
probably fair much better than Classic Visual Basic developers.
Paul
~~~~
Microsoft MVP (Visual Basic)
"Doug Taylor" <Do************@tayNOSPAMmade.demon.co.uk> wrote in message
news:l1********************************@4ax.com...
I've been following this debate at a distance, surely the whole thing
comes down to economics. Microsoft are not selling any more new VB 6
licenses so there is a zero revenue stream. They have in place a new
tool with a migration path (perhaps not ideal, but it exists)
generating a revenue stream.
A few users want a new migration path, lets do some costing, guesses
only
1) development of new tool 2,000,000
2) testing and QA 500,000
3) marketing 100,000
4) profit 400,000 to make it easy
so we have a total aimed minimum return of 3,000,000
I've seen figures of around 1000 people are demanding this so the
minimum price after corporate discounts needs to be 3,000 are people
going to pay this for a migration tool, probably not enough so the
project doesn't go ahead.
Even assuming your figures for the cost of doing it, I suspect that your
figures for the number of people to whom it could be marketed are way on the
low side.
Already, nearly 4000 people have signed the petition.
According to a Visual Expert survey recently
( http://www.visual-expert.com/us/info...04_results.htm) 80% of VB
developers are still using VB5 or VB6 as their primary version of VB.
Microsoft used to claim that there were 6 million VB developers. Let's
assume for the purpose discussion that 5 million of those are hobbyists who
Microsoft has decided to there is no money to be made out of, and
concentrate on the million writing significant code. According to the
survey, 80% of them are still on VB6, or roughly 800,000 serious developers.
Maybe half of them would pay for and make use of a decent upgrading tool if
one was available. That means there is a market of about 400,000. So, to get
a total return of 3,000,000, Microsoft needs a sales margin per user of
$7.50. I think that is achievable. And in doing so, they would increase the
adoption of modern platforms among the developers and their customers.
Win-win.
--
Regards
Jonathan West - Word MVP www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org
Jonathan, Already, nearly 4000 people have signed the petition.
So accoording too your message have 0.007% of the users signed it
Than is that not really much in my opinion.
When it is that important that they want to pay for it, it would have been
probably much more.
Just my thought,
Cor
Cor,
"Cor Ligthert" <no************@planet.nl> schrieb: Already, nearly 4000 people have signed the petition.
So accoording too your message have 0.007% of the users signed it
Than is that not really much in my opinion.
When it is that important that they want to pay for it, it would have been
probably much more.
Many VB6 developers are not aware of the petition. They do their work 10
hours the day, go home, eat something, watch a football match on TV, and
then go to bed. In other words, they are not active in communities and thus
have not yet heard about the petition. In addition to that, there are very
few VB6-oriented magazines available in the meantime, so VB6 developers are
"disconnected" from each other.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Herfried,
Many VB6 developers are not aware of the petition. They do their work 10
hours the day, go home, eat something, watch a football match on TV, and
then go to bed. In other words, they are not active in communities and
thus have not yet heard about the petition. In addition to that, there
are very few VB6-oriented magazines available in the meantime, so VB6
developers are "disconnected" from each other.
I know your point of view, however as most developers I like it when
somebody shows "facts" to debate that with other "facts".
From the more than probably 12000 messages we did in this newsgroup together
in the last 12 months you should know that I in my idea.
:-)
Cor
While I would certainly agree that there are more people out there that want
a VB.COM-like tool than have signed the petition, I still hold to the idea
that it wouldn't be enough to make it an economically worthwhile proposition
to Microsoft. We can quibble about our cost and profit estimates, but
regardless of what the actual total costs are, it's going to be more than
$0, which is what Microsoft will currently have to spend to get achieve its
target market share for VB.NET without doing *any* more development of VB6.
I know I mentioned this before, but besides the economic issues there is the
issue of the human nature of the average Microsoft employed developer. Any
programmer assigned to the VB.COM project at Microsoft would view this as a
punishment. "What did I do to deserve this? God, why me?"
For so many reasons, VB.COM is just not going to happen.
- Mitchell S. Honnert
"Jonathan West" <jw***@mvps.org> wrote in message
news:u4*************@TK2MSFTNGP12.phx.gbl...
"Doug Taylor" <Do************@tayNOSPAMmade.demon.co.uk> wrote in message
news:l1********************************@4ax.com...
I've been following this debate at a distance, surely the whole thing
comes down to economics. Microsoft are not selling any more new VB 6
licenses so there is a zero revenue stream. They have in place a new
tool with a migration path (perhaps not ideal, but it exists)
generating a revenue stream.
A few users want a new migration path, lets do some costing, guesses
only
1) development of new tool 2,000,000
2) testing and QA 500,000
3) marketing 100,000
4) profit 400,000 to make it easy
so we have a total aimed minimum return of 3,000,000
I've seen figures of around 1000 people are demanding this so the
minimum price after corporate discounts needs to be 3,000 are people
going to pay this for a migration tool, probably not enough so the
project doesn't go ahead.
Even assuming your figures for the cost of doing it, I suspect that your
figures for the number of people to whom it could be marketed are way on
the low side.
Already, nearly 4000 people have signed the petition.
According to a Visual Expert survey recently
(http://www.visual-expert.com/us/info...04_results.htm) 80% of
VB developers are still using VB5 or VB6 as their primary version of VB.
Microsoft used to claim that there were 6 million VB developers. Let's
assume for the purpose discussion that 5 million of those are hobbyists
who Microsoft has decided to there is no money to be made out of, and
concentrate on the million writing significant code. According to the
survey, 80% of them are still on VB6, or roughly 800,000 serious
developers. Maybe half of them would pay for and make use of a decent
upgrading tool if one was available. That means there is a market of about
400,000. So, to get a total return of 3,000,000, Microsoft needs a sales
margin per user of $7.50. I think that is achievable. And in doing so,
they would increase the adoption of modern platforms among the developers
and their customers. Win-win.
--
Regards
Jonathan West - Word MVP
www.intelligentdocuments.co.uk
Please reply to the newsgroup
Keep your VBA code safe, sign the ClassicVB petition www.classicvb.org
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl... While I would certainly agree that there are more people out there that
want a VB.COM-like tool than have signed the petition, I still hold to the
idea that it wouldn't be enough to make it an economically worthwhile
proposition to Microsoft. We can quibble about our cost and profit
estimates, but regardless of what the actual total costs are, it's going
to be more than $0, which is what Microsoft will currently have to spend
to get achieve its target market share for VB.NET without doing *any* more
development of VB6.
I know I mentioned this before, but besides the economic issues there is
the issue of the human nature of the average Microsoft employed developer.
Any programmer assigned to the VB.COM project at Microsoft would view this
as a punishment. "What did I do to deserve this? God, why me?"
For so many reasons, VB.COM is just not going to happen.
- Mitchell S. Honnert
Why don't we do a little experiment?
Why don't we put together an email that you can send to classic VB
developers that you know that tells them about the petition, where to sign
up and asks them to forward the email to friends of theirs who are classic
VB programmers?
This is surely the most efficient method of getting the word out, and should
give us (within a month) a real idea of how many classic VB developers want
a better migration tool and extended support for classic VB.
It should be relatively short and simple. I'll post a suggested message in
a little while.......
Jim Hubbard
I don't know anyone who still programs in VB6 and even if I did, I certainly
wouldn't want to do anything that would encourage them to sign the VB.COM
petition. I personally think that the petition is a bad idea. And even if
I thought it was a good thing, I don't see Microsoft following the
recommendation.
- Mitchell S. Honnert
"Jim Hubbard" <re***@groups.please> wrote in message
news:Ks********************@giganews.com...
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:%2***************@tk2msftngp13.phx.gbl... While I would certainly agree that there are more people out there that
want a VB.COM-like tool than have signed the petition, I still hold to
the idea that it wouldn't be enough to make it an economically worthwhile
proposition to Microsoft. We can quibble about our cost and profit
estimates, but regardless of what the actual total costs are, it's going
to be more than $0, which is what Microsoft will currently have to spend
to get achieve its target market share for VB.NET without doing *any*
more development of VB6.
I know I mentioned this before, but besides the economic issues there is
the issue of the human nature of the average Microsoft employed
developer. Any programmer assigned to the VB.COM project at Microsoft
would view this as a punishment. "What did I do to deserve this? God,
why me?"
For so many reasons, VB.COM is just not going to happen.
- Mitchell S. Honnert
Why don't we do a little experiment?
Why don't we put together an email that you can send to classic VB
developers that you know that tells them about the petition, where to sign
up and asks them to forward the email to friends of theirs who are classic
VB programmers?
This is surely the most efficient method of getting the word out, and
should give us (within a month) a real idea of how many classic VB
developers want a better migration tool and extended support for classic
VB.
It should be relatively short and simple. I'll post a suggested message
in a little while.......
Jim Hubbard
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... I don't know anyone who still programs in VB6 and even if I did, I
certainly wouldn't want to do anything that would encourage them to sign
the VB.COM petition. I personally think that the petition is a bad idea.
And even if I thought it was a good thing, I don't see Microsoft following
the recommendation.
- Mitchell S. Honnert
Whether Microsoft backs down or not, I think it would be good for us and
Microsoft to get as good a count of the classic VB users that are
disappointed in .Net. Then we'd know if we are just a vocal few or if
Microsoft really pissed off millions of VB users.
Maybe Microsoft would at least put more effort into a methodology that would
allow VB6 programs to be upgraded to VB.Net.
Microsoft is (much to their credit) already realizing that they screwed up
the whole RAD feel of VB in VB.Net and are trying to bring some of that back
with VB.Net 2005.
I've got the beta of VB.Net 2005, and I like it MUCH more than VB.Net 2003.
As much as it may seem like I am anti-Microsoft, I most certainly am not.
Microsoft has done more right than it has wrong. It charges too much for
its software and listens to its own developers over its customer base - but
those things can be fixed.
I am very vocal about screw ups - but, isn't that what we're supposed to
do - squeal when we need grease?
I know that (as a business owner myself) I love my customers that point out
where we can be better or where we have changed something that they loved
the way it was...they keep me in line with our customers' needs and wishes.
But, I don't make them scream about it - I actually have a menu item for a
customer to submit a help ticket or to simply submit a "Wish List" of things
they want added to the application.
I am not anti-.Net. I just want the RAD development environment that we
enjoyed with classic VB back and I want to be able to port my old VB
programs more easily so that I can take advantage of the new features
available in the .Net framework. Is that too much to ask?
I am impressed with the improvements in Vb.Net 2005. I can't wait to try
out the full version.
Jim Hubbard
> Whether Microsoft backs down or not, I think it would be good for us and Microsoft to get as good a count of the classic VB users that are
disappointed in .Net.
Well, I guess we still disagree. I think the effort is fruitless.
Microsoft isn't going to go out of its way to find out there is a demand to
do something it doesn't want to do nor thinks would be a bad idea.
Microsoft is (much to their credit) already realizing that they screwed up
the whole RAD feel of VB in VB.Net
Jim, I'll fully admit that this may be a matter of perspective, but I
personally couldn't disagree with you more that Microsoft "screwed up"
anything. I think the exact opposite, in fact. I have some pet peeves with
VB.NET, sure, but on the whole I think they did an incredible job at
improving Visual Basic, including RAD.
and are trying to bring some of that back with VB.Net 2005.
I'd like to get your impressions of VB.NET 05, specifically what features of
VB6 that VB.NET 05 is "bringing back". I tried Beta 1 of VB.NET 05 on my
machine for a bit and while I too was quite impressed with the improvements,
I didn't recognize them as being features of VB6 that didn't make it into
VB.NET. Can you give an example of such a feature? (I'm not denying they
are they; I just didn't notice any.)
- Mitchell S. Honnert
"Jim Hubbard" <re***@groups.please> wrote in message
news:Ef********************@giganews.com...
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...I don't know anyone who still programs in VB6 and even if I did, I
certainly wouldn't want to do anything that would encourage them to sign
the VB.COM petition. I personally think that the petition is a bad idea.
And even if I thought it was a good thing, I don't see Microsoft following
the recommendation.
- Mitchell S. Honnert
Whether Microsoft backs down or not, I think it would be good for us and
Microsoft to get as good a count of the classic VB users that are
disappointed in .Net. Then we'd know if we are just a vocal few or if
Microsoft really pissed off millions of VB users.
Maybe Microsoft would at least put more effort into a methodology that
would allow VB6 programs to be upgraded to VB.Net.
Microsoft is (much to their credit) already realizing that they screwed up
the whole RAD feel of VB in VB.Net and are trying to bring some of that
back with VB.Net 2005.
I've got the beta of VB.Net 2005, and I like it MUCH more than VB.Net
2003.
As much as it may seem like I am anti-Microsoft, I most certainly am not.
Microsoft has done more right than it has wrong. It charges too much for
its software and listens to its own developers over its customer base -
but those things can be fixed.
I am very vocal about screw ups - but, isn't that what we're supposed to
do - squeal when we need grease?
I know that (as a business owner myself) I love my customers that point
out where we can be better or where we have changed something that they
loved the way it was...they keep me in line with our customers' needs and
wishes. But, I don't make them scream about it - I actually have a menu
item for a customer to submit a help ticket or to simply submit a "Wish
List" of things they want added to the application.
I am not anti-.Net. I just want the RAD development environment that we
enjoyed with classic VB back and I want to be able to port my old VB
programs more easily so that I can take advantage of the new features
available in the .Net framework. Is that too much to ask?
I am impressed with the improvements in Vb.Net 2005. I can't wait to try
out the full version.
Jim Hubbard
"Mitchell S. Honnert" <news@honnert~R~E~M~O~V~E~.com> schrieb: I know I mentioned this before, but besides the economic issues there is
the issue of the human nature of the average Microsoft employed developer.
Any programmer assigned to the VB.COM project at Microsoft would view this
as a punishment. "What did I do to deserve this? God, why me?"
Do you think that developers working on Win32/COM code in Windows and most
other Microsoft products see their work the same way?!
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>
Jim,
"Jim Hubbard" <re***@groups.please> schrieb: I don't know anyone who still programs in VB6 and even if I did, I
certainly wouldn't want to do anything that would encourage them to sign
the VB.COM petition. I personally think that the petition is a bad idea.
And even if I thought it was a good thing, I don't see Microsoft following
the recommendation.
[...]
Whether Microsoft backs down or not, I think it would be good for us and
Microsoft to get as good a count of the classic VB users that are
disappointed in .Net. Then we'd know if we are just a vocal few or if
Microsoft really pissed off millions of VB users.
I agree that there are lots of customers who fell really pissed off by what
Microsoft did with VB6, but I doubt that most of them are disappointed by
..NET. .NET has its right to exist, but so does Classic VB.
I know that (as a business owner myself) I love my customers that point
out where we can be better or where we have changed something that they
loved the way it was...they keep me in line with our customers' needs and
wishes. But, I don't make them scream about it - I actually have a menu
item for a customer to submit a help ticket or to simply submit a "Wish
List" of things they want added to the application.
The FAQ to the petition lists the reason why the MVPs who initiated the
petition did this step into the public instead of talking to Microsoft about
this issue again.
I am not anti-.Net. I just want the RAD development environment that we
enjoyed with classic VB back and I want to be able to port my old VB
programs more easily so that I can take advantage of the new features
available in the .Net framework. Is that too much to ask?
No, that's not too much. I think it's a customer's right to give the
manufacturer feedback about products and product lifecycles.
I am impressed with the improvements in Vb.Net 2005. I can't wait to try
out the full version.
Full ACK. But this doesn't solve the VB6 issue.
--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Jim Hubbard |
last post by:
http://www.eweek.com/article2/0,1759,1774642,00.asp
|
by: clintonG |
last post by:
To all Microsoft partners and customers who have been unable to download
recently or access ASP.NET documentation from the msdn2 website and for all
of those customers who have been lied to and...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
