Microsoft MVPs Say They Want Old VB Back

  • Thread starter Thread starter Jim Hubbard
  • Start date Start date
Do you think that developers working on Win32/COM code in Windows and most
other Microsoft products see their work the same way?!
I honestly don't know, but if I had to make a guess, I'd say yes. In other
words, I'm saying that regardless of what language they are using or if what
they are developing is an application or an application development tool,
there is likely a tendency for MS employees to want to work on the "hot" new
product. I think this is just human nature. Because of the stigma of VB
not being for "real programmers", I believe this principle would apply
especially to VB.COM.

- Mitchell S. Honnert
 
Mitchell S. Honnert said:
I honestly don't know, but if I had to make a guess, I'd say yes.

I'd say no. .NET was designed for writing user mode applications; it will
/never/ be used in certain low-level parts (kernel, core libraries) of the
operating systems. In the past few years Microsoft published some clips
showing "Microsofties" at work: Some of them do not even use Microsoft
tools for development.
 
The point I was trying to make related to the application the MS employee
was making, not the tools the employee was using to make it. So, regardless
of whether they were doing their day-to-day work in C++, C#, VB.NET, or some
other non-MS tool, employees would be naturally drawn to projects that were
producing Microsoft's latest "sexy" application.

So, back to the original example, I believe far more programmers at
Microsoft would rather be working on developing Visual Studio .NET 2005 than
Visual Basic .COM. In fact, I would go so far as to say that a collective
lack of enthusiasm at MS for enhancing what is essentially a dead language
(VB6) will play no small part in the failure of the VB.COM petition to
achieve its goals.

People don't want to work on dead-end projects. Why would anyone want to
work on a project to revive a dead (from the standpoint of MS, anyway)
product when they could work on a product that is still in its earlier
stages?

- Mitchell S. Honnert
 
Mitchell,

Mitchell S. Honnert said:
People don't want to work on dead-end projects. Why would anyone want to
work on a project to revive a dead (from the standpoint of MS, anyway)
product when they could work on a product that is still in its earlier
stages?

It's marketing that declares Classic VB a dead programming tool, and VFP, on
the other hand, a tool which will continue to be alive for forseeable
future; there is absolutely no technical reason to dispose the Visual Basic
/programming language/. At the time when Microsoft's marketing will stop
trying to sell customers VB.NET as VB7, Classic VB will be rehabilitated and
I am sure that Microsoft will have an enthusiastic and motivated team for a
new version of Classic VB.
 
It's marketing that declares Classic VB a dead programming tool
Marketing...and the decision to develop VB.NET in the first place.
there is absolutely no technical reason to dispose the Visual Basic
/programming language/.
Who said anything about a technical reason? I think the majority of reasons
that the VB.COM petition will fail have nothing to do with what is
technically possible, but with what is economically justifiable.
At the time when Microsoft's marketing will stop trying to sell customers
VB.NET as VB7, Classic VB will be rehabilitated
I find your insistence on associating VB.NET with "VB7" perplexing. In
point of fact, VB.NET is called VB.NET and not VB7. The only reference to
VB7 that I've ever seen are in the very early stages of development for what
became VB.NET or deep down in some documentation where the marketing weasels
overlooked it. The only way I can see your point making any sense is if MS
did the exact opposite of what it did i.e. called it VB7 instead of VB.NET.
But they didn't. They called it VB.NET. It's a very bad name, but to most
people, the departure from the standard numbered naming convention implied
there is something quite different about VB.NET.

Can you give any examples of MS marketing VB.NET as if it were "VB7"? From
my perspective, MS did everything it could to announce that VB.NET was not
VB7. You couldn't open up a programming magazine without seeing some kind
of article that warned you of this.

- Mitchell S. Honnert
 
Mitchell S. Honnert said:
Marketing...and the decision to develop VB.NET in the first place.

Who said anything about a technical reason? I think the majority of
reasons that the VB.COM petition will fail have nothing to do with what is
technically possible, but with what is economically justifiable.


