Russell Jones

[Bill Seddon]

In my my view Russell Jones review of the naysayers points misses a number
of key issues with the direction VS.NET is taking VB and his use of trivial
issues obscures the key issues

There is no doubt that the new features will be welcomed. Writing VB code
without real inheritance makes life difficult; improved error trapping will
be a great improvement; the prospect of being able to write once for multiple
platforms is an exciting prospect.

But...

The concern isn't about the change being wrought by Microsoft's removal of
arcane language features. That just trivialises a serious issue. Millions
of developers around the world rely on VB to develop COMMERCIAL software.
This software has to be maintained with cost and reliability the key issues.

Billions of lines of code of VB code have been written and tested. To move
to VB.NET, despite the potential advantages, much of the code has to be
tweaked (at least). Moreover, most likely it will require re-testing at
the *code module* level rather than just a functional level, to ensure that
none of the (for example) parameter passing default changes break code.
Who is going to pay?

This burden has already had a knock on effect. Producers of controls, the
mainstays of most VB developers toolkits, are being forced to make, at least
short term, decisions about moving to the .NET platform or stay with the
current platform.

Like many control producers, except perhaps those with the resources of Microsoft,
Oracle or IBM, the manufacturers of the Janus Grid control are going with
.NET. They don't appear to have resources to create reliable products on
both platforms. The consequence is, as I understand it, that user of their
control for VS.NET (the only commercial one available today) cannot expect
updates or look forward to new extension and features without making the
transition to VS.NET themselves.

Producing reliable, commercial software is the main concern of most VB developers.
How reliable will VS.NET be? No doubt a lot of effort will go into making
it solid. How reliable will products created with VS.NET be? Of course
no one can really say... until SP1. Assurances can be given but no guarantees
can be offered. So why is the current platform being left behind and .NET
encouraged quite so much?

