Microsoft's C++ bigotry - Page 13


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 13 of 43 FirstFirst ... 3111213141523 ... LastLast
Results 181 to 195 of 633

Thread: Microsoft's C++ bigotry

  1. #181
    Dave Guest

    Re: Microsoft's C++ bigotry


    Paul Clement <UseAdddressAtEndofMessage@swspectrum.com> wrote:
    >Well Mid is supported but once again you may want to indicate specifically

    what you
    >are doing. It
    >could simply be the .NET environment and not the actual function. And, it's

    possible
    >the VB.NET
    >variation may be relatively easy to implement with a performance improvement.
    >Paul ~~~ pclement@ameritech.net
    >Microsoft MVP (Visual Basic)


    Hey, if you have any pull with MS (I assume that's what Microsoft MVP means
    ..), ask them to just confer with some of the members of the old VB6 development
    team to find out how to get Mid and ReDim performing acceptably. Although
    a lot of people mention the poor performance of Mid, ReDim is even slower.
    It may be discouraging to some people to port an app to VB.NET and then find
    out that extensive array usage is penalized.
    I found an ugly hack around the problem (by redimming in large blocks), but
    if Microsoft just fixes the **** thing we won't need the hacks.




  2. #182
    Kent Guest

    Re: Microsoft's C++ bigotry


    Pat,

    It should have been a no brainer for the monopolists to realize all by them
    selves that a VB7 with managed extensions was needed. The fact that they
    didn't provide a migration path then and still don't today speaks volumes
    to the level of commitiment they have provided to the VB community.

    They don't listen and they don't care... yet. If things keep going the way
    they are, they soon will. You're defense of them is not helping any. Admit
    the problems exist and say you won't stand for it. Point out the alternatives...
    Hit em where it hurts most, that's how you make change.

    Kent

    "Patrick Troughton" <Patrick@Troughton.com> wrote:
    >
    >"Jonathan West" <jwest@mvps.org> wrote:
    >>
    >>
    >>I don't think anybody would have complained if a compatible language had
    >>been provided in addition to VB.NET. The problem is that option was not

    >on
    >>offer from Microsoft.

    >
    >No, but did the .NOTters ever ask for a VB7 with Managed Extensions? No,
    >they focused their attention on two strategies...
    >
    >1 - Compromising the VB.NET language (such as adding GoSub and getting rid
    >of BitAnd, BitOr, etc.)
    >2 - Rejecting the whole concept of .NET itself.
    >
    >The first strategy only succeeded in pissing off the pro-.NET folks which
    >split the VB community in two.
    >
    >The second strategy was even more stupid than the first. It succeeded in
    >pissing almost everyone off, pro-VB.NETters and MS. In fact, it alienated
    >MS - the very people they wanted to help them. Even the ".NOT" phrase they
    >thought they so cleverly coined worked against them.
    >
    >Both were self-defeating, and doomed to failure. The .NOTters should have
    >pursued a third strategy...
    >
    >3 - VB7 with Managed Extensions.
    >
    >...Almost no VB.NET programmer would have objected to this option. The .NOTters
    >would have got the compatible language they wanted, and the VB.NETters would
    >have got the no-holds barred language they wanted. The VB community would
    >never have been split in two. Plus, rather than a condemnation of .NET,

    a
    >VB7 with Managed Extensions would actually be considered an endorsement

    of
    >.NET while still retaining "language stability". The .NOTters were their
    >own worst enemy.
    >
    >Would MS have listened? Maybe they would have, maybe no. I don't know. But
    >since it was never tried, we never found out.
    >
    >There's more I wish I could say, but I'm under NDA....
    >
    >/Pat
    >---------------------------
    >It's the platform, stupid.
    >---------------------------



  3. #183
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Patrick Troughton" <Patrick@Troughton.com> wrote in message
    news:3e2ea0c1$1@tnews.web.devx.com...
    >
    > "Jonathan West" <jwest@mvps.org> wrote:
    > >
    > >
    > >I don't think anybody would have complained if a compatible language had
    > >been provided in addition to VB.NET. The problem is that option was not

    > on
    > >offer from Microsoft.

    >
    > No, but did the .NOTters ever ask for a VB7 with Managed Extensions? No,
    > they focused their attention on two strategies...


    To be honest, until VB.NET actually hit commercial release, asking for yet
    another language to be added in parallel to VB.NET was hardly the best and
    most practical way forward, and would have been laughed out of court by MS.
    The idea is only being talked about now because it's now too late to go back
    and remake VB.NET with the proper compatibility it ought to have had in the
    first place. if they went back and changed VB.NET, those who went with it in
    v1 would come up with exactly the same arguments that the .notters expressed
    during the beta.

    >
    > 1 - Compromising the VB.NET language (such as adding GoSub and getting rid
    > of BitAnd, BitOr, etc.)


    If you go back through the threads, you'll find that the beta 2 changes were
    decidedly *not* what was asked for - by anyone!

    > 2 - Rejecting the whole concept of .NET itself.


    No, this is a misunderstanding of the position of those who were arguing for
    compatibility (with the exception of MM). You are failing to make the
    distinction between language and platform again. Several times, Karl and
    others said words to the effect of "We like the idea of .Net. We just wish
    that Microsoft had included Visual Basic in it". The key point was that
    VB.NET had so many changes to core language elements that for all practical
    purposes it was a new language and should be given a new name. That was the
    origin of the "Visual Fred" name coined by Bill Vaughn.

    The argument was never against the dotnet platform itself. I suspect that
    some of the netters knew this perfectly well, and deliberately chose to
    characterise the argument as pro/anti dotnet in order to portray the notters
    as a bunch of reactionary old gits who didn't want to keep up with progress,
    or were afraid of losing their VB guru status.

    >
    > The first strategy only succeeded in pissing off the pro-.NET folks which
    > split the VB community in two.


    The split divided the community fairly neatly into the following groups

    1. Those who had created substantial VB5/6 apps and were responsible for
    maintaining and extending them,

    2. Those who hadn't ever created substantial apps in VB5/6, or had created
    them but were not responsible for their further development.

    I won't say that absolutely every member of the two groups conformed to
    those descriptions, but I've described the characteristics of the large
    majority. Also, there were occasional mavericks such as Bill Storage, who
    had code and wanted Microsoft to break it, but overall, those two groups
    defined the argument.

    The requirements of the two groups were incompatible with each other, and so
    at best Microsoft could only keep one group happy with any decision on the
    syntax of a single version of VB. Microsoft tried to keep both groups happy
    with the beta 2 rollbacks, and simply enraged everyone, not least with their
    lack of decisiveness on an issue which really admitted of no compromise.

    Microsoft had to choose to meet the requests of one and ignore the requests
    of the other, or go with two completely separate languages in addition to
    C#. Which group (if their requirements were met) was in a better position to
    help Microsoft assure the overall success of the .Net platform by bringing
    substantial apps to it in a short time? The anser to that question should
    have been the deciding factor in how Microsoft proceeded. It is still the
    key point in how Microsoft should go on from here.

    >
    > The second strategy was even more stupid than the first. It succeeded in
    > pissing almost everyone off, pro-VB.NETters and MS. In fact, it alienated
    > MS - the very people they wanted to help them. Even the ".NOT" phrase they
    > thought they so cleverly coined worked against them.
    >
    > Both were self-defeating, and doomed to failure. The .NOTters should have
    > pursued a third strategy...
    >
    > 3 - VB7 with Managed Extensions.
    >
    > ..Almost no VB.NET programmer would have objected to this option. The

    ..NOTters
    > would have got the compatible language they wanted, and the VB.NETters

    would
    > have got the no-holds barred language they wanted. The VB community would
    > never have been split in two. Plus, rather than a condemnation of .NET, a
    > VB7 with Managed Extensions would actually be considered an endorsement of
    > NET while still retaining "language stability". The .NOTters were their
    > own worst enemy.
    >
    > Would MS have listened? Maybe they would have, maybe no. I don't know. But
    > since it was never tried, we never found out.


    It was tried - but the pro vb.netters characterised their arguments in the
    way you have in this post.

    >
    > There's more I wish I could say, but I'm under NDA....


    You've probably broken NDA by even admitting that :-)

    --
    Regards
    Jonathan West


  4. #184
    David Rothgery Guest

    Re: Microsoft's C++ bigotry


    "Gary Nelson" <gn@contanet.es> wrote in message
    news:3e2e5706@tnews.web.devx.com...
    > David,
    >
    > > Because in a language strictly tied to a platform,

    >
    > In a world tending toward platform independent languages that is a null
    > argument. So when Windows 64 comes out we change all the definitions

    again?

    Perhaps, though 32-bit values on most 64-bit platforms don't have the
    performance issues that 16-bit values do on most 32-bit platforms (certainly
    the Itanium and the Athlon 64/Opteron don't).

    > > Integer should be the optimal integer size on the platform

    >
    > Why?


    Because a type called Integer (or int, in the C-style world, or whatever
    keyword has a name that strongly suggests 'default integeral data type') is
    the integer type that's going to be used most of the time, and library
    functions that require an integral type as a parameter will take one; it
    doesn't make sense to delibrately de-optimize code.

    > > (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).

    >
    > Excuse me, but that is abusrd. No one is talking about making them work
    > behind the scene as something else.


    Jonathan West suggested exactly that, as a hack to get around the
    performance issues caused by using 16-bit values extensively on 32-bit
    systems.

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

    >
    > As if there are no errors waiting to happen in VB.Net.


    Of course there are; no language is perfect (and some of the language design
    errors in VB.NET are a direct result of trying to maintain backward
    compatibility).

    But defaulting to pass by reference, GOTOs, GOSUBs, C-style pointers, and
    self-modifying code are gotchas that are pointed out in every freshman CS
    student's first or second programming class. And when you're making radical
    changes to a language anyway (completely changing the core libraries for
    GUIs, database access, IO, web programming, string handling, collections,
    and a host of other things; adding full OOP support; changing from reference
    counting to garbage collection; changing from On Error-style error handling
    to exception handling), you might as well fix obvious design errors. The
    VB.NET team went a long way there, though not quite far enough IMO (see the
    Beta 2 rollbacks, changing Wend to End While instead of just dropping the
    construct entirely [as it's completely redundant with Do While/Loop]).

    --
    Dave Rothgery
    drothgery@alum.wpi.edu



  5. #185
    Dan Barclay Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 07:50:32 -0600, Paul Clement
    <UseAdddressAtEndofMessage@swspectrum.com> wrote:

    >On Wed, 22 Jan 2003 09:15:16 -0000, "Gary Nelson" <gn@contanet.es> wrote:
    >
    >
    > That's funny, because my main problems are with changes in the core
    > language. Because I've been programming for a very long time (since
    > gwbasic), and have had plenty of problems with third party tools, I
    > generally do most of my programming in the core language.
    >
    > Problem one: Gosub
    >
    > I've got a truckload of Gosubs, about a thousand in just one program.
    > Whether you like it or not, until VB.Net Gosub was part of the core
    > language.
    >
    >It was one of the few language elements to go. Microsoft has been more or less de emphasizing this
    >construct for years and never optimized it for Visual Basic:
    >
    >PRB: Poor Performance with the GoSub Statement
    >http://support.microsoft.com/default...b;en-us;174808


    The poor performance is a direct result of the implementation hack
    they installed at (as I recall) about VB4. It has nothing to do with
    GoSub inherently. In fact, in earlier versions (particularly in real
    compiled code of the DOS versions) GoSub was *much* faster than a Sub
    or Function. It compiled to a masm Call/Ret pair.

    Instead of using the pseudostack hack they came up with they could
    have picked any number of other implementation methods including
    straight code substitution (like a macro) in which there would be
    *zero* call overhead.

    Do not confuse performance with behavior. Behavior is a result of
    implementation design decisions.

    Gary is not alone, by a long shot, in his use of GoSub. It's a useful
    construct. Like *any* other, it can be misused (care to survey .cls
    files of typical projects???). If you've never learned to use GoSub
    (or classes!) properly, that's unfortunate but it does not mean they
    are bad things that you should expect Microsoft to protect you from.

    Duplicate code fragments are a virus in code that lives through years
    of maintenance. It's a hard fact that, at some point, one copy of the
    fragment will be fixed or enhanced and others will be missed. Its
    proper usage is as a code-only container for eliminating duplicate
    code fragments.

    FWIW, Delphi provides almost a direct replacement using their nested
    procedures.

    By the way, 2 years ago I was told by MS that GoSub was cut due to
    lack of time to get in implemented... then I was told it was dropped
    on purpose. Dunno which is right.

    >In most instances it can be easily replaced by a Sub or Function. If performance was an issue, as
    >you indicate in your following points, I'm surprised that you continued to use GoSub.


    In most places I use them it would require extensive parameter lists.
    The idea is to eliminate duplicated code fragments for maintenance
    reasons, but to replace them with equally long parameter lists or,
    (God forbid) module level variables would only trade one problem for
    another.

    >
    >
    > Problem three: Mid$
    >
    > Four hundred times slower in VB.Net. I make extensive use of Mid$. All
    > routines that use Mid$ must be rewritten. Is not Mid$ part of the core
    > language?
    >
    >Well Mid is supported but once again you may want to indicate specifically what you are doing. It
    >could simply be the .NET environment and not the actual function. And, it's possible the VB.NET
    >variation may be relatively easy to implement with a performance improvement.


    Hmmm... if they've made Mid$() slow, using your argument of GoSub,
    perhaps this means they're about to drop it?

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  6. #186
    Tom Shelton Guest

    Re: Microsoft's C++ bigotry


    "Dave" <dave_doknjas@yahoo.ca> wrote in message
    news:3e2ead07$1@tnews.web.devx.com...
    >
    > Paul Clement <UseAdddressAtEndofMessage@swspectrum.com> wrote:
    > >Well Mid is supported but once again you may want to indicate

    specifically
    > what you
    > >are doing. It
    > >could simply be the .NET environment and not the actual function. And,

    it's
    > possible
    > >the VB.NET
    > >variation may be relatively easy to implement with a performance

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

    >
    > Hey, if you have any pull with MS (I assume that's what Microsoft MVP

    means
    > .), ask them to just confer with some of the members of the old VB6

    development
    > team to find out how to get Mid and ReDim performing acceptably. Although
    > a lot of people mention the poor performance of Mid, ReDim is even slower.
    > It may be discouraging to some people to port an app to VB.NET and then

    find
    > out that extensive array usage is penalized.
    > I found an ugly hack around the problem (by redimming in large blocks),

    but
    > if Microsoft just fixes the **** thing we won't need the hacks.


    That's not a hack... ReDim maybe slightly slower in VB.NET, but it is also
    slow in VB6 especially as your array gets larger. It has never been good
    practice to ReDim arrays 1 element at a time. And if you want a dynamic
    container - System.Collections.ArrayList.

    I'm sorry, but for the most part, I find .NET to be just as fast or faster
    in some cases. It usually comes down to changing the way you do things.
    Take file I/O. Gary keeps complaining about how slow it is - and it is if
    you use the VB.NET intrinsic functions. But if you take the time to figure
    out the stream classes in System.IO, which are not all that difficult, then
    you would find that it is just as fast. The platform has changed, and
    performance optimizations that worked in the old environment don't
    necesarrily work in .NET.

    Tom Shelton



  7. #187
    Dan Barclay Guest

    Re: Microsoft's C++ bigotry


    >a small but vocal minority
    >of idiotic .NOTters like DB, KP, MM, GN


    Hey! A promotion! I get to change my number!

    Thanks!

    Dan (#1 now!)
    Language Stability is a *feature* I wish VB had!
    (#6)
    Error 51
    Error 3
    Error 9
    ....

  8. #188
    Patrick Troughton Guest

    Re: Microsoft's C++ bigotry


    Hi Kent,

    You're deluding yourself if you think VB.NET isn't here to stay. The fact
    is that .NET is already success, and getting bigger and bigger every day.
    Every month, more and more companies are adopting .NET. Just in the last
    few weeks....

    Allstate Insurance....
    http://www.microsoft.com/resources/c...eStudyID=13648

    CNET...
    http://www.microsoft.com/resources/c...eStudyID=13550

    Nasdaq Stock Market, Inc....
    http://www.microsoft.com/resources/c...eStudyID=13543

    Volvo Cars....
    http://www.microsoft.com/resources/c...eStudyID=13469

    This is in addition to the hundreds and hundreds of companies who are already
    using .NET.

    In fact, .NET is now being used for everything from web sites to nuclear-powered
    aircraft carriers (PC Magazine, "Mobile Application Tools", October 15th,
    2002).

    I can personally say that I know of another huge company that started on
    a *major* VB.NET project just a few weeks ago. I can't give out the name,
    but it has over 5,000 stores in 60 different countries throughout the world.
    I can almost guarantee that everyone in this newsgroup has heard of it, and
    has probably shopped there a few times, too. I suspect that when the app
    is done, you will probably hear about it somewhere. I'm not under NDA with
    this company, but I'll let them announce it when they're ready.

    Even software vendors are embracing .NET because it's so much easier to work
    with....
    http://news.devx.com/cgi-bin/dnewswe...em=45350&utag=

    ZDNET reports that .Net is one of the top job skills in demand....
    http://zdnet.com.com/2100-1104-978922.html

    .NET has won numerous industry awards...

    PC Magazine's 18th Annual Technical Excellence Awards
    Best Development Tool: Visual Studio .NET
    http://www.pcmag.com/article2/0,4149,140708,00.asp

    Software Development Magazine
    Jolt Award for Best Libraries, Frameworks, and Components Microsoft .NET
    Framework
    http://www.sdmagazine.com/jolts/

    Productivity Award for Best Languages and Development Environments Microsoft
    Visual Studio .NET http://www.sdmagazine.com/jolts/

    Those of you who have read my posts before know that I have few friends and
    family in the IT industry. Just this weekend, I met up with a couple friends
    from a consulting firm. They tell me that their .NET business is booming
    and that their bench is filled with Java programmers who are starting to
    worry that they don't have any clients.

    I've been one of VB.NET's biggest supporters (beta 2 rollbacks notwithstanding)
    since Day One and .NET has exceeded even my expectations.

    Kent, I'm not going to argue with you. If there's one thing I've learned
    from this newsgroup is that people make up their minds before posting, and
    rarely change them, no matter what you say or how much proof you have.

    So this will be my last post to this thread. If you're anything like the
    other .NOTters, you will probably want to flame me or resort to personal
    insults since .NOTters were never able to defend their ideas with logic or
    facts.

    The only thing I can say is if the .NOTters had listened to me two years
    ago, they would be laughing all the way to the bank, too. And if they don't
    start picking up .NET, they shouldn't be surprised when they're out of a
    job a few years from now....

    Later....

    /Pat
    --------------------------
    It's the platform, stupid.
    --------------------------

    "Kent" <KP@KP.org> wrote:
    >
    >Pat,
    >
    >It should have been a no brainer for the monopolists to realize all by them
    >selves that a VB7 with managed extensions was needed. The fact that they
    >didn't provide a migration path then and still don't today speaks volumes
    >to the level of commitiment they have provided to the VB community.
    >
    >They don't listen and they don't care... yet. If things keep going the

    way
    >they are, they soon will. You're defense of them is not helping any. Admit
    >the problems exist and say you won't stand for it. Point out the alternatives...
    > Hit em where it hurts most, that's how you make change.
    >
    >Kent



  9. #189
    Kent Guest

    Re: Microsoft's C++ bigotry


    "David Rothgery" <drothgery@alum.wpi.edu> wrote:
    >But defaulting to pass by reference, GOTOs, GOSUBs, C-style pointers, and
    >self-modifying code are gotchas that are pointed out in every freshman CS
    >student's first or second programming class. And when you're making radical
    >changes to a language anyway (completely changing the core libraries for
    >GUIs, database access, IO, web programming, string handling, collections,
    >and a host of other things; adding full OOP support; changing from reference
    >counting to garbage collection; changing from On Error-style error handling
    >to exception handling), you might as well fix obvious design errors. The
    >VB.NET team went a long way there, though not quite far enough IMO (see

    the
    >Beta 2 rollbacks, changing Wend to End While instead of just dropping the
    >construct entirely [as it's completely redundant with Do While/Loop]).


    Then they should not have called it VB since calling it VB provides some
    some hope of backward compatibility. They also should have provided VB7
    with managed extensions as Dan and others have suggested. What we have not
    is not acceptable. The jobmarket for VB.Net and overall lack of interest
    in it shows this. The MVP crowd may have talked themselves out of work.


  10. #190
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 11:08:24 -0600, Dan Barclay <Dan@MVPs.org> wrote:


    >
    >It was one of the few language elements to go. Microsoft has been more or less de emphasizing this
    >construct for years and never optimized it for Visual Basic:
    >
    >PRB: Poor Performance with the GoSub Statement
    >http://support.microsoft.com/default...b;en-us;174808

    The poor performance is a direct result of the implementation hack
    they installed at (as I recall) about VB4. It has nothing to do with
    GoSub inherently. In fact, in earlier versions (particularly in real
    compiled code of the DOS versions) GoSub was *much* faster than a Sub
    or Function. It compiled to a masm Call/Ret pair.

    Instead of using the pseudostack hack they came up with they could
    have picked any number of other implementation methods including
    straight code substitution (like a macro) in which there would be
    *zero* call overhead.

    Do not confuse performance with behavior. Behavior is a result of
    implementation design decisions.

    Correct. The decision was to de emphasize its usage, which is one of the reasons they suggest using
    Subs and Functions as they had no plans on optimizing it.


    Gary is not alone, by a long shot, in his use of GoSub. It's a useful
    construct. Like *any* other, it can be misused (care to survey .cls
    files of typical projects???). If you've never learned to use GoSub
    (or classes!) properly, that's unfortunate but it does not mean they
    are bad things that you should expect Microsoft to protect you from.

    I used it in old line coded basic, which had no Subs or Functions, but there was never any reason to
    use it in QuickBASIC or any variant of the structured BASIC language. It is outdated just as GoTo
    is.


    Duplicate code fragments are a virus in code that lives through years
    of maintenance. It's a hard fact that, at some point, one copy of the
    fragment will be fixed or enhanced and others will be missed. Its
    proper usage is as a code-only container for eliminating duplicate
    code fragments.

    Problem is it isn't a container but a containee that affects the flow of logic within its container.
    It causes the code to branch down and then back up through the code in its container - a prime
    example of spaghetti code.


    FWIW, Delphi provides almost a direct replacement using their nested
    procedures.

    By the way, 2 years ago I was told by MS that GoSub was cut due to
    lack of time to get in implemented... then I was told it was dropped
    on purpose. Dunno which is right.

    >In most instances it can be easily replaced by a Sub or Function. If performance was an issue, as
    >you indicate in your following points, I'm surprised that you continued to use GoSub.

    In most places I use them it would require extensive parameter lists.
    The idea is to eliminate duplicated code fragments for maintenance
    reasons, but to replace them with equally long parameter lists or,
    (God forbid) module level variables would only trade one problem for
    another.

    Well I think you know from our past discussions that I will never buy this. First GoSub is a
    branching mechanism. Branch and returns (used instead of Subs and Functions) lead to some rather
    confusing and difficult to debug code. It also unnecessarily increases the size of Subs and
    Functions, causing the same types of problems.

    If you are worried about long parameter lists, you can use a parameter array.


    >
    >
    > Problem three: Mid$
    >
    > Four hundred times slower in VB.Net. I make extensive use of Mid$. All
    > routines that use Mid$ must be rewritten. Is not Mid$ part of the core
    > language?
    >
    >Well Mid is supported but once again you may want to indicate specifically what you are doing. It
    >could simply be the .NET environment and not the actual function. And, it's possible the VB.NET
    >variation may be relatively easy to implement with a performance improvement.

    Hmmm... if they've made Mid$() slow, using your argument of GoSub,
    perhaps this means they're about to drop it?

    Yes, but the migration path for those Visual Basic functions are likely to remain for quite a while
    (as they did for GoSub in "Classic" VB).


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

  11. #191
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On 22 Jan 2003 09:23:14 -0800, "Kent" <KP@KP.com> wrote:

    >Then they should not have called it VB since calling it VB provides some
    >some hope of backward compatibility. They also should have provided VB7
    >with managed extensions as Dan and others have suggested. What we have not
    >is not acceptable. The jobmarket for VB.Net and overall lack of interest
    >in it shows this. The MVP crowd may have talked themselves out of work.


    Ah, but they *always* know best, don't they?

    MM

  12. #192
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 07:50:32 -0600, Paul Clement
    <UseAdddressAtEndofMessage@swspectrum.com> wrote:

    >In most instances it can be easily replaced by a Sub or Function. If performance was an issue, as
    >you indicate in your following points, I'm surprised that you continued to use GoSub.


    It could be replaced by a Sub or a Function, but that would be to
    completely miss the point of GoSub! The one way GoSub was extremely
    useful was when you had a piece of standard code in a procedure and
    you had to execute it again and again. However, suppose the code in
    question utilised several variables. If you were to write a separate
    Sub or Function, you'd have to pass arguments representing those
    variables. This is quite a significant overhead if you're executing
    the same bit of code ten times throughout that one procedure. And so
    you use GoSub instead. Because GoSub can only sit somewhere inside
    your procedure (I tuck mine away at the bottom, following the error
    hander), it is "global" to the procedure. That is, whatever variables
    are active inside the procedure are automatically available to the
    GoSub code.

    So you can replace the several lines of code at multiple places in
    your procedure with just a GoSub MyRoutine, and it makes the code far
    more readable. Also, no overhead is lost through continually passing
    arguments to a Sub or Function which would have to be called again and
    again instead of using GoSub.

    This is why GoSub was and is absolutely the right choice in certain
    circumstances.

    MM

  13. #193
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 01:19:51 +1100, Jason Sobell iGadget
    <igadget_@hotmail.com> wrote:

    >How often do you call a function that takes and returns no parameters? This
    >is the only time GoSub can be used, unless you are storing your data in
    >global variables


    Eh? I don't think you can quite understand how GoSub is used! You just
    whack a chunk of code at the foot of your procedure (could be
    elsewhere, but that's where I place it), stick a label at the start
    and a Return at the end. Then you GoSub LabelName, the code in the
    GoSub block is executed and hits Return, sending you back to the
    statement following the GoSub call. All variables known to the
    procedure which contains your GoSub code are also known to the GoSub
    code, i.e. you don't have to pass anything!

    However, if instead of GoSub you wrote a separate Sub or Function,
    you'd have to pass arguments to it to replicate the variables which
    are already known within your procedure. So, if you needed to execute
    some standard piece of code ten times as your procedure is being
    executed overall (we're not in the GoSub code yet!), you have three
    choices: (a) Duplicate the code throughout the procedure, (b) Call a
    GoSub block, or (c) Call an external Sub or Function. Sometimes option
    c is right; sometimes option b is very handy. Option a is almost never
    wise.

    MM

  14. #194
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 12:34:19 -0000, "Jonathan West" <jwest@mvps.org>
    wrote:

    >Simply stated in terms of the way they are presented in the language, that
    >would be the object model that accesses the .Net framework.


    But surely that would require a "VB7 with Managed Extensions" to be
    pretty much what VB.Net is already? If it's going to be able to
    understand the .Net framework, I mean.

    MM

  15. #195
    Dan Barclay Guest

    Re: Microsoft's C++ bigotry

    On Wed, 22 Jan 2003 14:19:34 -0600, Paul Clement
    <UseAdddressAtEndofMessage@swspectrum.com> wrote:

    >Correct. The decision was to de emphasize its usage, which is one of the reasons they suggest using
    >Subs and Functions as they had no plans on optimizing it.


    LOL. Your argument is that they made it slow on purpose? Ya know,
    before VB7 came out I wouldn't have believed this but now you've
    cleared up a lot of confusion for me.

    I was misinformed that they accidentally created an ugly hack to get
    around With and some other gotcha's, then were too scared to touch it
    once they got it working. Silly me for believing that!

    They kinda backed themselves into that hack because of the
    interpreter. The sad part is that, now that they're using a pure
    compiler, they could have gone to source substitution. It would have
    been dead simple, and performance overhead would have been zero.
    ****, I offered to implement it if they'd provided a preprocessor
    hook(s) for the Basic[sic] compiler.

    Again, silly me, I didn't realize that they wanted to sabotage it!
    So, *** do I know!

    > Gary is not alone, by a long shot, in his use of GoSub. It's a useful
    > construct. Like *any* other, it can be misused (care to survey .cls
    > files of typical projects???). If you've never learned to use GoSub
    > (or classes!) properly, that's unfortunate but it does not mean they
    > are bad things that you should expect Microsoft to protect you from.
    >
    >I used it in old line coded basic, which had no Subs or Functions, but there was never any reason to
    >use it in QuickBASIC or any variant of the structured BASIC language. It is outdated just as GoTo
    >is.


    Oh, so GoTo is scheduled for removal? Didn't know that. I suppose it
    makes about as much sense though. I've been outta touch but I'm glad
    you're keeping up with 'em.

    > Duplicate code fragments are a virus in code that lives through years
    > of maintenance. It's a hard fact that, at some point, one copy of the
    > fragment will be fixed or enhanced and others will be missed. Its
    > proper usage is as a code-only container for eliminating duplicate
    > code fragments.
    >
    >Problem is it isn't a container but a containee that affects the flow of logic within its container.


    Certainly it is a container, and it works quite well. You *really*
    should learn something about it.

    >It causes the code to branch down and then back up through the code in its container - a prime
    >example of spaghetti code.


    LOL. You've *got* to be kidding. This is exactly what Subs and
    Functions do, by your definition, except that they also carry their
    own variable space. We've gotta stop that Sub branching, yessireee.

    Hmmm... have you been implementing your GoSubs using GoTo's and
    branches? Like I said, maybe you should learn something about it.

    Sounds like all you want in your toolbox is a hammer. Why do you
    insist that everybody else leave their screwdrivers at home as well?

    >
    > FWIW, Delphi provides almost a direct replacement using their nested
    > procedures.
    >
    > By the way, 2 years ago I was told by MS that GoSub was cut due to
    > lack of time to get in implemented... then I was told it was dropped
    > on purpose. Dunno which is right.
    >
    > >In most instances it can be easily replaced by a Sub or Function. If performance was an issue, as
    > >you indicate in your following points, I'm surprised that you continued to use GoSub.
    >
    > In most places I use them it would require extensive parameter lists.
    > The idea is to eliminate duplicated code fragments for maintenance
    > reasons, but to replace them with equally long parameter lists or,
    > (God forbid) module level variables would only trade one problem for
    > another.
    >
    >Well I think you know from our past discussions that I will never buy this. First GoSub is a
    >branching mechanism.


    Branching mechanism? That's why it was initially implemented with
    Call/Ret, huh?

    >Branch and returns (used instead of Subs and Functions) lead to some rather
    >confusing and difficult to debug code. It also unnecessarily increases the size of Subs and
    >Functions, causing the same types of problems.


    Nope.

    Please see my previous discussion (which you snipped) regarding taking
    the effort to properly use it.

    Oh, and while you're at it maybe you should educate some of the idiots
    on how to use classes before someone gets the bright idea that we
    should be protected from those as well.

    Holy cow! Just think of the crap someone is going to write using
    inheritance!!! ****, I was planning to use that some day and now
    they'll probably remove it because it has sharp edges.

    >If you are worried about long parameter lists, you can use a parameter array.


    Same issue. It adds complexity where none is needed. Keep it
    simple...

    > Hmmm... if they've made Mid$() slow, using your argument of GoSub,
    > perhaps this means they're about to drop it?
    >
    >Yes, but the migration path for those Visual Basic functions are likely to remain for quite a while
    >(as they did for GoSub in "Classic" VB).


    Has MS said to migrate from Mid(), or is that just your opinion?

    Dan
    Language Stability is a *feature* I wish VB had!
    (#6)/(#1!)
    Error 51
    Error 3
    Error 9
    ....

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