Microsoft's C++ bigotry - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 43 FirstFirst 123412 ... LastLast
Results 16 to 30 of 633

Thread: Microsoft's C++ bigotry

  1. #16
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 16 Jan 2003 20:06:35 +1100, "Jason Sobell iGadget"
    <iGadget_@hotmail.com> wrote:

    >My sympathies go out to all VB6 developers who do not have prior Java or C++
    >experience, because the .NET transition is a very hard one,


    Oh? Not what I've been hearing from the .Netizens in this ng for
    months, some of whom have even suggested that learning VB.Net is as
    easy as learning classic VB. In other words, they had no real basis
    for making such false claims but were merely talking up the new
    language to try and hoodwink novices into becoming believers.

    > but I disagree
    >that it is 'unacceptable' to have major language changes.


    I have never claimed that VB.Net should have been given an injection
    in the birth canal, but that it came out and promptly gobbled up its
    older sibling, classic VB. By all means allow Microsoft (yeah,
    magnanimous to a fault, me!) to produce what ever it liked, but that
    should *not* include screwing over existing programmers and businesses
    which depend on VB for everyday operation. That was cavalier, extreme,
    unwarranted and - still - reversible. By all means produce a new
    language and call it PolkaDots.OnNakedBots for all I care. But one
    must be able to have continuity - for EVAH, if need be - in one's
    previous and current choices. Otherwise there *is* a real risk that
    Mircrosoft or some other software company can come along in future
    years and do exactly the same thing all over again.

    > Core VB6 was a
    >tiny part of the VB environment, and most of the functionality used was in
    >COM objects included as references. ADO, networking, 3rd party controls,
    >scripting, and a myriad of other commonly used functions were in these
    >addons, and these have been replicated with different syntax into the .NET
    >library.
    >The biggest pain in VB6 code conversion is that we all tended to write such
    >apalling VB6 code!


    This is nonsense! Who is "we all", I have to ask? You are blaming the
    lack of a suitable conversion tool on some spurious claim that classic
    VB was always just thrown together? The whole point of a modern,
    dynamic language is that it *can* be thrown together! We do not have
    such rigid structures in other walks of life nowadays. No longer do we
    build massive stone bridges where the structure is far larger than the
    culvert that passes through it. We apply flexibility, lightness, and
    clean design concepts just strong enough to fulfil the purpose. So it
    must be with programming, too. We *should* be able to throw together a
    few "pictures" (i.e. controls), provide minimum, if any, glue code,
    and try it out. There is not a machine on the planet that has to be
    designed to work out of the box without any adjustments. We always
    build machines to be adjustable and flexible. The problem with .Net
    and the whole way of thinking in OOP is that it is all so prescribed
    and defined. Instead, we must imbue the machines themselves with more
    intelligence so that they aid us. We do that with Automatic Train
    Protection, for example, so that if the driver inadvertently passes a
    danger signal the train is brought to a safe halt. Same goes for
    software, or it should do. Instead of taking the concepts in classic
    VB, then adding on reams of total oopification, the designers should
    have made the language more amenable to allowing apps to be thrown
    together. I mean, can anyone, hand on heart, really say it's more
    *fun* coding in VB.Net than in classic VB? Even the diehard masochists
    who defended the obfuscatory powers of C++ to the last semicolon found
    themselves sidelined by businesses large and small, as the bean
    counters suddenly realised how the wool was being pulled over their
    eyes by a few Jolt-quaffing purists.

    > It was so easy to quickly knock up an initial solution,
    >then spend days or weeks modifying it to give a quality looking application.


    Just as we take a jack plane and smooth a plank of timber, continually
    trying it out to see if it's "right" yet. The dogmatic, oopificatory
    approach is to have every single piece of wood passed through a
    thicknesser which has been adjusted to within a thousandth of a
    millimeter.

    >If we had to scrap it and restart we know that we could write it in half the
    >code, and make it more maintainable, but with VB6 we don't have to do that.


    'Zactly! We can modify and improve the code, and because, lacking much
    OOP, thank God, it is so much more amenable to change without
    affecting the object "model", and we can quickly turn a pig's ear into
    a silk purse. You're not going to convince me that the only successful
    VB apps were ones which had been painstakingly designed from the
    ground up over months and months before any coding was started. Sure,
    that approach could and did work for the truly complicated and complex
    apps, but when did a VB team ever set out to replace the Chicago
    Baggage Handling System or equivalent? That kind of mammoth computing
    project may have seen elements of VB being employed, but huge systems
    like that are rare compared with the multitude of straightforward
    business apps which were VB's forte where the business rules have been
    known for centuries. The beauty of something like VB (and there's
    nothing quite like it, not really) is its pliant nature, yet it is
    continually hand-holding us in case we do anything really stupid -
    like incrementing a pointer off the end of memory.

    >When we try to port that code to a VB.NET environment we have terrible
    >problems, yet if we had used VB.NET in the first place we would probably
    >have been forced to do more planning and developed a more structured
    >solution the first time.


    And there's nothing wrong in that approach if you're using a language
    which demands it, as you're now suggesting VB.Net does, but again my
    plea is not to take away my previous tools! If they had simply allowed
    VB to continue as a bona fide alternative, even with further
    improvements and an open-ended "use by" date, then as time passed,
    people would have been able to get to know VB.Net at their own pace,
    not have it thrust down their throat.

    > This is something that Java and C++ developers are
    >used to, but VB developers are not.


    But you say this as if to claim that the Java/C++ position is the
    'preferred' one, and my inference is that the VB folk need to be
    dragged kicking and screaming into that 'alternative' mindset. This is
    missing the point of a Rapid Application Development language! It all
    revolves around that word 'rapid'. In the modern workshop we mount a
    fresh lump of metal into the lathe chuck, adjust the knife, push a
    button, and bingo! Out comes a new piston, or a new camshaft, or
    whatever. We are no longer hunched over our work like in the lathes of
    old with micrometer in hand and oily rag in the other. We are using
    technology to improve the whole process through effective use of
    computers. One even sees this in the airline industry, where the
    old-fashioned tug-on-a-rope cables of the Boeing school of airplane
    design are being supplanted by fly-by-wire, computer-based controls as
    epitomised by European Airbus Industrie. Yet while we are typing in
    code, the computer is almost completely passive. (Oh, it can detect
    'syntax error' - how marvellous!)

    > Now we are forced to adopt the same
    >design constraints, so what VB developers considered 'RAD' (i.e. don't plan,
    >just drag, drop & bodge) is no longer a viable option.


    Why does the pejorative 'bodge' figure in there? Why does RAD have to
    be a bodge? Why not instead adopt minimal planning, dragging,
    dropping, adjusting, and trying out as the norm? We know it does work!
    We have the evidence of 12 years of traditional VB programming
    throughout millions of businesses to show for it.

    >Is this good or bad?


    Rigid = bad. Flexible = good. OOP = rigid. Non-OOP = flexible.

    > I reckon that 80%+ of VB6 developers will require
    >extensive relearning to be able to do this, and this is not good for
    >industry.


    It's not good because it's costing industry a small fortune in extra
    costs that they would otherwise not have had to pay.

    > Perhaps MS should have retained VB6


    No 'perhaps' about it! Of course this is what they should have done.
    They still could!

    > but put in place more
    >'incentives' to move over, such as free additional controls or wizards that
    >developers and/or companies would be attracted to. From teaching and
    >consulting I know how much experience most industry VB6 developers have, and
    >I can say that most would (and are) struggling terribly to get to grips with
    >VB.NET.


    Instead of blaming the VB programmers, who after all were and are only
    using the tools sold to them over a decade or more, I blame the new
    language and its platform for being so unnecessarily complex. As for
    incentives, that's a bit like offering a drink to Kamikaze pilots
    before their final flight into glory.

    MM

  2. #17
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Phil Weber" <pweber@nospam.fawcette.com> wrote in message
    news:3e25c84a@tnews.web.devx.com...
    > "Why should C++ developers enjoy such ease of migration to .NET, while VB
    > developers (of whom there are arguably many more) are forced to rewrite
    > their code?...The message seems clear: If your application is
    > 'mission-critical', don't use VB." --
    > http://www.philweber.com/net/2003/01/14.htm#a40
    >


    This is very old news. Rob Bovey wrote a guestop in VSM mentioning this
    specific point, right back in May 2001

    Don't Abandon "Classic" VB
    http://www.fawcette.com/archives/pre...501/go0501.asp

    A long time ago now, the VB.NET design team discovered that the design of
    the framework didn't allow 100% identical behavior with VB6, specifically
    with the change to garbage collection from deterministic finalization. It
    seems to me that what happened was that once the principle of 100%
    compatibility was lost, then there was a gradual slippage as various people
    came up with cool ideas for "improving" the language. Each one was looked at
    and quite a few were approved - most of them individually being fairly
    insignificant. And so the slide down from 100% compatibility began, without
    there ever being a deliberate decision to do so. The problem is that it was
    *fun* to do cool new stuff, and boring and restrictive to abide by the
    constraint of assuring an upgrade path for existing customers. The VB team
    members wanted to have the same fun that the C# people were having,
    designing a whole new language. The VB management failed to see how the wind
    was blowing, and didn't do nearly enough to keep compatibility at the top of
    the agenda, though it was never formally dropped as a product requirement.

    Then they released beta 1, and I suspect that a collective "oh ****!" was
    heard on campus when the howls of rage came from many long-time VB
    programmers. At that point, they could have (and IMO should have) gone back
    and fixed everything that it was practicable to fix. The DF/GC thing is not
    fixable and there are maybe 3-4 other similar platform changes in the same
    category, but there are a heck of a lot of changes that *could* have been
    fixed, to the point where most VB6 source code could have been pasted into
    VB.NET projects and been compiled and run unchanged. VB.NET programmers
    would then have had the best of all possible worlds

    - access to the framework
    - easy upgrade path for their VB6 apps
    - use of almost all the publicly available VB6 source code to include in
    VB.NET projects

    Unfortunately they didn't do that. You would have to ask Microsoft why they
    didn't. I suspect that it was largely pride - the embarrassment of admitting
    in public that they got it so comprehensively wrong. A contributory factor
    might have been the approach of deadlines. The overall effect is that they
    made a couple of token changes (such as AndAlso, and restoring the tag
    property), decided to cobble together the migration wizard, and hoped that
    the complaints would go away. They didn't. Many developers regarded that as
    a major betrayal.

    Microsoft is now in a tough position. It has publicly committed itself to
    the fact that VB.NET is the VB way of the future, but publicly available
    indications (e.g. newsgroup posting volumes) show that VB.NET adoption rates
    are pretty dire. It looks like C#, from an installed base of zero, now has
    about 50% more active users than VB.NET.

    You might think that they should at least make large and public promises
    about future language stability, to try and recover confidence. The problem
    is that they can't do that - yet. There is still a very large user base out
    there which is using a current Microsoft product and coding in a very
    VB6-like language. I'm referring of course to Office & VBA. I don't know
    whether any statistics have ever been gathered on how many Office users
    write VBA, but it wouldn't surprise me if the numbers surpass those coding
    in VB5/6 (though of course that will include many part-timers whose main job
    is something else). Office is going to have to link up with .NET in due
    course, and the implication of that is that VBA will eventually have to be
    replaced by an embedded form of VB.NET, though they may run them both in
    parallel for a while.

    At best Microsoft would look awfully silly, and at worst downright
    dishonest, if they were to make a big public statement about stability and
    then drop VBA. In any case, dropping VBA will be regarded as at least as big
    a betrayal as the VB6/VB.NET change, and doing so in the face of a published
    policy on stability would leave them with no credibility at all.

    When Microsoft drops VBA from Office, they will be messing with the
    customers of one of their top 2 products. The stakes start getting rather
    high at this point. How many major accounts will decide to say "thanks, but
    no thanks" to a new version of Office when their TCO calculation has to
    include a rewrite of their VBA apps? Office is already a pretty capable
    platform, and most companies haven't yet scratched the surface of what they
    can do with the existing versions. They might well decide that the current
    version is good enough for quite some time to come. No upgrades = no upgrade
    revenue for Microsoft.

    What would you do in their place?

    --
    Regards
    Jonathan West


  3. #18
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:8v3d2v40406css8oj2clb53qvq14nvmk2u@4ax.com...
    > On Thu, 16 Jan 2003 20:06:35 +1100, "Jason Sobell iGadget"
    > <iGadget_@hotmail.com> wrote:
    >
    > >Kent, you seem to be missing the point... Only joking
    > >
    > >The differences between VB6 and VB.NET are enormous, and most of the [VB
    > >using] verbose people in this group seem to be split into three main
    > >clusters:
    > >1. Those who swear VB.NET is brilliant and deny that it is difficult to

    pick
    > >up, defending its every nuance
    > >2. Those who love VB6 and swear at VB.NET, claiming it should never have
    > >existed
    > >3. Those who approve VB.NET for its improvements over VB6, and accept

    that
    > >major changes were necessary

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


    Yes, for the reasons that I stated later in the message.
    I won't comment in here. Read (or ignore) my next posting for other comments


    Cheers,
    Jason



  4. #19
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote in
    message news:3e269916@tnews.web.devx.com...
    > Kent wrote:
    >
    > > You seem to think that "we" are blowing the whole thing out of
    > > proportion? I beg to differ. Maybe you can tell me does Microsoft
    > > have to completely rewrite office every 10 years?

    >
    > Is Office 10 years old yet?. [The answer is "no" btw, whatever the
    > software. You rewrite when you need to.]


    Actually, the answer is yes. I've been told by people in Microsoft that
    there is some code in Word and Excel that is so old and patched that nobody
    dare touch it because nobody knows what it does any more.

    >
    > > Isn't it time for
    > > a complete rewrite of windows? (yes it is, but I won't go there).

    >
    > DOS->Win9x->WinNT. Major/complete rewites. Enough for your you?


    Yes, but not because the language changed under their feet. They wanted new
    features - effectively a new product with a similar name. That's a perfectly
    valid business decision, under Microsoft's own control regarding the extent
    and timing of the rewrite.

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

    >
    > So change the tool. The OS has thefeatures but the tool is outdated. How
    > many people are still using VB1? VB4?


    So, what should I change VB6 to? What should I change Office VBA to if/when
    Microsoft drops it?

    >
    > > It IS NOT ACCEPTABLE to have drastic changes to the
    > > development tools.

    >
    > On the contrary. It is necessary that dev tools evolve to be relevant.

    Every
    > so often, the change will be drastic or the tool might become irrelevant.


    What is VB6 evolving to?

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

    >
    > Most of MS's code wouldn't "port" to .NET. It would continue to compile

    and
    > run as unmanaged code with VS.NET. MC++ doesn't magically convert legacy

    C++
    > code to .NET assemblies.


    I think many of MS's customers wish they could say the same of their VB code
    :-)

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

    >
    > If C/C++ migration support is broken, there will be no VB at all.


    As VB migration support is broken, there may be few customers to take
    advantage of it...

    --
    Regards
    Jonathan West


  5. #20
    Larry Triezenberg Guest

    Re: Microsoft's C++ bigotry

    This seems to be the crux of the folly. There are very few things in VB
    that it was imperative to change. Those few would have been relatively easy
    to accommodate in most cases. This would have greatly increased the
    adoption rate and would have allowed developers and their client community
    to begin utilizing some of the great new features while retaining most of
    their legacy code. As evidenced in the MID discussion on this group, it is
    possible to implement comparable code using .NET, just not necessarily using
    the prior (existing) syntax. Whether VB will gain enough momentum to
    continue and whether VBA will follow it is an open question, eventually I
    think that it will (in both cases). However, I know a number of developers
    that would be switching now if it meant an upgrade rather than a rewrite.

    "Jonathan West" <jwest@mvps.org> wrote in message
    news:3e26a0f9@tnews.web.devx.com...
    > Then they released beta 1, and I suspect that a collective "oh ****!" was
    > heard on campus when the howls of rage came from many long-time VB
    > programmers. At that point, they could have (and IMO should have) gone

    back
    > and fixed everything that it was practicable to fix. The DF/GC thing is

    not
    > fixable and there are maybe 3-4 other similar platform changes in the same
    > category, but there are a heck of a lot of changes that *could* have been
    > fixed, to the point where most VB6 source code could have been pasted into
    > VB.NET projects and been compiled and run unchanged. VB.NET programmers
    > would then have had the best of all possible worlds
    >
    > - access to the framework
    > - easy upgrade path for their VB6 apps
    > - use of almost all the publicly available VB6 source code to include in
    > VB.NET projects
    >
    > Unfortunately they didn't do that. You would have to ask Microsoft why

    they
    > didn't. I suspect that it was largely pride - the embarrassment of

    admitting
    > in public that they got it so comprehensively wrong. A contributory factor
    > might have been the approach of deadlines. The overall effect is that they
    > made a couple of token changes (such as AndAlso, and restoring the tag
    > property), decided to cobble together the migration wizard, and hoped that
    > the complaints would go away. They didn't. Many developers regarded that

    as
    > a major betrayal.




  6. #21
    Jason Sobell iGadget Guest

    Re: Microsoft's C++ bigotry

    Wow, you have been busy. Leave some bandwidth for the rest of us...

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:u64d2vccbefoacvl3n846lmppsgof38gt1@4ax.com...
    > On Thu, 16 Jan 2003 20:06:35 +1100, "Jason Sobell iGadget"
    > <iGadget_@hotmail.com> wrote:
    >
    > >My sympathies go out to all VB6 developers who do not have prior Java or

    C++
    > >experience, because the .NET transition is a very hard one,

    >
    > Oh? Not what I've been hearing from the .Netizens in this ng for
    > months, some of whom have even suggested that learning VB.Net is as
    > easy as learning classic VB. In other words, they had no real basis
    > for making such false claims but were merely talking up the new
    > language to try and hoodwink novices into becoming believers.


    Yes you have heard this. It has been stated dozens of times, but you choose
    to ignore those comments and treat everyone as a VB.NET zealot and Microsoft
    clone.

    > > but I disagree
    > >that it is 'unacceptable' to have major language changes.

    >
    > I have never claimed that VB.Net should have been given an injection
    > in the birth canal, but that it came out and promptly gobbled up its
    > older sibling, classic VB. By all means allow Microsoft (yeah,
    > magnanimous to a fault, me!) to produce what ever it liked, but that
    > should *not* include screwing over existing programmers and businesses
    > which depend on VB for everyday operation. That was cavalier, extreme,
    > unwarranted and - still - reversible. By all means produce a new
    > language and call it PolkaDots.OnNakedBots for all I care. But one
    > must be able to have continuity - for EVAH, if need be - in one's
    > previous and current choices. Otherwise there *is* a real risk that
    > Mircrosoft or some other software company can come along in future
    > years and do exactly the same thing all over again.
    >
    > > Core VB6 was a
    > >tiny part of the VB environment, and most of the functionality used was

    in
    > >COM objects included as references. ADO, networking, 3rd party controls,
    > >scripting, and a myriad of other commonly used functions were in these
    > >addons, and these have been replicated with different syntax into the

    ..NET
    > >library.
    > >The biggest pain in VB6 code conversion is that we all tended to write

    such
    > >apalling VB6 code!

    >
    > This is nonsense! Who is "we all", I have to ask?


    Sorry, "We all" refers to those of us that develop commercially, and "We
    all" know that "we" regularly rush a piece of code together to solve a
    problem, and VB lets us do that easily. Modifying that code later, or
    handing it over to another person often makes us painfully aware of code
    that we have written this way. The old comment "TODO: Rewrite before
    release"

    > You are blaming the
    > lack of a suitable conversion tool on some spurious claim that classic
    > VB was always just thrown together? The whole point of a modern,
    > dynamic language is that it *can* be thrown together!


    Ahh... so that's what a modern language is for.

    > We do not have
    > such rigid structures in other walks of life nowadays. No longer do we
    > build massive stone bridges where the structure is far larger than the
    > culvert that passes through it. We apply flexibility, lightness, and
    > clean design concepts just strong enough to fulfil the purpose. So it
    > must be with programming, too. We *should* be able to throw together a
    > few "pictures" (i.e. controls), provide minimum, if any, glue code,
    > and try it out. There is not a machine on the planet that has to be
    > designed to work out of the box without any adjustments. We always
    > build machines to be adjustable and flexible. The problem with .Net
    > and the whole way of thinking in OOP is that it is all so prescribed
    > and defined. Instead, we must imbue the machines themselves with more
    > intelligence so that they aid us. We do that with Automatic Train
    > Protection, for example, so that if the driver inadvertently passes a
    > danger signal the train is brought to a safe halt. Same goes for
    > software, or it should do. Instead of taking the concepts in classic
    > VB, then adding on reams of total oopification, the designers should
    > have made the language more amenable to allowing apps to be thrown
    > together. I mean, can anyone, hand on heart, really say it's more
    > *fun* coding in VB.Net than in classic VB? Even the diehard masochists
    > who defended the obfuscatory powers of C++ to the last semicolon found
    > themselves sidelined by businesses large and small, as the bean
    > counters suddenly realised how the wool was being pulled over their
    > eyes by a few Jolt-quaffing purists.


    So your argument is that structured langauges are not as flexible as you
    would like them to be.
    I don't find it more 'fun' coding in VB.NET, but I do find it more
    satisfying knowing that the structured solution I've devised is less likely
    to have an unexpected runtime error due to a date format being invalid or
    some variant based anomaly.

    > > It was so easy to quickly knock up an initial solution,
    > >then spend days or weeks modifying it to give a quality looking

    application.
    >
    > Just as we take a jack plane and smooth a plank of timber, continually
    > trying it out to see if it's "right" yet. The dogmatic, oopificatory
    > approach is to have every single piece of wood passed through a
    > thicknesser which has been adjusted to within a thousandth of a
    > millimeter.


    Please, I beg you, stop. You are putting the anal into analogy!

    > >If we had to scrap it and restart we know that we could write it in half

    the
    > >code, and make it more maintainable, but with VB6 we don't have to do

    that.
    >
    > 'Zactly! We can modify and improve the code, and because, lacking much
    > OOP, thank God, it is so much more amenable to change without
    > affecting the object "model", and we can quickly turn a pig's ear into
    > a silk purse. You're not going to convince me that the only successful
    > VB apps were ones which had been painstakingly designed from the
    > ground up over months and months before any coding was started. Sure,
    > that approach could and did work for the truly complicated and complex
    > apps, but when did a VB team ever set out to replace the Chicago
    > Baggage Handling System or equivalent? That kind of mammoth computing
    > project may have seen elements of VB being employed, but huge systems
    > like that are rare compared with the multitude of straightforward
    > business apps which were VB's forte where the business rules have been
    > known for centuries. The beauty of something like VB (and there's
    > nothing quite like it, not really) is its pliant nature, yet it is
    > continually hand-holding us in case we do anything really stupid -
    > like incrementing a pointer off the end of memory.
    >
    > >When we try to port that code to a VB.NET environment we have terrible
    > >problems, yet if we had used VB.NET in the first place we would probably
    > >have been forced to do more planning and developed a more structured
    > >solution the first time.

    >
    > And there's nothing wrong in that approach if you're using a language
    > which demands it, as you're now suggesting VB.Net does, but again my
    > plea is not to take away my previous tools! If they had simply allowed
    > VB to continue as a bona fide alternative, even with further
    > improvements and an open-ended "use by" date, then as time passed,
    > people would have been able to get to know VB.Net at their own pace,
    > not have it thrust down their throat.
    >
    > > This is something that Java and C++ developers are
    > >used to, but VB developers are not.

    >
    > But you say this as if to claim that the Java/C++ position is the
    > 'preferred' one, and my inference is that the VB folk need to be
    > dragged kicking and screaming into that 'alternative' mindset. This is
    > missing the point of a Rapid Application Development language! It all
    > revolves around that word 'rapid'. In the modern workshop we mount a
    > fresh lump of metal into the lathe chuck, adjust the knife, push a
    > button, and bingo! Out comes a new piston, or a new camshaft, or
    > whatever. We are no longer hunched over our work like in the lathes of
    > old with micrometer in hand and oily rag in the other. We are using
    > technology to improve the whole process through effective use of
    > computers. One even sees this in the airline industry, where the
    > old-fashioned tug-on-a-rope cables of the Boeing school of airplane
    > design are being supplanted by fly-by-wire, computer-based controls as
    > epitomised by European Airbus Industrie. Yet while we are typing in
    > code, the computer is almost completely passive. (Oh, it can detect
    > 'syntax error' - how marvellous!)
    >
    > > Now we are forced to adopt the same
    > >design constraints, so what VB developers considered 'RAD' (i.e. don't

    plan,
    > >just drag, drop & bodge) is no longer a viable option.

    >
    > Why does the pejorative 'bodge' figure in there? Why does RAD have to
    > be a bodge? Why not instead adopt minimal planning, dragging,
    > dropping, adjusting, and trying out as the norm? We know it does work!


    Java with a decent GUI for form design is also a RAD tool. RAD is not a
    bodge, but many people seem to presume that they are a 'RAD' developer if
    the 'wing it' and develop an application with no prior planning or design.
    This is what you are clearly looking for, and VB.NET does not deliver it in
    the easy way that VB6 does.

    > We have the evidence of 12 years of traditional VB programming
    > throughout millions of businesses to show for it.
    >
    > >Is this good or bad?

    >
    > Rigid = bad. Flexible = good. OOP = rigid. Non-OOP = flexible.


    'Flexible' is not the same as 'slack'. Much VB code is 'slack', and that's
    why we see so many apallingly written apps in VB6.
    You might not see them, becaused you don't work in industry where you get to
    fix, document, and modify other developers code, but I do.

    > > I reckon that 80%+ of VB6 developers will require
    > >extensive relearning to be able to do this, and this is not good for
    > >industry.

    >
    > It's not good because it's costing industry a small fortune in extra
    > costs that they would otherwise not have had to pay.
    >
    > > Perhaps MS should have retained VB6

    >
    > No 'perhaps' about it! Of course this is what they should have done.
    > They still could!
    >
    > > but put in place more
    > >'incentives' to move over, such as free additional controls or wizards

    that
    > >developers and/or companies would be attracted to. From teaching and
    > >consulting I know how much experience most industry VB6 developers have,

    and
    > >I can say that most would (and are) struggling terribly to get to grips

    with
    > >VB.NET.

    >
    > Instead of blaming the VB programmers, who after all were and are only
    > using the tools sold to them over a decade or more, I blame the new
    > language and its platform for being so unnecessarily complex. As for
    > incentives, that's a bit like offering a drink to Kamikaze pilots
    > before their final flight into glory.


    Note that Kamikaze pilots were not generally ace pilots. They were the
    extremist expendables

    I blame VB6 for allowing questionably skilled computer programmers to
    develop critical applications without enforcing any kind of structured
    design. I've always criticised VB for that, but there has never been a
    popular suitable alternative. Delphi or C++ Builder were probably the best
    alternatives, but were not accepted by industry, largely due to apalling
    marketting decisions by Borland/Inprise/Borland.

    Cheers,
    Jason



  7. #22
    Kunle Odutola Guest

    Re: Microsoft's C++ bigotry

    Jonathan West wrote:

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

    >>
    >> Is Office 10 years old yet?. [The answer is "no" btw, whatever the
    >> software. You rewrite when you need to.]

    >
    > Actually, the answer is yes.


    To Kent's question?. Definitely not. MS deosn't have to rewrite Office every
    10 years.

    > I've been told by people in Microsoft
    > that there is some code in Word and Excel that is so old and patched
    > that nobody dare touch it because nobody knows what it does any more.


    There was a version of Word that was publicly demostrated about 5 years ago
    running on what became the .NET platform. Rumours and facts hey?.

    A simple run through code transformation tools would sort that out. Please
    inform the MS people you know that I'll be able to tell them what the code
    does -- as long as it's C/C++/Pascal/i86-asm. Or they can employ Simonyi's
    IP technology.

    > They
    > wanted new features - effectively a new product with a similar name.
    > That's a perfectly valid business decision, under Microsoft's own
    > control regarding the extent and timing of the rewrite.


    As is the case with VB6-developed products. At least until 2007-8.

    >> So change the tool. The OS has thefeatures but the tool is outdated.
    >> How many people are still using VB1? VB4?

    >
    > So, what should I change VB6 to? What should I change Office VBA to
    > if/when Microsoft drops it?


    VB6 isn't outdated. It's has simply been discontinued.

    What would you change to if MS dropped Windows?. You'll find the best tool
    for what you need to do.

    >>> It IS NOT ACCEPTABLE to have drastic changes to the
    >>> development tools.

    >>
    >> On the contrary. It is necessary that dev tools evolve to be
    >> relevant. Every so often, the change will be drastic or the tool
    >> might become irrelevant.

    >
    > What is VB6 evolving to?


    It has already been [radically] evolved to VB.NET.

    >> Most of MS's code wouldn't "port" to .NET. It would continue to
    >> compile

    > and
    >> run as unmanaged code with VS.NET. MC++ doesn't magically convert
    >> legacy C++ code to .NET assemblies.

    >
    > I think many of MS's customers wish they could say the same of their
    > VB code :-)


    VB1-6 programs run fine as unmanaged code on all relevant editions of
    Windows today (planned until approx 2007-8 for VB6). VS.NET's VB upgrade
    wizard is the one weak link in VB.NET. It is still a work-in-progress so
    watch that space (if you have need of it).

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

    >>
    >> If C/C++ migration support is broken, there will be no VB at all.

    >
    > As VB migration support is broken, there may be few customers to take
    > advantage of it...


    VB.NET represents the best tool upgrade for VB'ers. Some tools offer better
    code upgrade wizards to VB competitors like Delphi at the moment but all
    previous VB experience counts for nothing when using the tools.

    A choice to ignore VB.NET because it has radical differences from VB is
    interesting because whatever else is chosen in it's place is going to be
    even more alien to VB'ers than VB.NET. ;-)

    Kunle


  8. #23
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Thu, 16 Jan 2003 09:39:43 -0500, "Larry Triezenberg" <ltriezenberg@pathsys.com> wrote:

    This seems to be the crux of the folly. There are very few things in VB
    that it was imperative to change. Those few would have been relatively easy
    to accommodate in most cases. This would have greatly increased the
    adoption rate and would have allowed developers and their client community
    to begin utilizing some of the great new features while retaining most of
    their legacy code.

    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. At best I would call them proprietary to the development environment. People wonder why
    C++ folks have it so easy in .NET - it's because the language was far more conducive to porting to
    the .NET environment than VB. While I've never like the C language elements I still believe that its
    implementations have been much better architected and standardized.

    When you consider the number of actual changes to the core language (which many of the VB.NOT folks
    enjoy clamoring about) they amount to a very small and almost insignificant part of the language.
    The largest conversion obstacle is primarily focused on the *extensions* to the language.

    As evidenced in the MID discussion on this group, it is
    possible to implement comparable code using .NET, just not necessarily using
    the prior (existing) syntax. Whether VB will gain enough momentum to
    continue and whether VBA will follow it is an open question, eventually I
    think that it will (in both cases). However, I know a number of developers
    that would be switching now if it meant an upgrade rather than a rewrite.

    As far as Office is concerned it seems rather obvious that there will be a migration path. I don't
    think Microsoft has any choice in this regard:

    http://www.microsoft.com/presspass/p...rtOfficePR.asp


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

  9. #24
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote in
    message news:3e26d7e9@tnews.web.devx.com...
    > Jonathan West wrote:
    >
    > >> Kent wrote:
    > >>
    > >>> You seem to think that "we" are blowing the whole thing out of
    > >>> proportion? I beg to differ. Maybe you can tell me does Microsoft
    > >>> have to completely rewrite office every 10 years?
    > >>
    > >> Is Office 10 years old yet?. [The answer is "no" btw, whatever the
    > >> software. You rewrite when you need to.]

    > >
    > > Actually, the answer is yes.

    >
    > To Kent's question?. Definitely not. MS deosn't have to rewrite Office

    every
    > 10 years.


    My "yes" was the answer to your "Is Office 10 years old yet?"

    I agree that answer to Kent's question is "no". It would be "yes" if Office
    were written in an unstable language...

    >
    > > I've been told by people in Microsoft
    > > that there is some code in Word and Excel that is so old and patched
    > > that nobody dare touch it because nobody knows what it does any more.

    >
    > There was a version of Word that was publicly demostrated about 5 years

    ago
    > running on what became the .NET platform. Rumours and facts hey?.


    So, they recompiled it. Doesn't mean that they dare touch the code.

    >
    > A simple run through code transformation tools would sort that out. Please
    > inform the MS people you know that I'll be able to tell them what the code
    > does -- as long as it's C/C++/Pascal/i86-asm. Or they can employ Simonyi's
    > IP technology.
    >
    > > They
    > > wanted new features - effectively a new product with a similar name.
    > > That's a perfectly valid business decision, under Microsoft's own
    > > control regarding the extent and timing of the rewrite.

    >
    > As is the case with VB6-developed products. At least until 2007-8.
    >
    > >> So change the tool. The OS has thefeatures but the tool is outdated.
    > >> How many people are still using VB1? VB4?

    > >
    > > So, what should I change VB6 to? What should I change Office VBA to
    > > if/when Microsoft drops it?

    >
    > VB6 isn't outdated. It's has simply been discontinued.


    How long before it's outdated? Oh I see. 2007-8. After that I would need to
    find another tool to port to. I can think of two things that are not good in
    that scenario, from Microsoft's point of view.

    1. Between now and 2007-8, they aren't going to be selling VB updates to
    such customers, and so not making any money out of them

    2. If VB.NET is not a suitable upgrage, VB.NET v2 or 3 is hardly likely to
    be more suitable (unless Microsoft has a change of heart), and so the final
    move from VB6 is likely to be to another company's product.

    (And I thought the whole idea of VS.NET was to lure developers *away* from
    competing products. Silly me!)

    --
    Regards
    Jonathan West


  10. #25
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Paul Clement" <UseAdddressAtEndofMessage@swspectrum.com> wrote in message
    news:ssld2vg310pns1j597n1tga2hihlo16vis@4ax.com...
    > On Thu, 16 Jan 2003 09:39:43 -0500, "Larry Triezenberg"

    <ltriezenberg@pathsys.com> wrote:
    >
    > This seems to be the crux of the folly. There are very few things in VB
    > that it was imperative to change. Those few would have been relatively

    easy
    > to accommodate in most cases. This would have greatly increased the
    > adoption rate and would have allowed developers and their client

    community
    > to begin utilizing some of the great new features while retaining most

    of
    > their legacy code.
    >
    > 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. At best I would call them proprietary to the development

    environment.

    That won't wash I'm afraid. Certainly the Ruby platform was coming apart at
    the seams and needed to be replaced, but many of the changes to the language
    were to elements that were much older than Windows, and in no way
    proprietary to Microsoft. They had worked largely unchanged with other
    versions of BASIC pre-Windows, on other platforms including mainframes.
    There was nothing about those aspects of the language that required a
    change - yet Microsoft changed them.

    --
    Regards
    Jonathan West


  11. #26
    Rune Bivrin Guest

    Re: Microsoft's C++ bigotry

    Mike Mitchell <kylix_is@yahoo.co.uk> wrote in
    news:km3d2vghire5hrcrqm1iufpahol8kjhdnm@4ax.com:

    > On 15 Jan 2003 18:11:51 -0800, "Kent" <kp@kp.com> wrote:
    >
    >>I'm pro VB just not VB.Net and I used to wave the Microsoft flag as
    >>high as any of "you" did.

    >
    > I wave it, too. But I spell it with an i.
    >
    > MM
    >


    What on earth is a "flig"? Or Microsift? or Micrisoft? Or do you mean you
    spell "it" with an i? If so, what's so fundamentally special about that,
    that you feel the need to share that information with us?

    --
    Rune Bivrin
    - OOP since 1989
    - SQL Server since 1990
    - VB since 1991

  12. #27
    Kunle Odutola Guest

    Re: Microsoft's C++ bigotry

    Jonathan West wrote:

    >>>> Is Office 10 years old yet?. [The answer is "no" btw, whatever
    >>>> the software. You rewrite when you need to.]
    >>>
    >>> Actually, the answer is yes.

    >>
    >> To Kent's question?. Definitely not. MS deosn't have to rewrite
    >> Office every 10 years.

    >
    > My "yes" was the answer to your "Is Office 10 years old yet?"


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

    > I agree that answer to Kent's question is "no". It would be "yes" if
    > Office were written in an unstable language...


    It is written in a number of languages. How you define unstable is up to
    you.

    >> There was a version of Word that was publicly demostrated about 5
    >> years

    > ago
    >> running on what became the .NET platform. Rumours and facts hey?.

    >
    > So, they recompiled it. Doesn't mean that they dare touch the code.


    A recompile wouldn't run on the platform. It will just be another unmanaged
    app.

    >> VB6 isn't outdated. It's has simply been discontinued.

    >
    > How long before it's outdated? Oh I see. 2007-8. After that I would
    > need to find another tool to port to. I can think of two things that
    > are not good in that scenario, from Microsoft's point of view.
    >
    > 1. Between now and 2007-8, they aren't going to be selling VB updates
    > to such customers, and so not making any money out of them


    Lots of VB.NET, C#, MC++, J# etc customers. MS can't make money out of
    everyone.

    > 2. If VB.NET is not a suitable upgrage, VB.NET v2 or 3 is hardly
    > likely to be more suitable (unless Microsoft has a change of heart),
    > and so the final move from VB6 is likely to be to another company's
    > product.


    VB.NET is a suitable upgrade. Most of the furore have really been about it's
    upgrade wizard's performance. That would improve in time.

    > (And I thought the whole idea of VS.NET was to lure developers *away*
    > from competing products. Silly me!)


    I thought it was to produce the best dev toolset on the market (which it
    probably is). Silly me.

    Kunle


  13. #28
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 16 Jan 2003 07:59:15 -0000, "Kunle Odutola"
    <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:

    >> Isn't it time for
    >> a complete rewrite of windows? (yes it is, but I won't go there).

    >
    >DOS->Win9x->WinNT. Major/complete rewites. Enough for your you?


    Neither Win9X nor WinNT is a rewrite of DOS, though Win9X is heavily
    dependent on DOS to even work. WinNT was a new design by the VMS folks
    from Digital (Dave Cutler et al).

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

    >
    >So change the tool. The OS has thefeatures but the tool is outdated. How
    >many people are still using VB1? VB4?


    The pertinent question is more one of how many people are still using
    VB6? But why fix something if it ain't broke? By changing it so much
    to make the changed product a different, a new product?

    >> It IS NOT ACCEPTABLE to have drastic changes to the
    >> development tools.

    >
    >On the contrary. It is necessary that dev tools evolve to be relevant.


    Who sez? The Great Kunle?!! This sounds like an edict to me.

    > Every
    >so often, the change will be drastic or the tool might become irrelevant.


    How many tools have become irrevelant? C? C++? Assembler? Pascal?
    COBOL? VBc? JavaScript? Java? Php? SQL? Imagine a 'changed' SQL with,
    say, MyStoredProc.Query.Select in place of SELECT! Sure, you can
    'change' just about anything. Thing is, did it really achieve
    anything? In the case of VB.Net I think the answer we're looking for
    is... nope!

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

    >
    >Most of MS's code wouldn't "port" to .NET. It would continue to compile and
    >run as unmanaged code with VS.NET. MC++ doesn't magically convert legacy C++
    >code to .NET assemblies.


    Oh, so it's okay for precious little Microsoft and its 'unmanaged'
    code to carry on compiling, while the millions of VB programmers who
    helped to make Windows and Office great are just thrown in at the deep
    end and told to RTFM?

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

    >
    >If C/C++ migration support is broken, there will be no VB at all.


    There is no VB at all! It's dead, deceased, passed on, no more! Oh,
    sorry, you're talking up the Java version again, aren't you?

    MM

  14. #29
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 16 Jan 2003 16:18:05 -0000, "Kunle Odutola"
    <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:

    >VB6 isn't outdated. It's has simply been discontinued.


    'Zactly! Simply! As in: "We piss on your grave!"

    MM

  15. #30
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 16 Jan 2003 16:18:05 -0000, "Kunle Odutola"
    <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:

    >A choice to ignore VB.NET because it has radical differences from VB is
    >interesting because whatever else is chosen in it's place is going to be
    >even more alien to VB'ers than VB.NET. ;-)


    Yeah, but at least it gives one the satisfaction of not giving
    Microsoft the satisfaction!

    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