It's a concern that, according to some sections of the press (see The Economist
Jan 20th 2001), Microsoft's decisions about compatibility, etc. are as much
to do with the need to create and implement a strategy that will address
issues raised by the the Justice Department as anything else. Surely any
comany concerned about its client base (vs it's own future) would have done
a better job of helping users manage the transition to .NET.

Come on DevX, be a friend to developers. Put some of the more serious issues
raised by the railroading way .NET is being delivered to Microsoft.

Bill Seddon
Mondial Software

[Daniel Anderson]

Good points, Mr. Jones, and I agree with you completely. What is your take
on Microsoft's intent to release a tool to migrate Java to .NET, as they
recently announced?

"Russell Jones" <arj1@northstate.net> wrote in message
news:3a733780@news.devx.com...
> For those who might be confused
>
> * the contents of this post reflect my opinion, and does not necessarily
> reflect the position of DevX, Fawcette, or any of their other employees.
> * this message was not paid for by Microsoft
>
> Bill Seddon wrote:
> > The concern isn't about the change being wrought by Microsoft's removal
of
> > arcane language features. That just trivialises a serious issue.
> Millions
> > of developers around the world rely on VB to develop COMMERCIAL
software.
> > This software has to be maintained with cost and reliability the key
> issues....
>
> I agree that that's an issue, but what's the alternative? Let's look at
> several possible scenarios:
>
> POSSIBLE ACTION:. MS creates a "true" VB7 upgrade, providing
implementation
> inheritance and structured exception handling, but leaves the language
> outside of .NET.
> RESULT: VB7 becomes not a second-class language, but a dead-end language.
As
> MS moves forward with .NET, VB7 loses the ability to interoperate with
other
> MS products, which is not only one of the language's primary strengths,
but
> also one of the reasons that VB programmers chose it to begin with.
>
> POSSIBLE ACTION: The vocal .NET opponents succeed in forcing MS to change
> some things, like True=-1 and Integer = 16-bit value, to better support
> backward compatibility.
> RESULT: VB.NET, due to the requirement to check and possibly translate
> parameters twice for every call, immediately becomes a second class
language
> within .NET, meaning people who want better compatibility and performance
> are forced to move to C#.
>
> POSSIBLE ACTION: MS drops support for VB.NET altogether, (as some people
> have hoped)
> RESULT: VB6 programmers are in trouble. Rather than having a few years'
span
> to become proficient in .NET by creating new projects in VB.NET while
> maintaining old programs in VB5/6, they're stuck The choice becomes one
of
> dedicating your career to working in an increasingly obscure language, or
> having to use your own time to learn another .NET language (or Java) to
stay
> viable in the market. Note that learning another .NET langugage isn't
going
> to be any easier than learning VB.NET and learning Java isn't any easier
> either.
>
> POSSIBLE ACTION: MS licenses the existing VB language (versions 3-6) to
> another company who promises to extend it.
> RESULT: VB programmers wait, at minimum, for a year for an upgrade. By the
> time it is released, the VB community has shrunk considerably due to
people
> moving to VB.NET, and defections to Java and other .NET languages. The
> released product is at least as likely to be buggy as .NET, will run in a
> new IDE, and won't be able to take advantage of any updates to .NET. In
this
> scenario, VB will always be behind the Microsoft technology curve.
>
> I can't see how any of these scenarios are good for either VB the language
> or the VB programming community. Just to cover all the possibilities,
here's
> one more:
>
> POSSIBLE ACTION: MS's .NET framework fails miserably, forcing them (after
> huge revenue and credibility losses) to return to the current system
> (shudder). RESULT: Major corporations move all their critical programming
to
> Java, which is now seen as the only viable alternative to MS. VB
programmers
> lose again. Companies spend extra billions porting the existing VB code.
>
> So the real question is, should MS make it easier to migrate to VB.NET by
> improving its backward compatibility at the cost of weakening its
compliance
> with the .NET framework. I vote no.
>
> Russell Jones
> Sr.Web Development Editor
> DevX.com
>
> "Bill Seddon" <bill.seddon@mondialsoftware.com> wrote in message
> news:3a7328e0$1@news.devx.com...
> >
> > In my my view Russell Jones review of the naysayers points misses a
number
> > of key issues with the direction VS.NET is taking VB and his use of
> trivial
> > issues obscures the key issues
> >
> > There is no doubt that the new features will be welcomed. Writing VB
code
> > without real inheritance makes life difficult; improved error trapping
> will
> > be a great improvement; the prospect of being able to write once for
> multiple
> > platforms is an exciting prospect.
> >
> > But...
> >
> > The concern isn't about the change being wrought by Microsoft's removal
of
> > arcane language features. That just trivialises a serious issue.
> Millions
> > of developers around the world rely on VB to develop COMMERCIAL
software.
> > This software has to be maintained with cost and reliability the key
> issues.
> >
> > Billions of lines of code of VB code have been written and tested. To
> move
> > to VB.NET, despite the potential advantages, much of the code has to be
> > tweaked (at least). Moreover, most likely it will require re-testing at
> > the *code module* level rather than just a functional level, to ensure
> that
> > none of the (for example) parameter passing default changes break code.
> > Who is going to pay?
> >
> > This burden has already had a knock on effect. Producers of controls,
the
> > mainstays of most VB developers toolkits, are being forced to make, at
> least
> > short term, decisions about moving to the .NET platform or stay with the
> > current platform.
> >
> > Like many control producers, except perhaps those with the resources of
> Microsoft,
> > Oracle or IBM, the manufacturers of the Janus Grid control are going
with
> > NET. They don't appear to have resources to create reliable products on
> > both platforms. The consequence is, as I understand it, that user of
> their
> > control for VS.NET (the only commercial one available today) cannot
expect
> > updates or look forward to new extension and features without making the
> > transition to VS.NET themselves.
> >
> > Producing reliable, commercial software is the main concern of most VB
> developers.
> > How reliable will VS.NET be? No doubt a lot of effort will go into
> making
> > it solid. How reliable will products created with VS.NET be? Of course
> > no one can really say... until SP1. Assurances can be given but no
> guarantees
> > can be offered. So why is the current platform being left behind and
..NET
> > encouraged quite so much?
> >
> > It's a concern that, according to some sections of the press (see The
> Economist
> > Jan 20th 2001), Microsoft's decisions about compatibility, etc. are as
> much
> > to do with the need to create and implement a strategy that will address
> > issues raised by the the Justice Department as anything else. Surely
any
> > comany concerned about its client base (vs it's own future) would have
> done
> > a better job of helping users manage the transition to .NET.
> >
> > Come on DevX, be a friend to developers. Put some of the more serious
> issues
> > raised by the railroading way .NET is being delivered to Microsoft.
> >
> > Bill Seddon
> > Mondial Software
>
>

[Russell Jones]

For those who might be confused

* the contents of this post reflect my opinion, and does not necessarily
reflect the position of DevX, Fawcette, or any of their other employees.
* this message was not paid for by Microsoft

Bill Seddon wrote:
> The concern isn't about the change being wrought by Microsoft's removal of
> arcane language features. That just trivialises a serious issue.
Millions
> of developers around the world rely on VB to develop COMMERCIAL software.
> This software has to be maintained with cost and reliability the key
issues....

I agree that that's an issue, but what's the alternative? Let's look at
several possible scenarios:

POSSIBLE ACTION:. MS creates a "true" VB7 upgrade, providing implementation
inheritance and structured exception handling, but leaves the language
outside of .NET.
RESULT: VB7 becomes not a second-class language, but a dead-end language. As
MS moves forward with .NET, VB7 loses the ability to interoperate with other
MS products, which is not only one of the language's primary strengths, but
also one of the reasons that VB programmers chose it to begin with.

POSSIBLE ACTION: The vocal .NET opponents succeed in forcing MS to change
some things, like True=-1 and Integer = 16-bit value, to better support
backward compatibility.
RESULT: VB.NET, due to the requirement to check and possibly translate
parameters twice for every call, immediately becomes a second class language
within .NET, meaning people who want better compatibility and performance
are forced to move to C#.

POSSIBLE ACTION: MS drops support for VB.NET altogether, (as some people
have hoped)
RESULT: VB6 programmers are in trouble. Rather than having a few years' span
to become proficient in .NET by creating new projects in VB.NET while
maintaining old programs in VB5/6, they're stuck The choice becomes one of
dedicating your career to working in an increasingly obscure language, or
having to use your own time to learn another .NET language (or Java) to stay
viable in the market. Note that learning another .NET langugage isn't going
to be any easier than learning VB.NET and learning Java isn't any easier
either.

POSSIBLE ACTION: MS licenses the existing VB language (versions 3-6) to
another company who promises to extend it.
RESULT: VB programmers wait, at minimum, for a year for an upgrade. By the
time it is released, the VB community has shrunk considerably due to people
moving to VB.NET, and defections to Java and other .NET languages. The
released product is at least as likely to be buggy as .NET, will run in a
new IDE, and won't be able to take advantage of any updates to .NET. In this
scenario, VB will always be behind the Microsoft technology curve.

I can't see how any of these scenarios are good for either VB the language
or the VB programming community. Just to cover all the possibilities, here's
one more:

POSSIBLE ACTION: MS's .NET framework fails miserably, forcing them (after
huge revenue and credibility losses) to return to the current system
(shudder). RESULT: Major corporations move all their critical programming to
Java, which is now seen as the only viable alternative to MS. VB programmers
lose again. Companies spend extra billions porting the existing VB code.