I find your insistence on associating VB.NET with "VB7" perplexing. In
point of fact, VB.NET is called VB.NET and not VB7. The only reference to
VB7 that I've ever seen are in the very early stages of development for
what became VB.NET or deep down in some documentation where the marketing
weasels overlooked it. The only way I can see your point making any sense
is if MS did the exact opposite of what it did i.e. called it VB7 instead
of VB.NET. But they didn't. They called it VB.NET. It's a very bad name,
but to most people, the departure from the standard numbered naming
convention implied there is something quite different about VB.NET.

Microsoft discontinued VB6 without providing an upgrade path. It doesn't
matter which name Microsoft choose, what matters is that there is a serious
break in compatibility and language stability. If Microsoft would see
VB.NET as a new programming language which is not a "VB7", they would not
have discontinued Classic VB.
Can you give any examples of MS marketing VB.NET as if it were "VB7"?

Microsoft implicitly marketed VB.NET as a "VB7" by obsoleting VB6 and
marketing VB.NET as "the new version", which is technically unsustainable.
From my perspective, MS did everything it could to announce that VB.NET
was not VB7. You couldn't open up a programming magazine without seeing
some kind of article that warned you of this.

Maybe Java FUD magazines would have "warned" people, but for sure no serious
VB magazine.
 
Microsoft discontinued VB6 without providing an upgrade path.
You do your argument a disservice by using these types of easily disprovable
statements. MS may not have provided an upgrade path that was satisfactory
as you define it, but they did provide an upgrade path.
It doesn't matter which name Microsoft choose, what matters is that there
is a serious break in compatibility and language stability.
Of course it matters. It is for the very reason that MS chose to break
compatibility and language stability that they chose a different name. Even
if someone somehow missed the fact that VB.NET was not going to be just VB7
during the MS media blitz before the VS.NET release, the name would indicate
to any rational person that there were major changes afoot.
If Microsoft would see VB.NET as a new programming language which is not a
"VB7", they would not have discontinued Classic VB.
This statement makes no sense to me. MS *does* see VB.NET as a new language
and they *did* discontinue VB6. Isn't that your gripe, that VB.NET is in
effect a different language because it broke language stability? How could
MS not see this? Do you think they created VB.NET and didn't realize they
were breaking language stability?
Maybe Java FUD magazines would have "warned" people, but for sure no
serious VB magazine.
All I can say is that you and I must have had a very different experience
before the release of VB.NET. I read books, magazines, online articles,
anything I could get my hands on about VB.NET and every one of them gave the
warning VB.NET was going to be a major departure from VB6. We were told
again and again how most existing VB6 systems should probably be left in VB6
and that new systems be developed in VB.NET. In fact, I remember becoming
frustrated with the repetition of this general statement. I was looking for
new information and all I found was different sources regurgitating this
warning and other similar duplicated information. I don't know what your
experience was, but I not only knew Microsoft was dumping VB6, I was beaten
over the head with it.

- Mitchell S. Honnert
 
Sorry to jump in off-topic, but I couldn't help it after you mentioned the
HP 1000 E-series. I did a lot of my early programming work on that platform,
and to be honest, I still miss it sometimes. Of course, it helped that we
had at the time a tremendously supportive and helpful HP representative who
worked closely with us to make sure we had everything we needed. HP was
quite a company back then.

Thanks again for bringing back some good memories. Maybe I need to join the
military just so I can work on that platform again. :)

May not be a long career, if you want to stay close to the hardware,
there is one in each wing of a cruise missile, so you may only last
one flight. Ah the joys of real time programming.
 
Hi Doug,




Its a matter of scale & proportion. Microsoft made the change from VB6 to
VB.NET when it was their most popular programming environment, and without
making it practicable to convert a large proportion of the projects written
using VB6

Had VB6 been little used, or only a small proportion of projects taken a
significant effort to migrate, then your comparisons whould have been valid.

So not many people use cars with leaded fuel, well in the UK it was
around 60% of vehicles were originally supplied to run on leaded fuel,
and around 95% of viewers to terrestial television use analogue, so I
feel it is a very good analogy.

Doug Taylor
 
Doug,



All of the three options are not viable -- that's why the petition exists.


Delphi was tied to Win32/COM too. Other manufacturers wrote compilers which
could create and consume COM components. I don't see such a big difference
between COM and .NET from this point of view.
Delphi Win16/32/64 but not tied to COM at all, you could use COM, but
most developers used the Borland Framework, which surprise surprise is
very similar to the .Net framework. Well not really a surprise at it
had the same author.

