If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Microsoft's C++ bigotry

"Why should C++ developers enjoy such ease of migration to .NET, while VB
developers (of whom there are arguably many more) are forced to rewrite
their code?...The message seems clear: If your application is
'mission-critical', don't use VB." --http://www.philweber.com/net/2003/01/14.htm#a40

Re: Microsoft's C++ bigotry

Phil,

a lot of us have been saying things like this for a long time. Where have
you been? Microsoft's attitude towards VB have clearly made it a less popular
choice in the market place. You can see it in the lack of VB jobs that are
currently out there.

Microsoft cares only about it's own interests. They have a ton of C and
C++ code, so if .Net is to be taken seriously, they have to make it as easy
as possible to port their own code. Not to mention that the flexibility
of C plays into it a bit as well. C++ is an extremely flexible language
while VB6 (may it rest in peace) was not.

Re: Microsoft's C++ bigotry

> A lot of us have been saying things like this for a
> long time. Where have you been?

Kent: I've been here. But unlike many of "you," I'm neither anti-VB nor
anti-Microsoft. I actually use and like VB.NET, and I don't think VB.NET's
lack of VB6-compatibility is as serious a problem as many critics portray it
to be. I'm hoping that perhaps my more moderate position will get a few more
people to hear what I'm saying.
--
Phil Weber

Re: Microsoft's C++ bigotry

"Phil Weber" <pweber@nospam.fawcette.com> wrote
> > A lot of us have been saying things like this for a
> > long time. Where have you been?
>
> Kent: I've been here. But unlike many of "you," I'm neither anti-VB nor
> anti-Microsoft. I actually use and like VB.NET, and I don't think VB.NET's
> lack of VB6-compatibility is as serious a problem as many critics portray it
> to be. I'm hoping that perhaps my more moderate position will get a few more
> people to hear what I'm saying.

Its not very likely that your statements will do anything to change the
current situation, or other people's perception of it. As Karl stated,
these facts have been out for years.

My take on it is that, like Assembly, C++ is at such a level that unless the
underlying hardware architecture changes, the concepts and structures used
in C++ will be supported no matter what other layers MS adds to the mix.
It is simply uneffected by MS's own C++ code that they use to pile on their
flavor of the month.

VB on the other hand, was dependant on MS's VB runtime layer originally,
and got progressively more involved as MS added layer upon layer, feature
upon feature, to core Windows processes.

All that 'fluff' is still present, as you know, VB6 still works, but I think MS
has positioned VB.Net to be less dependant on changes to any Windows
features, and soley dependant on the same things they need for their own
C# code. That will, in effect, help to make the language more resistant
to future change. But, to get there, they had to start from concepts that
do not conflict with the flow of operation on today's hardware. Rather
than shoehorn in old concepts that may yet break down the road, I think
their strategy was to use conepts more inline with C++ / C# so that they
can keep this new VB.Net backward compatable (to VB.Net) for as
long as they expect C# to remain backward compatable.

While that bodes well for future developers and development, current
developers are left nearly high and dry, forced to switch or maintain
old code, or both, mixing the two in their attempt to make the transition.

If you admit that it is pie in the sky for developers to think that their code
will last forever, how is it you do not recognise when well worn code
has come to the end of its useful cycle? As a lanuage, you'd like it to live
on, but as an application, it simply cannot. The time has come for a
rewrite to addresss the new concepts that were not even dreamed of, at
its conception.

You just gotta wonder what goes on behind the scenes when Intel tries
to suggest the same things about their own architectures and languages
for the CPU's they manufacture. I'd be willing to bet MS would use
all of its muscle to keep Intel from making the same types of drastic
changes MS is forcing on their customers. But for Intel, Microsoft,
and everybody else, its the same underlying golden rule; When money
talks, people listen.