So the real question is, should MS make it easier to migrate to VB.NET by
improving its backward compatibility at the cost of weakening its compliance
with the .NET framework. I vote no.

Russell Jones
Sr.Web Development Editor
DevX.com

"Bill Seddon" <bill.seddon@mondialsoftware.com> wrote in message
news:3a7328e0$1@news.devx.com...
>
> In my my view Russell Jones review of the naysayers points misses a number
> of key issues with the direction VS.NET is taking VB and his use of
trivial
> issues obscures the key issues
>
> There is no doubt that the new features will be welcomed. Writing VB code
> without real inheritance makes life difficult; improved error trapping
will
> be a great improvement; the prospect of being able to write once for
multiple
> platforms is an exciting prospect.
>
> But...
>
> The concern isn't about the change being wrought by Microsoft's removal of
> arcane language features. That just trivialises a serious issue.
Millions
> of developers around the world rely on VB to develop COMMERCIAL software.
> This software has to be maintained with cost and reliability the key
issues.
>
> Billions of lines of code of VB code have been written and tested. To
move
> to VB.NET, despite the potential advantages, much of the code has to be
> tweaked (at least). Moreover, most likely it will require re-testing at
> the *code module* level rather than just a functional level, to ensure
that
> none of the (for example) parameter passing default changes break code.
> Who is going to pay?
>
> This burden has already had a knock on effect. Producers of controls, the
> mainstays of most VB developers toolkits, are being forced to make, at
least
> short term, decisions about moving to the .NET platform or stay with the
> current platform.
>
> Like many control producers, except perhaps those with the resources of
Microsoft,
> Oracle or IBM, the manufacturers of the Janus Grid control are going with
> NET. They don't appear to have resources to create reliable products on
> both platforms. The consequence is, as I understand it, that user of
their
> control for VS.NET (the only commercial one available today) cannot expect
> updates or look forward to new extension and features without making the
> transition to VS.NET themselves.
>
> Producing reliable, commercial software is the main concern of most VB
developers.
> How reliable will VS.NET be? No doubt a lot of effort will go into
making
> it solid. How reliable will products created with VS.NET be? Of course
> no one can really say... until SP1. Assurances can be given but no
guarantees
> can be offered. So why is the current platform being left behind and .NET
> encouraged quite so much?
>
> It's a concern that, according to some sections of the press (see The
Economist
> Jan 20th 2001), Microsoft's decisions about compatibility, etc. are as
much
> to do with the need to create and implement a strategy that will address
> issues raised by the the Justice Department as anything else. Surely any
> comany concerned about its client base (vs it's own future) would have
done
> a better job of helping users manage the transition to .NET.
>
> Come on DevX, be a friend to developers. Put some of the more serious
issues
> raised by the railroading way .NET is being delivered to Microsoft.
>
> Bill Seddon
> Mondial Software

[Mike Mitchell]

On 27 Jan 2001 12:00:32 -0800, "Bill Seddon"
<bill.seddon@mondialsoftware.com> wrote:

>Who is going to pay?

Why, the consumers, of course! I can just see the crowds of corporate
finance directors queuing up at the bank to write out large cheques
that start "Pay Mi..." and end "......lots of money".

"But the benefits will be HUGE!" (so they keep telling us)

>
>Come on DevX, be a friend to developers. Put some of the more serious issues
>raised by the railroading way .NET is being delivered to Microsoft.

Alternatively, you could wait until **** freezes over, because that's
more likely to happen first, given the cheerleading stance of just
about all the editorials and opinions in VBPJ, for example. (With the
honourable exception of James E. Fawcette himself. Bet he wished he
got into peanuts instead...)

MM

[Russell Jones]

I think its OT, but it fits in extremely well with the .NET idea that the
logic of a program should be expressible in any language, making code
portable to whatever syntax you prefer. I also think it won't be long until
someone announces a C# to Java migration tool. After all, what's good for
the goose is good for the gander!


"Daniel Anderson" <dcanderson@uswest.net> wrote in message
news:3a733b44$1@news.devx.com...
> Good points, Mr. Jones, and I agree with you completely. What is your
take
> on Microsoft's intent to release a tool to migrate Java to .NET, as they
> recently announced?
>
> "Russell Jones" <arj1@northstate.net> wrote in message
> news:3a733780@news.devx.com...
> > For those who might be confused
> >
> > * the contents of this post reflect my opinion, and does not necessarily
> > reflect the position of DevX, Fawcette, or any of their other employees.
> > * this message was not paid for by Microsoft
> >
> > Bill Seddon wrote:
> > > The concern isn't about the change being wrought by Microsoft's
removal
> of
> > > arcane language features. That just trivialises a serious issue.
> > Millions
> > > of developers around the world rely on VB to develop COMMERCIAL
> software.
> > > This software has to be maintained with cost and reliability the key
> > issues....
> >
> > I agree that that's an issue, but what's the alternative? Let's look at
> > several possible scenarios:
> >
> > POSSIBLE ACTION:. MS creates a "true" VB7 upgrade, providing
> implementation
> > inheritance and structured exception handling, but leaves the language
> > outside of .NET.
> > RESULT: VB7 becomes not a second-class language, but a dead-end
language.
> As
> > MS moves forward with .NET, VB7 loses the ability to interoperate with
> other
> > MS products, which is not only one of the language's primary strengths,
> but
> > also one of the reasons that VB programmers chose it to begin with.
> >
> > POSSIBLE ACTION: The vocal .NET opponents succeed in forcing MS to
change
> > some things, like True=-1 and Integer = 16-bit value, to better support
> > backward compatibility.
> > RESULT: VB.NET, due to the requirement to check and possibly translate
> > parameters twice for every call, immediately becomes a second class
> language
> > within .NET, meaning people who want better compatibility and
performance
> > are forced to move to C#.
> >
> > POSSIBLE ACTION: MS drops support for VB.NET altogether, (as some people
> > have hoped)
> > RESULT: VB6 programmers are in trouble. Rather than having a few years'
> span
> > to become proficient in .NET by creating new projects in VB.NET while
> > maintaining old programs in VB5/6, they're stuck The choice becomes one
> of
> > dedicating your career to working in an increasingly obscure language,
or
> > having to use your own time to learn another .NET language (or Java) to
> stay
> > viable in the market. Note that learning another .NET langugage isn't
> going
> > to be any easier than learning VB.NET and learning Java isn't any easier
> > either.
> >
> > POSSIBLE ACTION: MS licenses the existing VB language (versions 3-6) to
> > another company who promises to extend it.
> > RESULT: VB programmers wait, at minimum, for a year for an upgrade. By
the
> > time it is released, the VB community has shrunk considerably due to
> people
> > moving to VB.NET, and defections to Java and other .NET languages. The
> > released product is at least as likely to be buggy as .NET, will run in
a
> > new IDE, and won't be able to take advantage of any updates to .NET. In
> this
> > scenario, VB will always be behind the Microsoft technology curve.
> >
> > I can't see how any of these scenarios are good for either VB the
language
> > or the VB programming community. Just to cover all the possibilities,
> here's
> > one more:
> >
> > POSSIBLE ACTION: MS's .NET framework fails miserably, forcing them
(after
> > huge revenue and credibility losses) to return to the current system
> > (shudder). RESULT: Major corporations move all their critical
programming
> to
> > Java, which is now seen as the only viable alternative to MS. VB
> programmers
> > lose again. Companies spend extra billions porting the existing VB code.
> >
> > So the real question is, should MS make it easier to migrate to VB.NET
by
> > improving its backward compatibility at the cost of weakening its
> compliance
> > with the .NET framework. I vote no.
> >
> > Russell Jones
> > Sr.Web Development Editor
> > DevX.com
> >
> > "Bill Seddon" <bill.seddon@mondialsoftware.com> wrote in message
> > news:3a7328e0$1@news.devx.com...
> > >
> > > In my my view Russell Jones review of the naysayers points misses a
> number
> > > of key issues with the direction VS.NET is taking VB and his use of
> > trivial
> > > issues obscures the key issues
> > >
> > > There is no doubt that the new features will be welcomed. Writing VB
> code
> > > without real inheritance makes life difficult; improved error trapping
> > will
> > > be a great improvement; the prospect of being able to write once for
> > multiple
> > > platforms is an exciting prospect.
> > >
> > > But...
> > >
> > > The concern isn't about the change being wrought by Microsoft's
removal
> of
> > > arcane language features. That just trivialises a serious issue.
> > Millions
> > > of developers around the world rely on VB to develop COMMERCIAL
> software.
> > > This software has to be maintained with cost and reliability the key
> > issues.
> > >
> > > Billions of lines of code of VB code have been written and tested. To
> > move
> > > to VB.NET, despite the potential advantages, much of the code has to
be
> > > tweaked (at least). Moreover, most likely it will require re-testing
at
> > > the *code module* level rather than just a functional level, to ensure
> > that
> > > none of the (for example) parameter passing default changes break
code.
> > > Who is going to pay?
> > >
> > > This burden has already had a knock on effect. Producers of controls,
> the
> > > mainstays of most VB developers toolkits, are being forced to make, at
> > least
> > > short term, decisions about moving to the .NET platform or stay with
the
> > > current platform.
> > >
> > > Like many control producers, except perhaps those with the resources
of
> > Microsoft,
> > > Oracle or IBM, the manufacturers of the Janus Grid control are going
> with
> > > NET. They don't appear to have resources to create reliable products
on
> > > both platforms. The consequence is, as I understand it, that user of
> > their
> > > control for VS.NET (the only commercial one available today) cannot
> expect
> > > updates or look forward to new extension and features without making
the
> > > transition to VS.NET themselves.
> > >
> > > Producing reliable, commercial software is the main concern of most VB
> > developers.
> > > How reliable will VS.NET be? No doubt a lot of effort will go into
> > making
> > > it solid. How reliable will products created with VS.NET be? Of
course
> > > no one can really say... until SP1. Assurances can be given but no
> > guarantees
> > > can be offered. So why is the current platform being left behind and
> .NET
> > > encouraged quite so much?
> > >
> > > It's a concern that, according to some sections of the press (see The
> > Economist
> > > Jan 20th 2001), Microsoft's decisions about compatibility, etc. are as
> > much
> > > to do with the need to create and implement a strategy that will
address
> > > issues raised by the the Justice Department as anything else. Surely
> any
> > > comany concerned about its client base (vs it's own future) would have
> > done
> > > a better job of helping users manage the transition to .NET.
> > >
> > > Come on DevX, be a friend to developers. Put some of the more serious
> > issues
> > > raised by the railroading way .NET is being delivered to Microsoft.
> > >
> > > Bill Seddon
> > > Mondial Software
> >
> >
>
>

[Bill McCarthy]

Hi Russell,
"Russell Jones" <arj1@northstate.net> wrote in message
news:3a733780@news.devx.com...
>
> POSSIBLE ACTION: The vocal .NET opponents succeed in forcing MS to change
> some things, like True=-1 and Integer = 16-bit value, to better support
> backward compatibility.
> RESULT: VB.NET, due to the requirement to check and possibly translate
> parameters twice for every call, immediately becomes a second class
language
> within .NET, meaning people who want better compatibility and performance
> are forced to move to C#.
>

What ?? That is utter nonsense.
How does having the keyword Integer being 16 bit effect VB.NET ??

As it stands VB.NET maps the Keyword to Int32, when it should map it to
Int16 for compatibility.
And actually as far as I am concerned changing it to Int32 is the best
option of all as it is the same as the CLR, hance no mapping is needed, and
the ambiguity introduced by changingthe defintion of keywords is removed.
Added to that, it defines the language in a much more stable way, allowing
the language to follow the CLR and easily adopt new integer types such as
Int128.

So, Russell, please tell me how people asking MS to change their mind about
re-defining Integer are in anyway what so ever causing the language to
become a second class language. In fact, when I ask for that to be changed
to Int32 I am doing so to hopefully have the language move forward with the
smoothest possible transistion while allowing for greater flexibility and
interoperability.

So what exactly is your arguement on that ?? Is it just you don't like
people saying everything isn't rosey , cause it sure looks like it to me.
How can you even have claimed to have considered this issue ?? Please ,
let's hear your arguements on it.

[Jon Ogden]

"Bill Seddon" <bill.seddon@mondialsoftware.com> wrote in message
news:3a7328e0$1@news.devx.com...
>
> In my my view Russell Jones review of the naysayers points misses a number
> of key issues with the direction VS.NET is taking VB and his use of
trivial
> issues obscures the key issues

I confess that I am amazed by the direction Jones, Meader, and even
Fawcette have taken in their commentaries. Apparently there is a real need
to marginalize the concerns re: VB.NET and denigrate those who express them.

> The concern isn't about the change being wrought by Microsoft's removal of
> arcane language features. That just trivialises a serious issue.
Millions
> of developers around the world rely on VB to develop COMMERCIAL software.
> This software has to be maintained with cost and reliability the key
issues.

I'm glad you've made this point so succinctly. I think it's something that
is understood more clearly, the further one gets from Redmond. I'm
perfectly ready to believe that in the long run VB applications will be
easier and cheaper to maintain if and when .NET is adopted by most of the
business world. But the cost of the conversion; the retraining, or
replacement of a number of junior developers; and necessity to maintain and
be current in two dissimilar versions of VB will irritate and frustrate a
number of senior managers who need their work done _now_ not later.

> This burden has already had a knock on effect. Producers of controls, the
> mainstays of most VB developers toolkits, are being forced to make, at
least
> short term, decisions about moving to the .NET platform or stay with the
> current platform.

If they can't do both - the way many of their clients will be forced to (and
are advised to by the VS product manager) -- their income will drop. If they
do do both, their expenses rise.

