Russell Jones


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 6 123 ... LastLast
Results 1 to 15 of 86

Thread: Russell Jones

  1. #1
    Bill Seddon Guest

    Russell Jones


    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

  2. #2
    Daniel Anderson Guest

    Re: Russell Jones

    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

    >
    >




  3. #3
    Russell Jones Guest

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




  4. #4
    Mike Mitchell Guest

    Re: Russell Jones

    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

  5. #5
    Russell Jones Guest

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

    > >
    > >

    >
    >




  6. #6
    Bill McCarthy Guest

    Re: Russell Jones

    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.











  7. #7
    Jon Ogden Guest

    Re: Russell Jones


    "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



  8. #8
    Zane Thomas Guest

    Re: Russell Jones

    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

  9. #9
    Bill McCarthy Guest

    Re: Russell Jones


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








  10. #10
    Zane Thomas Guest

    Re: Russell Jones

    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

  11. #11
    Bill McCarthy Guest

    Re: Russell Jones


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




  12. #12
    Zane Thomas Guest

    Re: Russell Jones

    "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

  13. #13
    Russell Jones Guest

    Re: 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.
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >




  14. #14
    Bill McCarthy Guest

    Re: Russell Jones

    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>









  15. #15
    Roberto Martinez-Brunet Guest

    Re: Russell Jones

    > 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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center