Microsoft's C++ bigotry - Page 8


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 8 of 43 FirstFirst ... 67891018 ... LastLast
Results 106 to 120 of 633

Thread: Microsoft's C++ bigotry

  1. #106
    John Butler Guest

    Re: Microsoft's C++ bigotry


    "Kent" <kp@kp.org> wrote in message news:3e2c9212$1@tnews.web.devx.com...
    >Really they should not have made a VB at all and
    > just ran with C# and left well enough alone.


    I for one am glad they didn't do that. With a VB background, getting into
    ..NET was much easier going the VB route. I can now do C# but still feel much
    more comfortable using VB...and since VB.NET has the same power factor now
    (barring one or two minor issues ..like advanced delegates)...there is no
    compelling reason to change over to squigglies.

    rgds
    John Butler





  2. #107
    John Butler Guest

    Re: Microsoft's C++ bigotry


    "Jonathan West" <jwest@mvps.org> wrote in message
    news:3e2c898f@tnews.web.devx.com...
    > I just wish the new languages could have been provided without depriving
    > existing application owners of a useful VB6 upgrade path. What has

    happened
    > is that Microsoft has for all practical purposes written two new

    Java-killer
    > languages and neglected their own customer base in the process. You could
    > say that they have shot themselves in the foot by so doing, but I think it
    > might be a little higher up, and more towards the centreline...


    Why do you treat the whole upgrade deal like it was now over and done with?
    Version 2 isn't out yet....VB6 has lots of life left in it, so there is
    still time for them to work on an upgrade wizard that really does
    ....upgrade, as well as introduce other features to make it easier to make
    the transition.

    I'm not arguing that it couldn't have been done before/been better planned
    etc...just that there is still room to capture more of the camp that refuse
    to move to VB.NET because of their code base etc. Please don't think I'm
    defending Microsoft, I'm certainly not....but the product is still
    relatively new....maybe you could give it some time and the glossy extras
    (which some may see as essential) might well be added? No?

    rgds
    John Butler



  3. #108
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "John Butler" <nospamjrbutler@btinternet.com> wrote in message
    news:3e2c97b2@tnews.web.devx.com...
    >
    > "Jonathan West" <jwest@mvps.org> wrote in message
    > news:3e2c898f@tnews.web.devx.com...


    >
    > Why do you treat the whole upgrade deal like it was now over and done

    with?

    I don't. If I did, I wouldn't bother continuing to post here where I know
    Microsoft is watching. I trust Microsoft's financial instincts to win out
    eventually over their sense of pride. Since VB is linked closely to VBA and
    Office, their financial instincts will *have* to win out if the company
    isn't going to suffer severely over this.

    > Version 2 isn't out yet....VB6 has lots of life left in it, so there is
    > still time for them to work on an upgrade wizard that really does
    > ...upgrade, as well as introduce other features to make it easier to make
    > the transition.


    If they had had a flawless upgrade wizard ready for v1 that could upgrade
    projects, individual modules and code snippets, they *might* just have
    gotten away with it. Now Microsoft has a reputation as a serial
    language-breaker, and I don't think a wizard will be enough to get the
    market moving any longer. Anyway, the effort they put into a wizard, they
    could equally put into the front-end of a VBClassic.Net compiler - it's the
    same translations involved, after all - and avoid the need for the
    individual module & code snippet capability.

    >
    > I'm not arguing that it couldn't have been done before/been better planned
    > etc...just that there is still room to capture more of the camp that

    refuse
    > to move to VB.NET because of their code base etc. Please don't think I'm
    > defending Microsoft, I'm certainly not....but the product is still
    > relatively new....maybe you could give it some time and the glossy extras
    > (which some may see as essential) might well be added? No?


    Extra features in v2 aren't of that much relevance to the owner of an
    existing application if the migration is too expensive to contemplate.
    Therefore, if Microsoft wants the VB6 codebase to move, a VBClassic.Net
    product has to take priority over new features. They have some time
    available to them still. As far as I can tell, much of the market is still
    in "wait and see" mode and sticking with VB6 until they have a requirement
    for features it cannot provide. If Microsoft has a viable upgrade strategy
    by then, they will stay with Microsoft. I'd say that Microsoft has maybe 12
    months or so to deliver this before customers start moving elsewhere in
    significant numbers. Longer than 12 months, and they will progressively
    reduce the proportion of the market they can retain.

    Given the history of the beta and v1, and the loss of trust that caused, the
    upgrade strategy would have to contain both the following elements to be
    viable:

    1. A VBClassic.Net (not an improved migration wizard to VB.NET)

    2. A big public splash about language stability - on the scale of the recent
    Trustworthy Computing initiative. It would have to be large enough that if
    Microsoft suffers yet another lapse in institutional memory in the future,
    even the dimmest computer journalist would remember and start asking awkward
    questions.

    --
    Regards
    Jonathan West


  4. #109
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

    "Jonathan West" <jwest@mvps.org> wrote

    > Given the history of the beta and v1, and the loss of trust that caused, the
    > upgrade strategy would have to contain both the following elements to be
    > viable:
    >
    > 1. A VBClassic.Net (not an improved migration wizard to VB.NET)


    > 2. A big public splash about language stability - on the scale of the recent
    > Trustworthy Computing initiative.



    If we see anything about language stability, in reference to spanning versions,
    I'd be surprised. There is already an industry term for that, namely backward
    compatability. I know you've heard it before, but I just thought I would add
    that 'language stability' is (AFAICT) a term commandeered by Dan Barclay.
    I would be real surprised to see MS using it in to mean backward compatability.

    Type in; 'IBM stability' at google and see what turns up...

    You'll get things like:

    "One of Linux's claims to fame is its legendary stability. However, the most
    stable operating system in the world won't do you any good if your hardware
    is defective or misconfigured ...
    .... the hardware glitch effectively makes our normally reliable Linux operating
    system barely able to stay afloat."
    http://www-106.ibm.com/developerworks/library/l-hw1/

    "Stability is defined as the ability of the configuration's hardware and software
    to function without interruption due to errors or malfunctions regardless of
    performance."
    http://www.polarsoft.com/download/wh...db2connect.pdf


    MS knows about stability, who hasn't seen Windows crash a time or two?
    A stable language, if properly translated, would mean a language that would
    not under any circumstances, cause the crash of an otherwise stable system.

    If you're going to hit them up for a public pow-wow, you may want to use
    terms more specific to what you mean....

    LFS




  5. #110
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Larry Serflaten" <serflaten@usinternet.com> wrote in message
    news:3e2cc315@tnews.web.devx.com...
    >
    > If we see anything about language stability, in reference to spanning

    versions,
    > I'd be surprised. There is already an industry term for that, namely

    backward
    > compatability. I know you've heard it before, but I just thought I would

    add
    > that 'language stability' is (AFAICT) a term commandeered by Dan Barclay.
    > I would be real surprised to see MS using it in to mean backward

    compatability.

    I don't particularly mind what term they use, so long as they make a
    commitment to the principle.

    --
    Regards
    Jonathan West


  6. #111
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Knule,

    > Is it really (Office - not the individual constituent parts)?. How times
    > flies...


    Actually it's well over ten years old. A company I used to work with did a
    bundle with Office back in '93.

    Gary



  7. #112
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Jonathan,

    > 4. Those who approve of moving VB to the .Net platform, but swear at all

    the
    > non-platform changes that were made to the language.


    Very accurate definition of how I feel. I've been working a little with
    Vb.Net (not as much as I would like because I have to make a living with
    VB6), and there are a lot of very nice things there, but why did they have
    to make it so difficult to make a transition.

    Aside from the changes in the language there is also the problem with
    internal differences. The Mid$ statement works the same but is 400 times
    slower. Meaning that code that uses it must be rewriten even though it is
    compatible.

    Gary



  8. #113
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    David,

    > Yeah, but the problem was that defaults to ByRef and 16-bit Integers were
    > stupid (the change to 32-bit Integers really should have been made in VB4;


    Why? Exactly what difference does it make?

    > the ByRef default never should have happened


    Why? I never had any problems with it. When I needed ByVal I used ByVal. I
    have a lot of subs that transform variables, therefore I find nothing wrong
    in the ByRef default. Lately I've been transforming some of my thousand or
    so gosubs into subs, and many require a long string of ByRef variables.

    > and the thousand and one variations on how to call a method were insane.


    Personally that was never one of my complaints.

    VB6 is far from perfect, and I would guess I spend a good amount of time on
    workarounds, optimization, etc., and there are a lot of things that could be
    better, but I find many of these issues irrelevant.

    Gary




  9. #114
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    John,

    > Why do you treat the whole upgrade deal like it was now over and done

    with?
    > Version 2 isn't out yet....VB6 has lots of life left in it, so there is
    > still time for them to work on an upgrade wizard that really does
    > ...upgrade, as well as introduce other features to make it easier to make
    > the transition.


    Personally I'm counting on that being true (which it may or may not be). In
    the meantime I'm trying to learn a little about VB.Net. I've ported a
    coulple of small programs, but nothing important, and will wait for version
    2 to see what it has to offer to get serious about it. If version 2 is more
    upgrade friendly I'll make the move. If not I'll wait for version 3 (or 4 or
    5 or...)

    Gary



  10. #115
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Fri, 17 Jan 2003 12:26:23 -0800, "Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:

    "Paul Clement" <UseAdddressAtEndofMessage@swspectrum.com> wrote in message <news:vhfg2v08epetnva1f0elcjjjlv7eq8jmm7@4ax.com>...

    > On Thu, 16 Jan 2003 21:49:49 +0000, Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >
    > On Thu, 16 Jan 2003 10:24:37 -0600, Paul Clement
    > <UseAdddressAtEndofMessage@swspectrum.com> wrote:
    >
    > >Unfortunately the foundation on which it was built was beginning to crumble. There were way too many
    > >half-baked implementations in Classic Visual Basic that really didn't make much sense to carry over
    > >into .NET.
    >
    > Why carry anything over from classic VB into a *new* language?
    >
    > VB.NET isn't a new language. It's a next generation of the previous just as VB 1.0 was to BASIC.
    > Once again, if you can identify the changes in the language elements that justify calling it a new
    > language feel free to do so.

    You know it's really tough talking to folks who don't use .NET since they don't seem to be able to
    distinguish between the language and the extensions to the language.


    Paul ~~~ pclement@ameritech.net
    Microsoft MVP (Visual Basic)

  11. #116
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On 17 Jan 2003 19:28:05 -0800, "Kent" <kp@kp.org> wrote:


    VB.Net is similar in syntax only... It may not be a completely new language,
    but it is only a shadow of what VB once was.

    Well I suppose we could say the same of Visual Basic and Quick Basic. Is there a point?


    There have been enough posts here the past two days to support the difficulty
    in moving from VB to VB.Net. Don't try and make it seem trivial because
    it's not a trivial issue.

    Except I wasn't trivializing the upgrade which involves much more than the core language. I think
    that was pretty clear in my first post.


    Paul ~~~ pclement@ameritech.net
    Microsoft MVP (Visual Basic)

  12. #117
    Gary Nelson Guest

    Re: Microsoft's C++ bigotry

    Phil,

    > If MS won't do it, I think there's a market for a third-party conversion
    > wizard that does a better job.


    I was contemplating making myself a program to remove the gosubs from my VB6
    code. But I got discouraged because a lot of things I use are just not up to
    par in VB.Net. Mid$ takes 400 times longer, which means that I must rewrite
    the code anyway, even though it does convert. File I/O is twice as slow in
    VB.Net, so even though it converts, I've still got to rewrite it using
    streams to get the speed back.

    So.... I decided to wait for version 2. Perhaps MS will revisit some of
    these problems. In the meantime I'll keep working with VB6.

    Gary



  13. #118
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Sun, 19 Jan 2003 19:03:06 -0000, "Jonathan West" <jwest@mvps.org> wrote:


    "Phil Weber" <pweber@nospam.fawcette.com> wrote in message
    news:3e2ad2ff@tnews.web.devx.com...
    > > No, no! We need to get Microsoft to admit it!
    >
    > Mike: That's actually why I wrote the piece that started this thread. I'm
    > going to use what little influence I have to try to get MS to make the
    > VB6-to-VB.NET transition more similar to the VC++-to-MC++ transition: "It
    > Just Works."
    >
    > If MS won't do it, I think there's a market for a third-party conversion
    > wizard that does a better job.

    Microsoft will do it, if they perceive that the following three conditions
    are met

    1. Sales & usage figures are bad for VB.NET
    2. They believe this is having a significant negative impact on the chances
    of success for the .NET platform overall.
    3. They believe fixing it will retrieve the situation.

    I don't have access to Microsoft's sales figures, but I have been keeping an
    eye on newsgroup volumes in the dotnet groups on the msnews server, which
    probably serve as a reasonable indication of usage. The C# groups have about
    50% more traffic than the VB.NET groups. I once took a look at a sample of
    the posts on the framework groups, to see which languages were being used
    more there, and the same ratio seemed to hold.

    Of course you're assuming that more posts mean higher popularity. That's statistical
    oversimplification. It could mean instead that more folks need help with C# than VB.NET. After all
    that is the purpose for posting a question in the first place. You have to consider other factors.

    ASP.NET uses both VB.NET and C# so you may want to eval the posts there as well.


    Paul ~~~ pclement@ameritech.net
    Microsoft MVP (Visual Basic)

  14. #119
    David A. Rothgery Guest

    Re: Microsoft's C++ bigotry

    Gary Nelson <gn@contanet.es> wrote:
    > David,
    >
    > > Yeah, but the problem was that defaults to ByRef and 16-bit Integers were
    > > stupid (the change to 32-bit Integers really should have been made in VB4;

    >
    > Why? Exactly what difference does it make?


    Because in a language strictly tied to a platform, Integer should be the
    optimal integer size on the platform (and no, Jonathan, implementing
    Integers as 32-bit integers behind the scene and making them act like
    16-bit integers would not be a good idea; you'd have a base integer type
    with very strange behavior, so experienced programmers would use Long
    for everything).

    > > the ByRef default never should have happened

    >
    > Why? I never had any problems with it.


    Lots of people claim that they never had any problems with GOTOs,
    GOSUBs, C-style pointers, or self-modifying code, but it doesn't keep
    them from being errors waiting to happen either.

    --
    Dave Rothgery
    Picking nits since 1976
    drothgery@alum.wpi.edu
    http://drothgery.editthispage.com

  15. #120
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Mon, 20 Jan 2003 20:22:42 -0000, "Jonathan West" <jwest@mvps.org>
    wrote:

    >There is nothing in the change to the .Net platform that requires a change
    >in the default calling convention from ByRef to ByVal, or requires that the
    >argument list for subroutines be enclosed in parentheses, or requires that
    >16-bit integers be called Short instead of Integer.


    But mummy knows best, ergo the change was made.

    >These changes (which are just 3 examples out of many other similar changes
    >that exist) have no effect on compatibility with the platform - they are
    >trivial for a compiler to cope with. They have no effect on performance,
    >either version of the source code can compile to the same object code. The
    >*only* effect they have is on the ability to make use of code written in the
    >earlier version of the language. That effect is negative - importing
    >projects is much more difficult, and importing code fragments unmodified is
    >in most cases impossible.


    But mummy knows best, ergo the changes were made.

    >The problem with the mindset as it seems to exist within Microsoft is that
    >VB has only ever really existed on one platform at a time, and so the
    >distinction between platform and language has become quite inappropriately
    >blurred. The fact that 32-bit is the "most performant" integer datatype on
    >32-bit Windows platforms doesn't mean that it has to be called Integer. The
    >fact that the platform codes a Boolean True as 0x0001 rather than as 0xFFFF
    >doesn't mean than CInt(True) had also to take the value 1 instead of -1. You
    >can decouple the syntax as presented to the programmer from what is going on
    >under the hood. In Microsoft's own interest (i.e. getting lots of VB
    >developers to port their applications to .Net) this decoupling ought to have
    >been done, but wasn't.


    But mummy still knows best and is willing to dump millions of
    ne'er-do-wells who program in a funny, peculiar procedural language
    without any trace of OOP, so that mummy may retain only the purists
    who think as it does.

    These changes were as much political and self-righteous as
    technological.

    MM

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