> Like many control producers, except perhaps those with the resources of
Microsoft,
> Oracle or IBM, the manufacturers of the Janus Grid control are going with
> NET. They don't appear to have resources to create reliable products on
> both platforms. The consequence is, as I understand it, that user of
their
> control for VS.NET (the only commercial one available today) cannot expect
> updates or look forward to new extension and features without making the
> transition to VS.NET themselves.

And the clients who are most likely not to switch to .NET at least for
awhile, will be the large corporations -- the ones who think in multiples of
100 licenses at a time. Most of them may wait for .NET+ before making that
investment -- unless they have dropped MSFT development in favor of
something else. (That's an option I wouldn't have conceved of as being
possible six weeks ago.)

> Producing reliable, commercial software is the main concern of most VB
developers.
> How reliable will VS.NET be? No doubt a lot of effort will go into
making
> it solid. How reliable will products created with VS.NET be? Of course
> no one can really say... until SP1. Assurances can be given but no
guarantees
> can be offered.

You are right. Not only will there no longer be "old hands" who either know
what to do or where to look it up; they'll be working with a product that is
as likely to be as flakey as Windows 3.0 or VB4 -- or both put together.
Yet MSFT expects me, and others like me, to recommend to senior management
that we commit a decent fraction of the company's gross to switching to that
product, when we already can see how little interest Microsoft has in
helping us make the transition.