Also you could port programs to Kylix with about the same difficulty
as porting VB6 to .Net, i.e. it depends on the coding techniques used
in the first place.
 
Mitchell S. Honnert said:
You do your argument a disservice by using these types of easily
disprovable statements. MS may not have provided an upgrade path that was
satisfactory as you define it, but they did provide an upgrade path.

Like Enron provided an investment vehicle for seniors.
Of course it matters. It is for the very reason that MS chose to break
compatibility and language stability that they chose a different name.
Even if someone somehow missed the fact that VB.NET was not going to be
just VB7 during the MS media blitz before the VS.NET release, the name
would indicate to any rational person that there were major changes afoot.

Dude! Per Microsoft......"Visual Basic .NET, the latest version of the
world's most popular development tool and language. Visual Basic .NET
delivers unsurpassed productivity and unique language features for
task-oriented developers building solutions with the .NET Framework."
(http://msdn.microsoft.com/vstudio/productinfo/whitepapers/default.aspx) In
all previous versions, backwards compatability was kept as much as possible
and upgrading your applications meant a day or 2 of coding at most.

With "the latest version of the world's most popular development tool and
language" there was no reason that any "rational person" would conclude that
this "latest version of the world's most popular development tool and
language" would not continue the tradition of Visual Basic's historical
releases.

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

I'm reading that as "this is another version of Visual Basic". If you
don't, change your medication.
This statement makes no sense to me. MS *does* see VB.NET as a new
language and they *did* discontinue VB6. Isn't that your gripe, that
VB.NET is in effect a different language because it broke language
stability? How could MS not see this? Do you think they created VB.NET
and didn't realize they were breaking language stability?

See Microsoft's statements quoted above........
All I can say is that you and I must have had a very different experience
before the release of VB.NET. I read books, magazines, online articles,
anything I could get my hands on about VB.NET and every one of them gave
the warning VB.NET was going to be a major departure from VB6.

So, you didn't read the Microsoft stuff?
We were told again and again how most existing VB6 systems should probably
be left in VB6 and that new systems be developed in VB.NET.

Really? Any Microsoft links for that?
In fact, I remember becoming frustrated with the repetition of this general
statement. I was looking for new information and all I found was different
sources regurgitating this warning and other similar duplicated
information. I don't know what your experience was, but I not only knew
Microsoft was dumping VB6, I was beaten over the head with it.

Links would help here.

Even better, it would help us all if Microsoft cared to send email directly
to it's customer base concerning their products (like Visual Basic) instead
of leaving us to find obscurre web pages or press releases. Why don't they
do that? We did register the software. They have our email addresses. If
we use it for programming, wouldn't we want to be included in it's
evolution......or at least be notified of it?

Jim Hubbard
 
Doug Taylor said:
May not be a long career, if you want to stay close to the hardware,
there is one in each wing of a cruise missile, so you may only last
one flight. Ah the joys of real time programming.

Thanks for the information. One in each wing of a cruise missile? That's
interesting. I think I'll do more research on that.

Carl Rapson
 
Doug Taylor said:
So not many people use cars with leaded fuel, well in the UK it was
around 60% of vehicles were originally supplied to run on leaded fuel,
and around 95% of viewers to terrestial television use analogue, so I
feel it is a very good analogy.

A more proper analogy would be making the roads thinner (i.e. OS) so that
your old car would not fit on the new streamlined (thinner) streets, and
adding a cargo bay that only accepts packages wrapped in a new space-aged
polymer.

Neither of these things are a real problem.......unless you do deliveries
for a living.

Jim Hubbard
 
Mitchell,



It's marketing that declares Classic VB a dead programming tool, and VFP, on
the other hand, a tool which will continue to be alive for forseeable
future; there is absolutely no technical reason to dispose the Visual Basic
/programming language/. At the time when Microsoft's marketing will stop
trying to sell customers VB.NET as VB7, Classic VB will be rehabilitated and
I am sure that Microsoft will have an enthusiastic and motivated team for a
new version of Classic VB.

At the time Microsoft's marketing try and stop selling visual studio
2002 vb.net, they will have moved on to marketing 2005, they will not
allow a product that will confuse their message to marketed along
side.

Have you considered what the developers consigned to this dead end
project will think of it in terms of enhacing their career
aspirations. Yes there maybe a number of developers in their late
50's who will be happy to fill in to retirement, (speaking as a
programmer whose first program ran on a valve based computer) but I
doubt many on the up slope of their careers will be happy.

