Microsoft's C++ bigotry - Page 21


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 21 of 43 FirstFirst ... 11192021222331 ... LastLast
Results 301 to 315 of 633

Thread: Microsoft's C++ bigotry

  1. #301
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Fri, 24 Jan 2003 10:01:09 -0000, "Gary Nelson" <gn@contanet.es>
    wrote:

    >I think that's what we are all saying. How can I get up to speed in .net if
    >I have to spend most of the time in VB6?


    Well, the short answer is, I think, you can't! It's a choice. And that
    is the problem. This morning I received the Feb 2003 issue of Visual
    Systems Journal (www.vsj.co.uk) in which the editorial includes:

    <quote>
    "Windows programmers are being asked to change their model of the
    universe, and they are being sold this idea as something to do with
    XML and Web Services. This is verging on the laugable."
    </quote>

    There is only a certain amount of time in the day and all the while
    programmers have to do a particular job just to keep their heads above
    water, they're not going to be able to allocate time to learning
    something quite different. Even evening classes are done well away
    from work, after one has gone home for a couple of hours (at least),
    had a chance to relax a bit and take the dog for a walk. One needs to
    spend 100% of one's mental resources when learning something new and
    if the commitment (let alone a valid reason) isn't there, then failure
    or confusion is almost inevitable. That is yet another reason why the
    decision to replace VB with VB.Net was daft, as it just doesn't allow
    a seamless, gradual changeover. It's all or nothing from the moment
    you make the decision to switch.

    MM

  2. #302
    Mike Mitchell Guest

    Re: Microsoft's C++ bigotry

    On Fri, 24 Jan 2003 09:59:28 +1100, Jason Sobell iGadget
    <igadget_@hotmail.com> wrote:

    >A new phrase "the .Netizenry"? Defined as "All who do not despise VB.NET"?


    Like the citizenry, but owned by MS....!

    MM

  3. #303
    Mark Hurd Guest

    Re: Microsoft's C++ bigotry

    Mike Mitchell wrote:
    > On Thu, 23 Jan 2003 13:23:53 +1030, "Mark Hurd"
    > <markhurd@ozemail.com.au> wrote:
    >
    > > It *is* a good excuse to rewrite your code, if you can afford it. And,
    > > yes, I expect you'll use less code to produce the same or better result,
    > > but then I'd expect any competent programmer to solve the problem better
    > > the second time around, even if they used VB6 again.

    >

    <SNIP valid description of a common scenario that corresponds to why a company
    cannot afford to rewrite.>

    I said the above because many people defending (selling) .NET say that they're
    pleased with the result of upgrading to .NET because they've got a better
    program with less code. I believe the .NET Framework is a reason for that, but
    so is the fact that you're rewriting the program -- re-solving the problem.

    Regards,
    Mark Hurd, B.Sc.(Ma.) (Hons.)



  4. #304
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

    "Gary Nelson" <gn@contanet.es> wrote
    > > Adding a class...

    >
    > Classes are very useful, but are very different from Gosub
    >
    > Using a class for something like that is overkill, plus it converts a very
    > simple structure (Gosub) into something much more comples (a class)



    Then use a standard module. You are using Gosub because it is
    convenient, not because it is needed. VB has a lot of 'convenient'
    features that should not show up in a well written program....

    LFS




  5. #305
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 20:38:29 -0000, "Jonathan West" <jwest@mvps.org> wrote:


    "Dave" <dave_doknjas@yahoo.ca> wrote in message
    news:3e304d64$1@tnews.web.devx.com...

    > Well... the "first make it work, then make it work well" principle is
    usually
    > applied to code in early development, prior to official release, but I
    guess
    > that's not Microsoft's approach.

    Historically, it's usually been v3 of a product before Microsoft has been
    able to make it work right.

    What I do find interesting though is how Paul shuffles between "its only
    version 1 of a new product, you can't expect much of it" and "its not a new
    language, its an upgrade to an existing one" according to the nature of the
    point he's wanting to answer.

    No shuffling. It's the first version of the next generation of the product just as Visual Basic was
    to BASIC. AFAIK Microsoft named it Visual Basic .NET not Visual Basic 7.0, although it probably
    doesn't matter. It's still an upgrade just as Visual Basic 1.0 was.


    Paul, it's either new or it's not, but unless Microsoft has made a
    breakthrough in quantum computing, it can't both be new and not-new at the
    same time!

    Sure if everything was black or white and there was no in between. It can certainly be a new
    generation of the product without calling it a new language. There's a lot of new, but much of the
    old still remains.


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

  6. #306
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 21:59:10 -0000, "Jonathan West" <jwest@mvps.org> wrote:


    "Phil Weber" <pweber@nospam.fawcette.com> wrote in message
    news:3e305215$1@tnews.web.devx.com...
    > > Paul, it's either new or it's not...
    >
    > Jonathan: I'm Phil. Do you have me confused with Paul?

    In that particular case, yes. However, I'll stand by the statement regarding
    Paul in general terms, given that the following has appeared from him within
    this thread.

    We have these:

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

    "Well first the changes to the actual language were few as I indicated."

    "VB.NET isn't a new language."


    And we have these:

    ""Classic" VB is/was a dead end. Microsoft was unable to evolve it beyond
    what it was. It's a great tool for building Windows desktop apps or COM
    components but that's as far as they were able to go with it. It need to be
    re-architected."

    "You weren't around when VB 1.0 was released were you? It wasn't until
    version 3.0 that it actually started to become popular.
    I don't think it's realistic to expect everyone to jump on the .NET
    bandwagon right away. It simply isn't practical."


    Nothing that I would consider incongruous. Are you reading something into this that isn't written?


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

  7. #307
    Jonathan West Guest

    Re: Microsoft's C++ bigotry


    "Larry Serflaten" <serflaten@usinternet.com> wrote in message
    news:3e314b69@tnews.web.devx.com...
    > "Gary Nelson" <gn@contanet.es> wrote
    > > > Adding a class...

    > >
    > > Classes are very useful, but are very different from Gosub
    > >
    > > Using a class for something like that is overkill, plus it converts a

    very
    > > simple structure (Gosub) into something much more comples (a class)

    >
    >
    > Then use a standard module. You are using Gosub because it is
    > convenient, not because it is needed. VB has a lot of 'convenient'
    > features that should not show up in a well written program....


    Why are you against convenience? It sounds to me as if you think that there
    is One Right Way of writing code, and all alternatives are wrong. Having
    seen code from very many people, ranging from the outstanding to the
    execrable, I have to say that it just isn't true.

    Therefore I am extremely skeptical of people who say you "should not" write
    code a specific way unless there is a tangible reason for it. That reason
    might be in terms of performance, compiled code size or maintainability, but
    there has to *be* a reason.

    --
    Regards
    Jonathan West


  8. #308
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote

    > >It is that 'hurry up' attitude that puts buggy code into the hands of the users.

    >
    > You just cannot say it's wrong, period!


    Yes I can.

    What other industry can tell you, 'You have only purchased a license to
    use the product, you do not own it, and we are not responsible for any
    damages you might suffer from using the product' ?

    Hiding buggy code behind such agreements is absurd. The usual arguement
    is that there is millions of lines of code involved and it is impossible to keep
    all the bugs out. But in the end, who's fault is that?

    Even when the code/application is free, that is not a license to ship low
    quality work. The constant parade of patches we are submitted to is a
    direct result of unsufficient quality control and testing on the part of the
    vendor.

    The situation will not fix itself. Many more vendors and developers have
    to adopt this same opinion before we can apply any amount of trust to
    computing. Consider the amount of trust you have in picking up your
    telephone and getting a dial tone. If you pay your bill, you might not even
    check for the tone before dialing the number you plan to call. How much
    trust do you have in your refrigerator, keeping your food cold? You leave
    it run all day, or may take off for a few days, and still expect your food
    to be cold on your return. There are many such comparisions that could
    be made, but suffice it to say that computing is still a far cry from such
    ubiquity.

    I say thats wrong, if you say it isn't then chances are you'll do nothing to
    make it better. That is also a part of the problem....

    LFS








  9. #309
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 14:18:29 -0600, Dan Barclay <Dan@MVPs.org> wrote:



    >It can't hold data specific to its function and it isn't a parent to its code. It's a code
    >navigational structure.

    The same would be true for masm Call/Ret as well, eh?

    No. A Sub or Function doesn't affect the flow of code (navigation) in the calling routine - it
    simply suspends execution until control is returned. A GoSub/Return does control the flow of
    execution - it is part of the functioning code in the Sub or Function which contains it. That is the
    problem.


    >
    > >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.
    >
    >Nope. They do not inherently branch down, bypassing a chunk of code, and then return when they're
    >finished.

    Really? Every sub/function and GoSub I've seen does exactly this.

    A Sub, Function or method call to an instanced Class does not do this. If you have a snippet code
    that demonstrates your claim you are welcome to post it.


    >I can't imagine that you need to be drawn a road map documenting the flow of logic between a GoSub
    >and Subs or Functions. You've been doing this stuff long enough to know that.

    You're right. I've done it once before, and I understand it fairly
    well. Heck, I even wrote a class once.

    Well then I guess you understand the distinction after all.


    >
    >
    > Hmmm... have you been implementing your GoSubs using GoTo's and
    > branches? Like I said, maybe you should learn something about it.
    >
    >Perhaps you should learn about Subs and Functions so you can discriminate between them and GoSub.
    >Are you finished now?
    >
    >
    > 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?
    >
    >How about using the more efficient tool? Accepting the fact that GoSub was significantly slower
    >(regardless of what MS intended it to be), why still use it? Or do you use a screwdriver to pound in
    >nails?

    If it were fixed (it can be) and were faster than Sub/Function, would
    you argue that I should be using GoSub instead of Sub/Function??

    Nope, because of the inherent problem of creating spaghetti code. And if the GoSub implementations
    you are referring to are as straightforward as you say they are I see no reason why they can't be
    converted to an actual container such as a Sub or Function. If the GoSub implementations are not as
    straightforward, then you will likely have a maintenance problem when someone else has to review
    your code.


    Performance is the decision point only on "hot" code that has high
    impact on your overall app's performance. In the remaining 99.9% of
    code, maintenance and readability are more appropriate decision
    points.

    It's much cheaper to buy the performance that you may sacrifice in order to write more readable
    code, than to pay someone to maintain, convert, or fix code that is difficult to decipher.


    > > 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?
    >
    >Does it matter?

    Only if you think it's a branching mechanism. GoSub does not create a
    logical branch. It executes code as if it were inline, returning to
    the next statement.

    Well no I don't consider a call to a Sub or Function a branching mechanism. Branching occurs within
    a code container.


    >
    >
    > >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.
    >
    >Doesn't matter. As I said before it directly affects the flow of logic in your Sub or Function. The
    >execution of code in the Sub or Function flows in both directions which makes code more difficult to
    >work with.

    Nope, it does not affect the logic.

    I said it affects the "flow" of logic.


    > 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.
    >
    >Except they aren't inherently poor structures.

    That's what you and I think. There are some folks who don't agree
    with us. I've found, from experience, that those folks sometimes get
    the ear of the implementors.

    Well they're wrong. ;-)


    > 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...
    >
    >You use GoSub and you're complaining about complexity? ;-)

    GoSub is a far more simple construct than even Sub/Function, much less
    classes or inheritance. Do not confuse power with simplicity. In
    fact, the more powerful features are generally the more complex.

    I guess we're going to have to just disagree on this point. The concept of GoSub is simple, the
    implementation causes code maintenance headaches.


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

  10. #310
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Fri, 24 Jan 2003 10:42:54 -0000, "Gary Nelson" <gn@contanet.es> wrote:

    Paul,

    > Which is why it isn't a container since entry can be accomplished via a
    branch call or via the
    > sequential execution of code. That is, unless you either skip over the
    GoSub code programmatically
    > or Exit the Function or Sub prior to its execution.

    ????

    All of my Gosubs are below an Exit Sub or Function.

    How could you do it any other way?

    OK, I'm confused. How do you execute a GoSub statement if it's after an Exit Sub or Function. Or do
    you mean that you have a bunch of code in between the GoSub call and the label above the code that
    is to be executed when it is called? So in that case the flow of execution in the Sub or Function
    branches down to execute that code and then returns back up to the line after the GoSub call to
    execute the code in between the GoSub call and the GoSub code at the bottom of the Sub or Function.


    If you do a sequential entry into a Gosub routine you will get a Return
    without Gosub error when it hits the Return.

    Right on that one. Guess it's been a while since I used it. ;-)

    Still not a code container though.


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

  11. #311
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Thu, 23 Jan 2003 21:05:18 +0000, Mike Mitchell <kylix_is@yahoo.co.uk> wrote:

    On Thu, 23 Jan 2003 12:02:40 -0800, "Phil Weber"
    <pweber@nospam.fawcette.com> wrote:

    > > But I'm curious, perhaps you have a machine that computes
    > > differently than most...[run] the code below, and report your
    > > findings, just to check if it matches what the rest of us see...
    >
    >Larry:
    >
    > Gosub took: 1282
    > Subroutine took: 4436

    Thank God! Now, for f***'s sake, let's fuggedabout GoSub for

    >>five ruddy minutes!<


    You misspelled "forever". ;-)


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

  12. #312
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On 23 Jan 2003 11:22:16 -0800, "Kent" <kp@kp.org> wrote:


    If that is the migration path, then no one should be surprised that some existing
    shops and customers refuse to use VB.Net.


    And that's why those of us who support .NET believe that much of the complaining about
    incompatibility is simply a red herring and that the dislike for it extends beyond this issue.


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

  13. #313
    Paul Clement Guest

    Re: Microsoft's C++ bigotry

    On Fri, 24 Jan 2003 11:07:23 -0000, "Gary Nelson" <gn@contanet.es> wrote:


    > The bottom line is that you have a migration path. If the performance of
    Mid is unacceptable you can
    > change it (now or later), but for the time being you have functioning code
    in a VB.NET app. That may
    > not be exactly what you want but its preferable over the functionality
    being dropped altogether.

    The problem is that the performance of my program must at least be
    comparable to the VB6 version when I make the transition in order to please
    my clients. I can't throw a second class program on them and then tell them
    to wait till I get it up to par.

    That's not an uncommon issue when upgrading to a new version of Visual Basic. It happened when
    ActiveX components were introduced to Visual Basic as a replacement for VBXs and Visual Basic became
    COM based.

    Retaining Mid may not be your solution then and in order for the app to be on par performance-wise
    you will need to convert to the newer functions. Or, you stick with Visual Basic 6.0 for the time
    being.


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

  14. #314
    Larry Serflaten Guest

    Re: Microsoft's C++ bigotry

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

    > Why are you against convenience?


    More times than not, it is not needed, and there are better ways to get the
    job done. In the case of Gosub, a separate procedure is often a better
    route. In the case of Variants, strongly typed variables are often a better
    route. There are other such examples...

    > It sounds to me as if you think that there
    > is One Right Way of writing code


    That's your perception, I never said that....


    > Therefore I am extremely skeptical of people who say you "should not" write
    > code a specific way unless there is a tangible reason for it. That reason
    > might be in terms of performance, compiled code size or maintainability, but
    > there has to *be* a reason.


    Take your pick, it is sometimes less performant, and sometimes difficult to
    maintain, depending on how badly it has been abused. You know there is a
    religious admonition agaist using End to stop a program, yet some still have
    to be told not to use End. MS has been hinting Gosub is on its way out
    since about version 4, yet some people still use it....

    <quote>
    Tip Creating separate procedures that you can call may provide a more structured alternative to using GoSub...Return
    </quote>

    How many other help topics do you see where they specifically mention using
    an alternative? (Not many!)

    LFS








  15. #315
    Guest

    Re: Microsoft's C++ bigotry


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >On 23 Jan 2003 11:55:26 -0800, "Bob" <vb.@127.0.0.1> wrote:
    >
    >>So if Mike isn't lying or crazy according to his own statement, he isnt'
    >>developing in VB anymore--any version. Which is it Mike? Are you crazy

    or
    >>just spreading FUD?

    >
    >I'm neither crazy, nor spreading FUD. All I asked was, did anyone test
    >out the claims that GoSub is slower than achieving the same
    >functionality through calling a Sub multiple times and passing maybe a
    >dozen arguments?
    >

    Why don't you test it and find out? That's what real programmers do, Mike.

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