>So why is the current platform being left behind and .NET
> encouraged quite so much?

Why did I think you were a-gonna tell us as soon as I read this <grin>

> It's a concern that, according to some sections of the press (see The
Economist
> Jan 20th 2001), Microsoft's decisions about compatibility, etc. are as
much
> to do with the need to create and implement a strategy that will address
> issues raised by the the Justice Department as anything else.

Every time this possibility is brought up, it is ignored or given very short
shrift by the .Net-at-any-price contingent. Therefore I suspect you have
hit the nail on the head.

>Surely any
> comany concerned about its client base (vs it's own future) would have
done
> a better job of helping users manage the transition to .NET.

You would think so, wouldn't you? We may have been spoiled by working in a
language considered to be part of the Office group. They seem to understand
something about customer satisfaction and service. Or perhaps MSFT has
gotten itself into a box with VB and really doesn't know how to get out of
it.

> Come on DevX, be a friend to developers. Put some of the more serious
issues
> raised by the railroading way .NET is being delivered to Microsoft.
>
> Bill Seddon
> Mondial Software

Thank you for summarizing the situation so well.

Good Luck,
Jon

[Zane Thomas]

On Sat, 27 Jan 2001 16:41:46 -0500, "Jon Ogden" <jon@ogdenco.net> wrote:

>Apparently there is a real need
>to marginalize the concerns re: VB.NET and denigrate those who express them.

Or some people have a real need to feel attacked by differences of
opinion.


---
Ice Z - Straight Outta Redmond

[Bill McCarthy]

"Zane Thomas" <zane@mabry.com> wrote in message
news:3b004157.1030332484@news.devx.com...
> On Sat, 27 Jan 2001 16:41:46 -0500, "Jon Ogden" <jon@ogdenco.net> wrote:
>
> >Apparently there is a real need
> >to marginalize the concerns re: VB.NET and denigrate those who express
them.
>
> Or some people have a real need to feel attacked by differences of
> opinion.
>

And some people seem to have to make personal attacks rather than focus on
the issues.

BTW: how's this for a contradiction:

" Let Microsoft know what you do or don't like about it. If VB.NET fails, it
should fail on its merits or lack thereof, not because it doesn't match the
expectations of the last generation's experts. "

So if you aren't an expert with VB then your opinion counts, but not if you
are. Sounds like a great way to get constructive feedback

Can you really say that article of Russell's was not targetted at certain
individuals ??

[Zane Thomas]

On Sun, 28 Jan 2001 09:12:35 +1100, "Bill McCarthy"
<Bill_McC@iprimus.com.au> wrote:

>And some people seem to have to make personal attacks rather than focus on
>the issues.

For some people personal attacks _are_ the issue.

If there'd been such wailing and hand-wringing over personal attacks on
this ng the past few months, I'd see doing so when it comes to RJ as
consistent. As it is, it looks like hypocrisy.


---
Ice Z - Straight Outta Redmond

[Bill McCarthy]

"Zane Thomas" <zane@mabry.com> wrote in message
news:3b0250b6.1034266859@news.devx.com...
>
> For some people personal attacks _are_ the issue.
>
> If there'd been such wailing and hand-wringing over personal attacks on
> this ng the past few months, I'd see doing so when it comes to RJ as
> consistent. As it is, it looks like hypocrisy.
>

You seem to forget all those times we have tried to move those kind of
discussions to the off ramp. There's a time and place for everything, and
using a magazine article to wage personal attacks is not the correct place.

[Zane Thomas]

"Bill McCarthy" <Bill_McC@iprimus.com.au> wrote:

>You seem to forget all those times we have tried to move those kind of
>discussions to the off ramp.

No I haven't forgotten, and as a section leader hereabouts I've proposed
another solution which I hope will be implemented soon.

>There's a time and place for everything, and
>using a magazine article to wage personal attacks is not the correct place.

<nit>It wasn't a magazine article.</net>

I don't see where Russell waged a personal attack on anyone - and yes, I
just went and read it again. If you - or Karl - think that the mere
mention of Karl's name constitutes an attack then you might consider that
it's the price of the fame which he so much enjoys. As far as I know Karl
hasn't had a problem providing his opinion about vb.net to zdnet or
whoever asks him. Anyone putting himself in such a position should expect
to see his name mentioned in a counter-view.


---
Ice Z - Straight Outta Redmond

[Russell Jones]

Hi Bill:

If the VB.NET keyword Integer is 16-bit, then either all the documentation
(and Intellisense parameter listings) would need to either be translated by
the IDE solely for VB.NET, or VB programmers would--once again, or perhaps I
should say *still* --be forced to mentally translate their parameters, e.g.
"Let's see--the documentation says Integer, therefore--because I'm a VB
programmer--I need to say 'Long.'" Do you really think that makes the
language easier?

(BTW: I agree with your idea on naming them Int16, Int32, etc. I'm all for
calling things what they are, and we can avoid this discussion when Integers
become 64 bit.)

But that's just for Integers. For Boolean True (which I notice you avoided)
the problem is similar. Either the runtime will need to evaluate parameters
for every function call, translating True from -1 to 1 for VB.NET when
necessary, or else VB programmers will have to keep two separate True values
in mind; those returned by all non-VB methods and those returned by VB-only
methods. Again--what a mess!

Finally, I've never maintained that VB.NET isn't going to cause problems, as
those who read prior editorials of mine already know. I think it would
behoove Microsoft to listen to the concerns of the experts in this newsgroup
as far as creating a more robust and complete upgrade migration path. But I
don't think that making VB incompatible with the rest of the languages that
run on the CLR is the answer.






"Bill McCarthy" <Bill_McC@iprimus.com.au> wrote in message
news:3a733d2a@news.devx.com...
> Hi Russell,
> "Russell Jones" <arj1@northstate.net> wrote in message
> news:3a733780@news.devx.com...
> >
> > POSSIBLE ACTION: The vocal .NET opponents succeed in forcing MS to
change
> > some things, like True=-1 and Integer = 16-bit value, to better support
> > backward compatibility.
> > RESULT: VB.NET, due to the requirement to check and possibly translate
> > parameters twice for every call, immediately becomes a second class
> language
> > within .NET, meaning people who want better compatibility and
performance
> > are forced to move to C#.
> >
>
> What ?? That is utter nonsense.
> How does having the keyword Integer being 16 bit effect VB.NET ??
>
> As it stands VB.NET maps the Keyword to Int32, when it should map it to
> Int16 for compatibility.
> And actually as far as I am concerned changing it to Int32 is the best
> option of all as it is the same as the CLR, hance no mapping is needed,
and
> the ambiguity introduced by changingthe defintion of keywords is removed.
> Added to that, it defines the language in a much more stable way, allowing
> the language to follow the CLR and easily adopt new integer types such as
> Int128.
>
> So, Russell, please tell me how people asking MS to change their mind
about
> re-defining Integer are in anyway what so ever causing the language to
> become a second class language. In fact, when I ask for that to be
changed
> to Int32 I am doing so to hopefully have the language move forward with
the
> smoothest possible transistion while allowing for greater flexibility and
> interoperability.
>
> So what exactly is your arguement on that ?? Is it just you don't like
> people saying everything isn't rosey , cause it sure looks like it to me.
> How can you even have claimed to have considered this issue ?? Please ,
> let's hear your arguements on it.
>
>
>
>
>
>
>
>
>
>

[Bill McCarthy]

Hi Russell,

"Russell Jones" <arj1@northstate.net> wrote in message
news:3a7355db$1@news.devx.com...
>
> If the VB.NET keyword Integer is 16-bit, then either all the documentation
> (and Intellisense parameter listings) would need to either be translated
by
> the IDE solely for VB.NET, or VB programmers would--once again, or perhaps
I
> should say *still* --be forced to mentally translate their parameters,
e.g.
> "Let's see--the documentation says Integer, therefore--because I'm a VB
> programmer--I need to say 'Long.'" Do you really think that makes the
> language easier?
>

But that is exactly what the case is at presetn. Becasue VB use the keyword
Integer for Int32, all the documentation does have to be re-written for it,
and the IDE does have to translate everything for it.
If you've got the SDK installed, please look at the help files:
ms-help://MSDNVS/vsintro7/html/vxgrfLanguageEquivalentsTypes.htm
and you will see that the only language that uses Integer for Int32 other
than VB.NET is VFP, and VFP isn't even a CLR compliant language.



> (BTW: I agree with your idea on naming them Int16, Int32, etc. I'm all for
> calling things what they are, and we can avoid this discussion when
Integers
> become 64 bit.)
>

**** right !!! <g>

> But that's just for Integers. For Boolean True (which I notice you
avoided)
> the problem is similar. Either the runtime will need to evaluate
parameters
> for every function call, translating True from -1 to 1 for VB.NET when
> necessary, or else VB programmers will have to keep two separate True
values
> in mind; those returned by all non-VB methods and those returned by
VB-only
> methods. Again--what a mess!
>