I would have thought your best bet for a classic VB or vb.com would be
to try and persuade Microsoft to put VB6 code into the public domain
and try a Linux style diffused development project to produce it, then
it may well achieve what you want.

Doug Taylor
 
Doug Taylor said:
At the time Microsoft's marketing try and stop selling visual studio
2002 vb.net, they will have moved on to marketing 2005, they will not
allow a product that will confuse their message to marketed along
side.

Have you considered what the developers consigned to this dead end
project will think of it in terms of enhacing their career
aspirations. Yes there maybe a number of developers in their late
50's who will be happy to fill in to retirement, (speaking as a
programmer whose first program ran on a valve based computer) but I
doubt many on the up slope of their careers will be happy.

I would have thought your best bet for a classic VB or vb.com would be
to try and persuade Microsoft to put VB6 code into the public domain
and try a Linux style diffused development project to produce it, then
it may well achieve what you want.

If Microsoft would simply provide a more viable upgrade tool, I think we'd
all be happy to move on.

One click upgrades (or at least something close to it......)......that's all
we need. Then we could focus on enhancing our code to take advantage of
..Net's new features and NOT on rewriting our entire codebase.

Jim Hubbard
 
Like Enron provided an investment vehicle for seniors.
Touché! :-) I guess the point you are trying to make is that the
Microsoft's suggested "upgrade path" is so unsatisfactory as to not be
considered an upgrade path at all. *My* point is that there are enough
people who agree that it *is* satisfactory, that one cannot support
categorical statements like the one Herfried made.
Dude! LOL.

Per Microsoft......"Visual Basic .NET, the latest version of the world's
most popular development tool and language.
You apparently read a whole lot into that word "version". I take it that
you believed it indicated in absolute terms that VB.NET would have
compatibility and language stability with VB6. I didn't. Especially with
all that was being written about VB.NET at the time.
So, you didn't read the Microsoft stuff?
Yes, I read Microsoft's stuff, but I didn't rely on it *exclusively*. I
don't know what you did, so I can't say if this applies, but anyone who
relied purely on the MS marketing weasels in their business decisions
regarding VB.NET was seriously lacking in the due diligence department. The
companies I worked for didn't just read MS press releases and wait for MS to
send them e-mails. They went out and did research to find out what the
industry thought of this new thing called "VB.NET".

I can understand that there are people that are angered that VB.NET breaks
language stability, but I don't see how anyone would have been *surprised*
by this. When did you discover this? I'm getting the impression that you
loaded up the release version of VB.NET for the first time and only then
discovered that language stability had been broken.

- Mitchell S. Honnert
 
If Microsoft would simply provide a more viable upgrade tool, I think we'd
all be happy to move on.
What? If the petitioners would be happy with a more "viable upgrade tool",
why are they asking for VB.COM, something that would be monumentally more
expensive to develop? Are they using the bartering technique of asking for
way more than you know you'll get so after the haggling is done, you'll get
what you really wanted in the first place?

One of the major flaws that I see with the petition is that there is a
significant disconnect between what the stated problems are and the proposed
solution. I don't think the petition would have been controversial (or
newsworthy, for that matter) if all it was asking for was a new or better
tool to help with upgrading VB6 code to VB.NET. I would certainly agree
that the current user-base of VB6 would warrant a better conversion tool.
But that's not what the petition is asking for. Instead of an mere upgrade
tool, the petition is asking for VB.COM, a major enhancement to the existing
Visual Studio environment. It's not that I don't agree that there is a
problem, it's just that the proposed solution is overkill.
One click upgrades (or at least something close to it......)......
that's all we need.
Being that "one-click upgrades" from VB6 to VB.NET are all but impossible,
I'm guessing you aren't going to get what you are asking for. I don't think
even the third party tools that do this kind of conversion promise one-click
upgrades or even "something close".