So, the way I see it, VB.Net will be an even better language for future
developers, (in terms of both capablilities and (Dan's) stability) even if
the current crowd has to suffer through a few hardships.

Re: Microsoft's C++ bigotry

I'm pro VB just not VB.Net and I used to wave the Microsoft flag as high as
any of "you" did. But for reasons you've already point, I've burned that
flag in the street. Too bad CNN wasn't there to see it. it's not that Microsoft
are C++ bigots, they simply have their own interests at heart and could give
a hoot less about yours or mine.

You seem to think that "we" are blowing the whole thing out of proportion?
I beg to differ. Maybe you can tell me does Microsoft have to completely
rewrite office every 10 years? Isn't it time for a complete rewrite of windows?
(yes it is, but I won't go there).

A software company should be able to keep it's application relevant using
the latest features of the OS through the programming tools that they use.
This will no longer be possible using VB6 and for those companies that produce
shrink wrap products stability is a must. It IS NOT ACCEPTABLE to have drastic
changes to the development tools.

You think if Microsoft were not in complete control of Windows and someone
changed the platform and developement tools they use to the extent VB was
changed they would not be pissed off? They need their C and C++ code to
be easily ported to .Net, that should be answer enough for you. The rest
of us are not so lucky.

I would hope your observation of their favor of C++ would be warning to you
of what changes may come next, as history tends to repeat it's self.

"Phil Weber" <pweber@nospam.fawcette.com> wrote:
> > A lot of us have been saying things like this for a
> > long time. Where have you been?
>
>Kent: I've been here. But unlike many of "you," I'm neither anti-VB nor
>anti-Microsoft. I actually use and like VB.NET, and I don't think VB.NET's
>lack of VB6-compatibility is as serious a problem as many critics portray
it
>to be. I'm hoping that perhaps my more moderate position will get a few
more
>people to hear what I'm saying.
>--
>Phil Weber
>
>

Re: Microsoft's C++ bigotry

Kent wrote:
> You seem to think that "we" are blowing the whole thing out of
> proportion? I beg to differ. Maybe you can tell me does Microsoft
> have to completely rewrite office every 10 years?

Is Office 10 years old yet?. [The answer is "no" btw, whatever the
software. You rewrite when you need to.]
> Isn't it time for
> a complete rewrite of windows? (yes it is, but I won't go there).

DOS->Win9x->WinNT. Major/complete rewites. Enough for your you?
> A software company should be able to keep it's application relevant
> using the latest features of the OS through the programming tools
> that they use. This will no longer be possible using VB6 and for
> those companies that produce shrink wrap products stability is a
> must.

So change the tool. The OS has thefeatures but the tool is outdated. How
many people are still using VB1? VB4?
> It IS NOT ACCEPTABLE to have drastic changes to the
> development tools.

On the contrary. It is necessary that dev tools evolve to be relevant. Every
so often, the change will be drastic or the tool might become irrelevant.
> You think if Microsoft were not in complete control of Windows and
> someone changed the platform and developement tools they use to the
> extent VB was changed they would not be pissed off? They need their
> C and C++ code to be easily ported to .Net, that should be answer
> enough for you. The rest of us are not so lucky.

Most of MS's code wouldn't "port" to .NET. It would continue to compile and
run as unmanaged code with VS.NET. MC++ doesn't magically convert legacy C++
code to .NET assemblies.
> I would hope your observation of their favor of C++ would be warning
> to you of what changes may come next, as history tends to repeat it's
> self.

Re: Microsoft's C++ bigotry

Kent, you seem to be missing the point... Only joking

The differences between VB6 and VB.NET are enormous, and most of the [VB
using] verbose people in this group seem to be split into three main
clusters:
1. Those who swear VB.NET is brilliant and deny that it is difficult to pick
up, defending its every nuance
2. Those who love VB6 and swear at VB.NET, claiming it should never have
existed
3. Those who approve VB.NET for its improvements over VB6, and accept that
major changes were necessary

I fall into cluster 3, although I am particularly critical of Microsoft in
that they did not give more helpful tools for the migration process, such as
the promised code snippet utility (where you type in a VB6 command and it
suggests the .NET equivalent) or some decent help files aimed at the
developers (the search system in .NET help absolutely sucks).
I suspect that the development community would have been happier to have
seen VB6 dropped and only C# specified as the new language, because this
would be a _total_ design methodology shift instead of this almost false
similarity to VB6.
My sympathies go out to all VB6 developers who do not have prior Java or C++
experience, because the .NET transition is a very hard one, but I disagree
that it is 'unacceptable' to have major language changes. Core VB6 was a
tiny part of the VB environment, and most of the functionality used was in
COM objects included as references. ADO, networking, 3rd party controls,
scripting, and a myriad of other commonly used functions were in these
addons, and these have been replicated with different syntax into the .NET
library.
The biggest pain in VB6 code conversion is that we all tended to write such
apalling VB6 code! It was so easy to quickly knock up an initial solution,
then spend days or weeks modifying it to give a quality looking application.
If we had to scrap it and restart we know that we could write it in half the
code, and make it more maintainable, but with VB6 we don't have to do that.
When we try to port that code to a VB.NET environment we have terrible
problems, yet if we had used VB.NET in the first place we would probably
have been forced to do more planning and developed a more structured
solution the first time. This is something that Java and C++ developers are
used to, but VB developers are not. Now we are forced to adopt the same
design constraints, so what VB developers considered 'RAD' (i.e. don't plan,
just drag, drop & bodge) is no longer a viable option.
Is this good or bad? I reckon that 80%+ of VB6 developers will require
extensive relearning to be able to do this, and this is not good for
industry. Perhaps MS should have retained VB6 but put in place more
'incentives' to move over, such as free additional controls or wizards that
developers and/or companies would be attracted to. From teaching and
consulting I know how much experience most industry VB6 developers have, and
I can say that most would (and are) struggling terribly to get to grips with
VB.NET.

Cheers,
Jason

"Kent" <kp@kp.com> wrote in message news:3e2614e7$1@tnews.web.devx.com...
>
> I'm pro VB just not VB.Net and I used to wave the Microsoft flag as high
as
> any of "you" did. But for reasons you've already point, I've burned that
> flag in the street. Too bad CNN wasn't there to see it. it's not that
Microsoft
> are C++ bigots, they simply have their own interests at heart and could
give
> a hoot less about yours or mine.
>
> You seem to think that "we" are blowing the whole thing out of proportion?
> I beg to differ. Maybe you can tell me does Microsoft have to completely
> rewrite office every 10 years? Isn't it time for a complete rewrite of
windows?
> (yes it is, but I won't go there).
>
> A software company should be able to keep it's application relevant using
> the latest features of the OS through the programming tools that they use.
> This will no longer be possible using VB6 and for those companies that
produce
> shrink wrap products stability is a must. It IS NOT ACCEPTABLE to have
drastic
> changes to the development tools.
>
> You think if Microsoft were not in complete control of Windows and someone
> changed the platform and developement tools they use to the extent VB was
> changed they would not be pissed off? They need their C and C++ code to
> be easily ported to .Net, that should be answer enough for you. The rest
> of us are not so lucky.
>
> I would hope your observation of their favor of C++ would be warning to
you
> of what changes may come next, as history tends to repeat it's self.
>
> "Phil Weber" <pweber@nospam.fawcette.com> wrote:
> > > A lot of us have been saying things like this for a
> > > long time. Where have you been?
> >
> >Kent: I've been here. But unlike many of "you," I'm neither anti-VB nor
> >anti-Microsoft. I actually use and like VB.NET, and I don't think
VB.NET's
> >lack of VB6-compatibility is as serious a problem as many critics portray
> it
> >to be. I'm hoping that perhaps my more moderate position will get a few
> more
> >people to hear what I'm saying.
> >--
> >Phil Weber
> >
> >

Re: Microsoft's C++ bigotry

<snip>
> All that 'fluff' is still present, as you know, VB6 still works, but I
think MS
> has positioned VB.Net to be less dependant on changes to any Windows
> features, and soley dependant on the same things they need for their own
> C# code. That will, in effect, help to make the language more resistant
> to future change. But, to get there, they had to start from concepts that
> do not conflict with the flow of operation on today's hardware. Rather
> than shoehorn in old concepts that may yet break down the road, I think
> their strategy was to use conepts more inline with C++ / C# so that they
> can keep this new VB.Net backward compatable (to VB.Net) for as
> long as they expect C# to remain backward compatable.
<snip>
>
> So, the way I see it, VB.Net will be an even better language for future
> developers, (in terms of both capablilities and (Dan's) stability) even if
> the current crowd has to suffer through a few hardships.

Re: Microsoft's C++ bigotry

On 15 Jan 2003 13:56:23 -0800, "Kent" <kp@kp.com> wrote:
>Microsoft cares only about it's own interests. They have a ton of C and
>C++ code, so if .Net is to be taken seriously, they have to make it as easy
>as possible to port their own code. Not to mention that the flexibility
>of C plays into it a bit as well. C++ is an extremely flexible language
>while VB6 (may it rest in peace) was not.

Ah, but C++ being the "extremely flexible language" it may be was
unusable by normal people. You had to be abnormal to want to use it,
let alone learn it. It is a language more akin to climbing sheer rock
faces without ropes, which the vast majority of the general public
would never attempt, whereas classic VB, though not quite such a
"high-level assembler" as C++ could satisfy a huge cross-section of
the community, both programmers and non-programmers.

VB was intended to be a fast way of creating effective business
solutions, and the fact that it was able to be used for vastly wider
categories of application than just business ones speaks volumes for
its flexibility.

Anyway, I've said it all before. I feel totally vindicated now. All
the chickens are coming home to roost, and it's a great shame that
this once-great, world-wide language is now effectively dead in the
water.

Re: Microsoft's C++ bigotry

On 15 Jan 2003 18:11:51 -0800, "Kent" <kp@kp.com> wrote:
>You think if Microsoft were not in complete control of Windows and someone
>changed the platform and developement tools they use to the extent VB was
>changed they would not be pissed off? They need their C and C++ code to
>be easily ported to .Net, that should be answer enough for you. The rest
>of us are not so lucky.

Yes, you can see to what lengths they went to defend the accusation of
antitrust which case is still ongoing, I believe. They never accepted
they did anything wrong and fought like rats in a sack to be allowed
to continue in the same old ways.

Re: Microsoft's C++ bigotry

On Thu, 16 Jan 2003 20:06:35 +1100, "Jason Sobell iGadget"
<iGadget_@hotmail.com> wrote:
>Kent, you seem to be missing the point... Only joking
>
>The differences between VB6 and VB.NET are enormous, and most of the [VB
>using] verbose people in this group seem to be split into three main
>clusters:
>1. Those who swear VB.NET is brilliant and deny that it is difficult to pick
>up, defending its every nuance
>2. Those who love VB6 and swear at VB.NET, claiming it should never have
>existed
>3. Those who approve VB.NET for its improvements over VB6, and accept that
>major changes were necessary

And which cluster do you think the vast majority of traditional VB
programmers fell into? My guess would be (2).

Re: Microsoft's C++ bigotry

C++ is close to the metal and at least at the beginning the idea was to use
directly the Windows API.

VB6 was done with this problem in mind and provided a form package as well
as some runtime functions to allows programming without having to deal with
those Windows low level details. But unfortunately it was done only with a
single language in mind.

..NET extends this view by providing a form package that is just part of much
broader support classes that are not restricted to a single language. It
would make little sense to maintain two products based on the same idea
(with the later supporting multiple languages).

Though I'm not a C++ expert IMO someone using MFC classes with C++ could ask
himself if MFC classes are still the way to go or if he'll have one day or
the other to switch to Managed C++.

IMO the problem is not the language but the package. As C++ doesn't rely
necessarily on an OS abstraction there is no problem to use pre .NET code.

In VB, to maintain code compatibility would have required to have in .NET
the same objects/methods than in VB but still provide a much more wider
support for abstracting the OS capabilities which would have been very hard.