Ah, I avoided it because it's not a VB specific issue. It's a CLR issue. To
have the Boolean.ToInt32 method behave differently for different languages
is not feasible, and to have VB add overhead to booleans is definetly not
desirable. The question though is not should VB change the behaviour of
Booleans, but whether or not the CLR definiton of booleans is approapiate.
A boolean has two states, False and True. The current behaviour in the CLR
is for the boolean to accept values as being True if they are Not False. But
at the same time, the Boolean.ToInt32 does not return the equivalents for an
integer, that being 0 and Not 0.

Think of it this way. You can assign convert a value of 2 to a Boolean. It's
value as a boolean is True. Yet 2 does not have bit 0 (value 1) set. So the
behaviour is inconsistent with data in, data out.

Also, as Booleans are non-isomorphic in .NET, then it makes sense that MS
designs them with the major use in mind. Considering that VB developers make
up the vast majority of developers working with MS languages, then
fundamentals like this should be designed with VB in mind. It's a very
simple thing for the Boolean to do, to return the Not 0 value for the
intrinsic types. It provides those methods so a simple change in them is all
this is necessary.


> Finally, I've never maintained that VB.NET isn't going to cause problems,
as
> those who read prior editorials of mine already know. I think it would
> behoove Microsoft to listen to the concerns of the experts in this
newsgroup
> as far as creating a more robust and complete upgrade migration path. But
I
> don't think that making VB incompatible with the rest of the languages
that
> run on the CLR is the answer.
>

I agree. Unfortunately your article came across to me as you saying that MS
should not listen to the concerns of "last generations experts" <g>

[Roberto Martinez-Brunet]

> I don't see where Russell waged a personal attack on anyone - and yes, I
> just went and read it again. If you - or Karl - think that the mere
> mention of Karl's name constitutes an attack then you might consider that
> it's the price of the fame which he so much enjoys. As far as I know Karl
> hasn't had a problem providing his opinion about vb.net to zdnet or
> whoever asks him. Anyone putting himself in such a position should expect
> to see his name mentioned in a counter-view.

But, won't you agree that the counter-opinion should concentrate on the
arguments more than in the supposed motive behind them?

Roberto