- Mitchell S. Honnert
 
Mitchell S. Honnert said:
What? If the petitioners would be happy with a more "viable upgrade
tool", why are they asking for VB.COM, something that would be
monumentally more expensive to develop?

I think they are asking for VB.COM as an intermediary tool....a stepping
stone that would bridge the compatability issues of VB6 and VB.Net - a tool
that would allow us to keep the VB6 code alive and well, while beginning to
integrate the new features of VB.Net.....you know, exactly what the C/C++
programmers got in the new Visual Studio .Net.

This could have been done with VB.Net. Microsoft saw fit to allow C and C++
code to be able to be compiled within the Visual Studio IDE, but not Visual
Basic. Why not?

Could it be that Visual Basic could not be added because of technical
incompatabilities? Hardly. Adding the ability to write Visual Basic 6 code
from within the IDE has nothing to do with the framework......just as older
C++ code (that CAN be used in the new Visual Studio IDE) needs no changes to
be able to be edited and compiled in the new IDE.

This was a choice. A choice to abandon the largest group of programmers in
the world.
Are they using the bartering technique of asking for way more than you know
you'll get so after the haggling is done, you'll get what you really wanted
in the first place?

I don't think so. If I understand things correctly, VB.COM would be an IDE
that integrated both VB6 and VB.Net features while fixing known VB6 issues.
in other words, something that should have been a part of VB.Net. I don't
think there would be any objection to making VB.Net actually import AND RUN
Visual Basic 6 code in the current Visual Studio IDE.
One of the major flaws that I see with the petition is that there is a
significant disconnect between what the stated problems are and the
proposed solution. I don't think the petition would have been
controversial (or newsworthy, for that matter) if all it was asking for
was a new or better tool to help with upgrading VB6 code to VB.NET. I
would certainly agree that the current user-base of VB6 would warrant a
better conversion tool. But that's not what the petition is asking for.
Instead of an mere upgrade tool, the petition is asking for VB.COM, a
major enhancement to the existing Visual Studio environment. It's not
that I don't agree that there is a problem, it's just that the proposed
solution is overkill.

I don't agree. What they are asking for in VB.COM is exactly what the C/C++
programmers got in Visual Studio .Net.
Being that "one-click upgrades" from VB6 to VB.NET are all but impossible,
I'm guessing you aren't going to get what you are asking for. I don't
think even the third party tools that do this kind of conversion promise
one-click upgrades or even "something close".

Based on the Microsoft Visual Basic track record, upgrading from one version
of VB to the next has never been "one-click", but has been significantly
simpler than the current, unacceptable upgrade path provided for VB.Net.

I don't really expect a "one-click" upgrade, but that should be the goal.

Jim Hubbard
 
Mitchell S. Honnert said:
Touché! :-) I guess the point you are trying to make is that the
Microsoft's suggested "upgrade path" is so unsatisfactory as to not be
considered an upgrade path at all. *My* point is that there are enough
people who agree that it *is* satisfactory, that one cannot support
categorical statements like the one Herfried made.

We could go back and forth on this all day. What we need are hard numbers.
You apparently read a whole lot into that word "version". I take it that
you believed it indicated in absolute terms that VB.NET would have
compatibility and language stability with VB6.

I did.....at least to the extent that VB6 was backwards compatible with VB5
code and to the extent that the VB5 code would upgrade to VB6.
I didn't. Especially with all that was being written about VB.NET at the
time.

I was too busy listening to Microsoft. Thought they knew their product and
customers. My bad.
Yes, I read Microsoft's stuff, but I didn't rely on it *exclusively*. I
don't know what you did, so I can't say if this applies, but anyone who
relied purely on the MS marketing weasels in their business decisions
regarding VB.NET was seriously lacking in the due diligence department.
The companies I worked for didn't just read MS press releases and wait for
MS to send them e-mails. They went out and did research to find out what
the industry thought of this new thing called "VB.NET".

I jumped on the very first .Net beta. And, I did look around...plenty.
But, I have to admit that I tend to rely on the details of a new project as
released by the project's team. In this case, that was the Microsoft .Net
team.
I can understand that there are people that are angered that VB.NET breaks
language stability, but I don't see how anyone would have been *surprised*
by this. When did you discover this? I'm getting the impression that you
loaded up the release version of VB.NET for the first time and only then
discovered that language stability had been broken.

No. I have been playing with VB.Net since the first beta. However, I am
still being hired by companies that have tons of VB6 code that will no
longer be supported on the new OS platforms.

Given the VAST amount of code written in (what Microsoft agrees) is the most
prolific programming language in the world, breaking backwards compatability
with classic Visual Basic (with no real upgrade path) is tantamount to
breaking C++ code for Microsoft. The only reason it didn't happen to C++ is
because the team developing Visual Studio .Net were C++ programmers and
would never stand for breaking all of their own code.

Regardless of the fact that there are more classic Visual Basic programmers
in the world than ANY other language, the C++ developers in charge of Visual
Studio .Net decided to continue the myth/religious code mantra that classic
Visual Basic was not a "real programming language". Nevermind that it is
the core developing language of your company's largest group of developers.

These "professional" developers did not take classic Visual Basic seriously,
or Microsoft's classic Visual Basic customers. Combine that with the
internal deadlines that they must have been under, just maybe they chose to
trash classic Visual Basic to save their own hides.

This doesn't take a psychic to figure out..... Microsoft's Visual Studio
team took care of their own interests above the interests of their largest
developer customer base. Visual Studio .Net is all about Microsoft. Not
you. Not me. Just them.

In choosing between taking care of the customer and covering their ass and
promoting their own agenda, Microsoft cut the customers loose.

I say, while you're loose......RUN!

Jim Hubbard
 
This could have been done with VB.Net. Microsoft saw fit to allow C and
C++ code to be able to be compiled within the Visual Studio IDE, but not
Visual Basic. Why not?
Maybe it was because C++ wasn't screwed up like VB6 was. Maybe MS didn't
want the taint of VB6 at all associated with their next-generation
application development tool. I've stated before that VB6 was a great tool
for the time, but by today's standards it's crap. I don't know C++, but my
assumption was that it was OK the way it was, whereas VB was long overdue
for a major overhaul.
I don't think so. If I understand things correctly, VB.COM would be an
IDE that integrated both VB6 and VB.Net features while fixing known VB6
issues. in other words, something that should have been a part of VB.Net.
I think your statement above is evidence of the mixed signals in the
petition. The petition is calling for a major upgrade to VB6 and yet you
say that "we'd" be happy with just a better upgrade tool. (I don't think
you are using the royal "we", so I'm assuming you are speaking on behalf of
the petitioners.) The conclusion I draw from this is that petitioners don't
really want to address the problems stated in the petition itself, but the
unstated "problem" that they think VB.NET should never have been developed
in the first place.
I don't agree.
Which part of what I said don't you agree with? That a better upgrade tool
wouldn't solve the problems stated in the petition? That VB.COM would be a
major undertaking?
What they are asking for in VB.COM is exactly what the C/C++ programmers
got in Visual Studio .Net.
I've heard this argument used several times and I have the same response
every time. Just because VS.NET's support of C/C++ is in principle the same
as a theoretical support for VB6 in VS.NET it doesn't mean that it makes
economic sense to invest in this development. To use an analogy I've used
before, if I already have a mortgage, the principle of getting a loan to buy
a house is the same, but that doesn't mean I can buy *another* house. So,
just because Microsoft felt it was a good investment to incorporate C/C++
into VS.NET doesn't mean that (especially so far after the fact) it would be
a good investment (from their perspective) to do it for VB6.

I happen to think one of the biggest reasons that C/C++ was supported in
VS.NET and not VB6 is related to Doug's original point about VB.COM being a
"dead-end project". In practical terms, VB6 wasn't incorporated into the
original version of VS.NET (nor will it be with VB.COM) for the simple
reason that MS programmers themselves use C/C++ more than VB. Too many
programmers would have viewed being assigned to the "VB6.NET" as a one-way
ticket to professional oblivion. "Oh, so you worked on the VB6.NET project,
eh? That's nice. Next!"

- Mitchell S. Honnert
 
Back
Top