Speaking of strings... - Page 11


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 11 of 17 FirstFirst ... 910111213 ... LastLast
Results 151 to 165 of 247

Thread: Speaking of strings...

  1. #151
    Jason Guest

    Re: Speaking of strings...


    "PWilmarth" <pwilmarth80231@msn.com> wrote:
    >
    >Your answer is rational and reasonable, but remember, the game Mike is playing
    >is to refuse to acknowledge any valid points that you have. Don't know if
    >you have ever watched the debates on MSNBC or CNBC. They argue for the sake
    >of arguing. Doesn't matter if the other side has valid points. If he (or
    >Bill) acknowledge your arguments as valid, the game is over.


    I think you are right. So far, they have managed to avoid or gloss over
    3 or 4 direct questions about object use in VB.

    So I will keep asking the question. If Bill thinks MP is far better than
    OO, and MM agrees, how do they rationalize using all those canned objects
    provided to make form design easier, and to wrap the Windows operating system?
    If they are using VB6, then they are using objects routinely, whether they
    create them or not.

    I think this knocks a big hole in the "MP is great, and OO is useless" argument.
    But MM seems to think that this is a joke, and Bill has thus far simply
    avoided the subject.

    Oh well. I've never met with stone silence from Bill before, so this is
    an interesting topic. I think I will stick with it until I get a decent
    answer.


  2. #152
    W.E. (Bill) Goodrich, PhD Guest

    Re: Speaking of strings...

    In article <3dac4828$1@10.1.10.29>,
    "Jason" <jason@hotmail.com> writes:

    > "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
    > >In article <3daa3d7a$1@10.1.10.29>,
    > >"Jason" <jason@hotmail.com> writes:


    > >[...]


    > >> Hey, Bill, instead of trashing OO, why don't you suggest
    > >> something better.


    > >Yet more of your tactical illiteracy? I have consistently been
    > >suggesting something better: modular programming. You have even
    > >quoted such suggestions.


    > ><<SNIP>>


    Interesting snip. Particularly the two questions (What's better?
    And why?) that the following list (along with the statement
    associating the list with modular programming).

    > >Here is a brief list I gave in another post:


    > >1) It is simpler.


    > > 2) It is closer to the way people normally think, and is therefore
    > > more intuitive.


    > > 3) It is closer to the way computers operate, and generally
    > > creates less unnecessary overhead.


    > > 4) It is closer to the realities of most problem domains.


    > > 5) It avoids all of the problems inherent in class related OO
    > > constructs (inheritance, overloading, etc.).


    > > 6) It avoids problems caused by confusion between data access
    > > and code execution.


    > > 7) It concentrates the code for a given function in one place, and
    > > limits the potential range and scope of unwanted side effects
    > > from changes to that code.


    > > 8) It is easier to maintain and upgrade by people other than the
    > > original designer(s) and programmer(s).


    > > 9) It is practical to do in most languages, from Assembly up.


    > >And of course, that doesn't even begin to touch on the areas where
    > >it is merely "as good as" OO (such as handling of complex data
    > >structures). Or those where it is only "a little better" than OO
    > >(such as availability of libraries of existing source code). Or
    > >the fact that MP has been in productive use for the better part of
    > >a half century, with more or less continual refinements along the
    > >way.


    > Okay, just two more questions:


    You went on to ask more than two questions. You just broke them into
    two clusters. And included pointless speculations for good measure.


    > (1) What language do you program in, primarily?


    It depends on what I am doing. And what time frame you are addressing.
    Over the last few years, I would say: For logic intensive, performance
    sensitive, and/or "close to the metal" work, I use C/C++. For quick
    one-offs and programs that are mostly user interface, I use VB6 or a
    combination of VB6 and C++. For Web related work, I use Javascript and
    Java.

    But over the last 35 years, I have probably used Assembly language(s)
    more than anything else. Followed by Fortran and C/C++.

    The fact that you are even thinking in terms of a single primary
    language says a lot about where you are coming from.

    > I thought it was VB6, but now I am beginning to wonder.


    Only for limited problem domains, as described above.

    > What is a ListBox?


    A component. Components have been popular since the 1960s, LONG before
    the fad for OOP or the advent of general purpose OOP languages. Of the
    benefits of component use, one of the most useful is the fact that you
    don't care how the component was implemented. All you need to know is
    what to "feed" it, what it produces, and what (if anything) it does
    with which outside data and/or hardware.

    > What is a Collection?


    Different things in different contexts.

    > What you are telling me is that you prefer to get right down to the
    > metal


    When appropriate. As it often is.

    > and program char-array strings


    What is it with your obsessive preoccupation with arrays? And your
    claimed complete inability to read my repeated statements that I
    prefer to use appropriately designed and typed data structures rather
    than your fantasy of sticking to the primitives? Has some traumatic
    event in your life burned some idiotic stereotype into your brain,
    one which you are incapable of moving beyond? Or did that come from
    some of the Academics who so recently shaped your world view?

    > and use functions for everything.


    What a peculiar characterization. I prefer to use functions where
    appropriate, and subroutines where appropriate. Do you even know the
    difference? Are you even vaguely aware your beloved "methods" ARE
    nothing more than functions and/or subroutines? What would you propose
    as an alternative? One large, amorphous mass of code?

    > Or else you are telling me that you use objects all the time,


    And here we jump feet first into another of your major fallacies. Do
    you even have any concept of the difference between following the
    formal modality called OOP and "using" a component which may or may
    not have been implemented in line with any particular approach? Or
    are you so blind in your advocacy that you reiterate the old "one drop
    of blood" standard? And this instance is worse than usual, since the
    term "objects" is defined so broadly as to include classes, non-class
    data structures, and the construct which in VB.classic was called a
    variant. I define and use data structures all the time. In my VB6
    code, I sometimes use variants. Does this mean I "use objects" in any
    meaningful sense? Absolutely not. Just as the fact that I use existing
    components which may or may not present a classlike interface does
    not classify MY code as "object ORIENTED" in any meaningful way.

    The only time I routinely "use objects" in any meaningful sense is
    when I am working in Java (where it is pretty much inescapable).

    > you just prefer that someone else write them.


    No, my preference is for components which clearly and cleanly separate
    relevant data structures from calls to code (as was the case with the
    immediate predecessors of most of your beloved current components).
    But when such components are not readily available, I wiil use what
    components are readily available despite their unfortunate designs.
    Only a blind fanatic would claim that such use somehow "orients" MY
    code toward objects.

    > In this case, you are saying that you like the results of OO
    > programming,


    Despite your lame attempt at a "double bind", it means no such thing.
    I like the results of using readily available, relatively solid
    prewritten components, irrespective of the way they were written. I
    was somewhat happier with the older, pre-OO version of "msgbox" than
    with the newer OO version, but the latter is readily available and
    the former is not. So I use the latter. Only an idiot or a blind
    fanatic would classify that as "liking the results of OO programming".

    > you just don't wish to use it yourself.


    Outside of the occasional foray into Java, and a VERY few special
    circumstances, that last part is largely correct. The first part
    of the sentence was completely invalid, however.

    > (2) Which is it?


    Neither, as described above.

    > You can't have it both ways.


    Now that your preposterously invalid premises have been demolished,
    that claim is a non starter.

    > Either you use a language that does not use any object constructs,
    > or you don't.


    That is entirely meaningless. C++ "uses" object constructs, but it
    entirely possible - and common - to write major programs in it without
    using the OO specifics. Even the usual components are widely available
    in non-OO configurations (although many also have OO compatible
    versions for those who like such things).

    > Like I have been saying, OO is very useful when applied correctly
    > (the component model for OCXs, for instance).


    For that claim to be meaningful, you would have to show that the OO
    implementation has some concrete advantage for non-OO programmers over
    an equivalent component written (and interfaced) in a non-OO manner.
    You have not done so. All you seem to be doing is trying to obscure
    the fact that components and component libraries are not OO specific,
    and that the implementation style of a given component is irrelevant
    to its utility.

    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  3. #153
    Jason Guest

    Re: Speaking of strings...


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
    <<snip>>

    Geesh, Bill, are you even capable of writing a succinct answer to anything?
    I wrote, what, 3 paragraphs? But let's get to the point.

    >> Either you use a language that does not use any object constructs,
    >> or you don't.

    >
    >That is entirely meaningless. C++ "uses" object constructs, but it
    >entirely possible - and common - to write major programs in it without
    >using the OO specifics. Even the usual components are widely available
    >in non-OO configurations (although many also have OO compatible
    >versions for those who like such things).


    Let's stick to VB. This group is all about VB, not C++. There are a whole
    different set of arguments around C++.


    >> Like I have been saying, OO is very useful when applied correctly
    >> (the component model for OCXs, for instance).

    >
    >For that claim to be meaningful, you would have to show that the OO
    >implementation has some concrete advantage for non-OO programmers over
    >an equivalent component written (and interfaced) in a non-OO manner.
    >You have not done so. All you seem to be doing is trying to obscure
    >the fact that components and component libraries are not OO specific,
    >and that the implementation style of a given component is irrelevant
    >to its utility.


    The components and component libraries in VB are very much OO specific.
    OCXs are objects. They have encapsulation, they contain other objects (usually),
    and they extend from Control. A Form is a Class. It can be cast to Object.
    It has properties and methods. It encapsulates data.

    These are facts, not my opinion.

    Now, if you are programming in VB, you are using OO, even if you never write
    a class module.

    You can use MP methodology for your code, but if you use any libraries in
    VB or if you build forms, then you are using objects, or you are doing simple
    OO programming.

    You are using VB because you can write programs with it faster than C++,
    right? And in doing so, you are either using or creating objects regularly,
    right? So you are not doing "strict" modular programming. You are benefitting
    from an OO design.

    I'm not saying there is anything wrong with modular programming. What I
    am saying is that some things, like the libraries you use in VB6, work better
    when they are structured as objects.

    If you think otherwise, then point me to a tool that uses "strict" MP that
    is more productive than VB6. I haven't seen one yet.

    Or, you could just admit that MP and OO are two methodologies that complement
    each other.

    Try not to phrase your answer(s) in the form of an unending string of insults
    this time, eh?


    >
    >--
    >
    >W.E. (Bill) Goodrich, PhD
    >
    >*-----------------------*--------------------------------------------*
    >* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    >* * *
    >* Without Aversive * ctgcentral@earthlink.net *
    >* Behavior Modification * Creative Technology Group *
    >* or Drugs * PO Box 286 *
    >* * Englewood, CO 80151-0286 *
    >*-----------------------*--------------------------------------------*



  4. #154
    W.E. (Bill) Goodrich, PhD Guest

    Re: Speaking of strings...

    In article <3dad1d6d@tnews.web.devx.com>,
    "Ed Courtenay" <replace-this-with-my-first-name@edcourtenay.co.uk>
    writes:

    > "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
    > news:3DAC3F63.473FDCE8@netzero.net...


    > > <snip/>


    > > Here is a brief list I gave in another post:


    > > 1) It is simpler.


    > Possibly, but not necessarily a good thing. Overall, OO is not
    > inheritantly difficult either.


    But it is inherently "less simple" than modular programming, which
    is the issue at hand. In large part because - with the exception of
    separation of data and code - it was created by simply adding a bunch
    of stuff to MP.

    > > 2) It is closer to the way people normally think, and is
    > > therefore more intuitive.


    > I disagree. I find OO based design much more natural than plain
    > Modular development.


    So you have claimed. However, the Cognitive researchers, from Piaget
    to Gazzaniga, paint a different picture. And since your "observation"
    is neither systematic nor objective, I will pay more attention to
    their claims than to yours.

    Contrary to the misplaced claims of some early OO advocates, people
    clearly think of "things" and "actions" differently and separately.
    MRI studies and the like have even shown that they use different
    parts of the brain to do so.

    > > 3) It is closer to the way computers operate, and generally
    > > creates less unnecessary overhead.


    > So?


    So, the unnecessary overhead slows down execution and impairs the
    ability to multitask with other programs. ESPECIALLY when the other
    programs are similarly bloated.

    > Write your code in hex if you want to get down to the metal.


    Hardly a surprising rejoinder from one of the Cheerleaders for the
    20 MB runtime. Completely irrelevant - and preposterous - but hardly
    surprising.

    > > 4) It is closer to the realities of most problem domains.


    > Not in any large scale developments that I've worked on; invariably
    > OO design has been able to model the 'real-world' problem at a much
    > closer level.


    More like *you*, with your personal prejudices and limitations, were
    more comfortable doing so. The large scale developments I have worked
    on, from spacecraft to network backbones, have consistently mapped
    more closely to the modular analysis than to OOD.

    > > 5) It avoids all of the problems inherent in class related OO
    > > constructs (inheritance, overloading, etc.).


    > Operator overloading can be a thorny issue; if used correctly it's
    > a boon, if not it's a problem I'll grant you. However, it can make
    > for very natural code;


    More like deceptively natural-appearing code.

    > Point p = new Point(1, 2);
    > Point q = new Point(4, 5);
    > Point r = p + q;


    > When you change the *meaning* of the overloaded operator, then you
    > cause problems and lead to code obfuscation.


    And you didn't even touch on the problems caused by excessive
    inheritance, fragile base classes, and the like.

    > > 6) It avoids problems caused by confusion between data access
    > > and code execution.


    > What confusion?


    For instance, the confusion caused by unexpected execution of seeming
    data members in various conditional operations.

    > > 7) It concentrates the code for a given function in one place, and
    > > limits the potential range and scope of unwanted side effects
    > > from changes to that code.


    > It also makes that function large and unwieldy,


    No more so than the equivalent "method". And generally less so, since
    commonalties which are not obvious when spread out across several
    generations of inheritance can be collapsed into a more compact form.
    Also, MP design calls for breaking large, multifunction code into
    separate, single function modules. That serves to limit such bloat as
    well.

    > prone to error and difficult to manage.


    No more so - and demonstrably less so - than the equivalent
    "methods". Such "methods" are susceptible to every kind of error and
    unnecessary complication that outside functions and subroutines are,
    plus additional ones arising from the OO specific constructs.

    [...]

    > > 9) It is practical to do in most languages, from Assembly up.


    > Why have OO languages been developed then?


    For the same reason that "Structured Programming" languages (such as
    Structured COBOL) were. The academic fad - and associated propaganda -
    created a perceived demand. And there was money to be made by filling
    that demand (no matter how irrational).

    > Why have they proved so popular?


    Because of the Academic fad.

    > Are we being brainwashed,


    In a word, yes. Specifically, the "gateway" to the relevant careers
    is through years spent in institutions with a vested interest in
    proselytizing the fad and discrediting the alternatives. Such is the
    reality of Academic politics. The penalties for questioning the fad
    range from cripplingly bad grades to outright denial of degree. And
    the "relevant careers" in question include technical and general
    management, as well as the directly technical careers.

    The only "acceptable" way to question the fad is in terms of one of
    the Approved candidates for the successor fad. So it is currently
    becoming acceptable to challenge elements of OOP in terms of AOP.

    > or have we actually proved to ourselves that this is a viable
    > method of development?


    Generally "accepted uncritically" rather than "proved". It is no
    coincidence that the most outspoken advocates of the fad exhibit a
    strong tendency to validate their beliefs based on statements of
    "appropriate authorities" rather than personal evaluation of
    objective evidence. Nor is it a coincidence that they tend to come
    to certain buzzwords and then become "stuck" - unable to think or
    argue past that point. See, for instance, Larry's and Jason's
    inability to produce a concrete definition of "polymorphism".

    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  5. #155
    Jason Guest

    Re: Speaking of strings...


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
    >> > 2) It is closer to the way people normally think, and is
    >> > therefore more intuitive.

    >
    >> I disagree. I find OO based design much more natural than plain
    >> Modular development.

    >
    >So you have claimed. However, the Cognitive researchers, from Piaget
    >to Gazzaniga, paint a different picture. And since your "observation"
    >is neither systematic nor objective, I will pay more attention to
    >their claims than to yours.
    >
    >Contrary to the misplaced claims of some early OO advocates, people
    >clearly think of "things" and "actions" differently and separately.
    >MRI studies and the like have even shown that they use different
    >parts of the brain to do so.


    Bill, I have to agree with the other guy on this one. When I use objects
    in Visual Basic, I generally find them easier to use than equivalent functions
    which take handles as arguments. For things like Strings, it's not a big
    deal. If you added a bunch of functions for Collections and Forms, etc.,
    you would run into namespace issues pretty quickly.

    I also understand his argument for objects. Yours? I have no idea. Cognitive
    researchers? MRI studies? Where do you get this stuff? And you'll have
    to do a better job of explaining the relevance to this discussion. "Hey,
    look at me! I'm Bill! I know names like Piaget and Gazzaniga and you don't!"
    Yeah, tell it to Dennis Miller.


    >> > 3) It is closer to the way computers operate, and generally
    >> > creates less unnecessary overhead.

    >
    >> So?

    >
    >So, the unnecessary overhead slows down execution and impairs the
    >ability to multitask with other programs. ESPECIALLY when the other
    >programs are similarly bloated.


    This has nothing to do with how easy or difficult OO is to understand. OO
    constructs add additional overhead. That is a given. They did it to C++,
    which is slower than C, they do it to VB6. Yet you still are using VB6,
    right?

    >> Write your code in hex if you want to get down to the metal.

    >
    >Hardly a surprising rejoinder from one of the Cheerleaders for the
    >20 MB runtime. Completely irrelevant - and preposterous - but hardly
    >surprising.


    Talk about predictable responses! Can't come up with a good retort? Bob,
    weave, and insult.

    Let me help you out. A better comeback would be:

    "Or C. C gets you really close to the metal, without all that nasty OO overhead.
    It's all MP."

    And look, I managed to do it without using the words "irrelevant," "preposterous,"
    or "rejoinder." I also managed to do it without an implied insult.

    >> > 4) It is closer to the realities of most problem domains.

    >
    >> Not in any large scale developments that I've worked on; invariably
    >> OO design has been able to model the 'real-world' problem at a much
    >> closer level.

    >
    >More like *you*, with your personal prejudices and limitations, were
    >more comfortable doing so. The large scale developments I have worked
    >on, from spacecraft to network backbones, have consistently mapped
    >more closely to the modular analysis than to OOD.


    Bill, why is it that everyone in the world but you is filled with personal
    predjudices and limitations? It must be really hard having to live in a
    world with all us complete idiots. If you get tired of it, I hear there
    is a nice little shack in Montana that's up for sale.

    Spacecraft, because they must be rad-hard, use comparatively simple processors,
    and their software tends to lend itself to MP very well. DSP algorithms
    don't require OO. They require speed and a real-time operating system, and
    usually an abbreviated memory footprint.

    In fact, the last spacecraft I worked on did not contain a CPU. It was constructed
    entirely with old 4000 logic parts on numerous circuit boards.

    Now how does this apply to something familiar, like, say, VB? Don't know.
    I've not seen a satellite that ran on Windows and VB yet. It's a different
    problem set.

    Can we please stay on subject, which is VB?


    >> > 5) It avoids all of the problems inherent in class related OO
    >> > constructs (inheritance, overloading, etc.).

    >
    >> Operator overloading can be a thorny issue; if used correctly it's
    >> a boon, if not it's a problem I'll grant you. However, it can make
    >> for very natural code;

    >
    >More like deceptively natural-appearing code.


    Incorrect answer. The correct answer is that operator overloading is a feature
    that you can choose not to use in your code. VB.NET doesn't have it, and
    C# only uses it in a few places, like for string comparisons (VB has always
    uses '=' anyway, but Java uses '.equals').

    Some people at Microsoft obviously thought it would be useful, so they put
    it into C#. Probably some C programmers who thought that the '.equals' thing
    in Java was silly.

    Operator overloading is not necessarily a feature of OO, but a feature of
    C#. There are plenty of languages that support OO but don't have operator
    overloading, and no one seems to mind.

    >> Point p = new Point(1, 2);
    >> Point q = new Point(4, 5);
    >> Point r = p + q;

    >
    >> When you change the *meaning* of the overloaded operator, then you
    >> cause problems and lead to code obfuscation.

    >
    >And you didn't even touch on the problems caused by excessive
    >inheritance, fragile base classes, and the like.


    But Bill, that is kind of like saying "MP sucks bacause everything is stored
    in a global variable and accessed from everywhere." You can do global variables
    in MP, can't you? Does that make it bad?

    Or maybe we should have the GOTO argument all over again. "MP is bad because
    languages contain the GOTO keyword." Yeah, it's not even a valid argument,
    but then yours isn't valid either.

    If you don't know MP best-practices and have some experience, you are going
    to make stupid design mistakes. If you don't know OO best-practices and
    have some experience, you are going to make stupid design mistakes.

    >> > 6) It avoids problems caused by confusion between data access
    >> > and code execution.

    >
    >> What confusion?

    >
    >For instance, the confusion caused by unexpected execution of seeming
    >data members in various conditional operations.


    You mean like "Property" in VB6? In case you missed it, you can create a
    property in a BAS module in VB6, and it behaves like a global variable -
    but there is code behind it.

    Don't like this? It's okay, because Java and C++ don't support properties.
    You can use them instead of VB6. But again, that gets us off the subject
    of VB, which has supported the "Property" keyword since at least version
    4.

    Incidentally, I can't recall even once where a VB programmer has mentioned
    to me that they were confused by a property that had code behind it. But
    maybe you have seen this from time to time. I can only speak for myself.

    >> > 7) It concentrates the code for a given function in one place, and
    >> > limits the potential range and scope of unwanted side effects
    >> > from changes to that code.

    >
    >> It also makes that function large and unwieldy,

    >
    >No more so than the equivalent "method". And generally less so, since
    >commonalties which are not obvious when spread out across several
    >generations of inheritance can be collapsed into a more compact form.
    >Also, MP design calls for breaking large, multifunction code into
    >separate, single function modules. That serves to limit such bloat as
    >well.


    In some cases the OO way is better. In other cases, the MP way is better.
    Depends on your requirements and what you are trying to accomplish. An
    encapsulated, extensible library (maybe OO) versus simplified inline code
    in an application (maybe MP).

    In any case, if you are doing VB forms, you are doing OO programming. Maybe
    you have actually extended the meaning of MP to include VB forms, since they
    only inherit once (well, twice if you consider Object --> Form --> YourForm).
    I'm sticking to the definition that if it looks like an object and quacks
    like an object, it probably extends from a duck.


    >> prone to error and difficult to manage.

    >
    >No more so - and demonstrably less so - than the equivalent
    >"methods". Such "methods" are susceptible to every kind of error and
    >unnecessary complication that outside functions and subroutines are,
    >plus additional ones arising from the OO specific constructs.
    >
    >[...]


    You'll have to provide some example side by side on this one. I don't see
    how one or the other is more "error prone." Maybe a few additional compile
    errors if you aren't bright enough to remember a keyword or two. Seems to
    be not a significant argument either way.

    Methods and functions are basically the same thing. Object constructs define
    how the methods and associated data are grouped together. They don't do
    a whole lot at the level of a single method.


    >> > 9) It is practical to do in most languages, from Assembly up.

    >
    >> Why have OO languages been developed then?

    >
    >For the same reason that "Structured Programming" languages (such as
    >Structured COBOL) were. The academic fad - and associated propaganda -
    >created a perceived demand. And there was money to be made by filling
    >that demand (no matter how irrational).


    VB is an OO language. Granted, it has evolved quite a bit since VB3, but
    object-based libraries and controls, support for classes and forms, and implementation
    inheritance, and early and late-bound polymorphism make it almost as complete,
    OOP-wise, as Java.

    Java is heavily OO based, and while there are a number of large failed Java
    projects, the successes seem to keep it going. It has surpassed VB in popularity
    and use in business applications, despite the fact that many people consider
    it to be second-class in terms of GUI development. It has taken the web-world
    and the middle tier by storm. Not that I personally like J2EE - I believe
    it it TOO object-oriented. But this is a VB discussion group, so let's not
    go any further with that.

    Meanwhile, Microsoft spent several billion dollars and "bet the company"
    that going more OO, not less, was the way to go.

    This is no academic fad anymore. It is a full-fledged industry-wide fad.
    Plus, isn't it a bit irrational to say that the whole industry is irrational?


    I'd like to think that I have a good enough brain to decide if a tool is
    useful to me or not. I don't believe that there are any emotion chips inside
    my skull that force me to develop opinions at the whim of a marketing department.


    Besides, even you seem to like VB6, and you still have yet to admit that
    VB6 is an OO language.


    >> Why have they proved so popular?

    >
    >Because of the Academic fad.


    That's it? That is the best you can do? Some professor likes it, so everyone
    in the civilized world picks it up and runs with it, despite the fact that
    it obviously has no merit? Well, except for you and MM, that is.

    Oh, come on! With all those big words and your ability to obfuscate logic,
    I KNOW you can come up with a more plausible explanation than that! I have
    faith in you Bill. Now try it again...

    Why have they proved so popular?

    >> Are we being brainwashed,

    >
    >In a word, yes. Specifically, the "gateway" to the relevant careers
    >is through years spent in institutions with a vested interest in
    >proselytizing the fad and discrediting the alternatives. Such is the
    >reality of Academic politics. The penalties for questioning the fad
    >range from cripplingly bad grades to outright denial of degree. And
    >the "relevant careers" in question include technical and general
    >management, as well as the directly technical careers.


    Hmmm. I am one of those guys who would be programming if they didn't pay
    me to do it. I like to develop applications, and I have made a reputation
    on being able to deliver solid solutions faster and cheaper than the next
    guy. Or even than the next two guys.

    I started this with VB, way back in the VB3 days. I did programming before
    that, of course, but that was when I started getting serious.

    Now, I find that I am most productive with a combination of Java for server-side
    programming and VB6 and .NET on the client.

    If I don't like a tool, I don't use it. I only use the tools that help me
    get my job done more quickly. My customers have given me a lot of leeway
    in this regard, and I take advantage of it.

    In other words, I don't think I learned OO just because it would help me
    get a better career or make more money. I learned it because it helps me
    do better software more quickly. And, by the way, I use MP techniques in
    there too.

    Incidentally, my grades in college were quite good, and very little of the
    theoretical study I did had anything to do with OOP. In fact, we used all
    sorts of non-OOP languages like Lisp, Pascal, and Tck-Tk, among others.
    And a lot of the studies were more mathematical in nature, and had nothing
    to do with structuring large programs, so OOP was not required.

    >The only "acceptable" way to question the fad is in terms of one of
    >the Approved candidates for the successor fad. So it is currently
    >becoming acceptable to challenge elements of OOP in terms of AOP.


    I'll cross that bridge when and if it becomes useful to me.

    >> or have we actually proved to ourselves that this is a viable
    >> method of development?

    >
    >Generally "accepted uncritically" rather than "proved". It is no
    >coincidence that the most outspoken advocates of the fad exhibit a
    >strong tendency to validate their beliefs based on statements of
    >"appropriate authorities" rather than personal evaluation of
    >objective evidence.


    Pot, kettle, tope.

    I can give you lots of stories from my personal experience. If you want
    "objective evidence," you will need to consult the "appropriate authorities."
    But you wouldn't trust them anyway, because they are academic, all taken
    in by "the fad." It isn't my job to run scientific studies that quantify
    productivity using different methodologies across languages. However, if
    I ever take such a job, I'll let you know.

    How's that tin-foil mind ray shield working out for ya these days, by the
    way?

    >Nor is it a coincidence that they tend to come
    >to certain buzzwords and then become "stuck" - unable to think or
    >argue past that point. See, for instance, Larry's and Jason's
    >inability to produce a concrete definition of "polymorphism".


    Actually, I did produce a "concrete" definition of polymorphism based on
    virtual function pointers and data structures. Did you miss it?

    If you want a solid definition of "polymorphism" in MP terms, check out the
    implementation in C++. Very easy to understand, and similar to the way it
    is implemented in other languages.

    Or were you expecting something different, maybe more theoretical?




  6. #156
    Ed Courtenay Guest

    Re: Speaking of strings...


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
    news:3DADBCC7.8BFCA20E@netzero.net...
    > In article <3dad1d6d@tnews.web.devx.com>,
    > "Ed Courtenay" <replace-this-with-my-first-name@edcourtenay.co.uk>
    > writes:
    >
    > > "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
    > > news:3DAC3F63.473FDCE8@netzero.net...


    > > > 2) It is closer to the way people normally think, and is
    > > > therefore more intuitive.

    >
    > > I disagree. I find OO based design much more natural than plain
    > > Modular development.

    >
    > So you have claimed. However, the Cognitive researchers, from Piaget
    > to Gazzaniga, paint a different picture. And since your "observation"
    > is neither systematic nor objective, I will pay more attention to
    > their claims than to yours.
    >
    > Contrary to the misplaced claims of some early OO advocates, people
    > clearly think of "things" and "actions" differently and separately.
    > MRI studies and the like have even shown that they use different
    > parts of the brain to do so.


    Excuse me, but you made the point that "[Modular development] is closer to
    the way people normally think", which I rebutted. Contrary to what you might
    think, I *am* a person, and OO is closer to the way *I* think, and *I* find
    OO design more natural. Therefore, from my objective viewpoint, I find OO
    development infinately superior to MP.



  7. #157
    Blob Guest

    Re: Speaking of strings...


    Jesus man, can you make this crap a little shorter. I was reading this and
    I fell asleep. I woke up two hours later late for work. And what the ****
    is this crap about changing your sexuality? What the **** does that have
    to do with VB.NET?

  8. #158
    W.E. (Bill) Goodrich, PhD Guest

    Re: Speaking of strings...

    In article <3dad961d$1@tnews.web.devx.com>,
    "Jason" <jason@hotmail.com> writes:

    > Yuh know, I am trying not to post negatively,


    You're not trying very hard, apparently. Your posts in this thread
    have consistently been heavily laced with personal insults, sarcasm,
    misrepresentation, inappropriate language, and other hallmarks of
    negativity. You set the tone for the exchange, and now it is a little
    late to complain that I was less than consistently "positive" in
    response to your childish outbursts.

    > and to try to understand your point of view.


    Then try actually READING what I write and cite, rather than scanning
    it for "sound bytes" you can twist into excuses for your continuing
    negativity.

    > And you still post an insult in every other sentence.


    Hardly. Of course, you have shown a consistent tendency to ignore the
    substance of the posts, so I can see how your little sound byte exerpts
    can make it look that way. However, if you are going to engage in games
    like "that was too hard to read" and "did I use the word you quoted my
    use of? I don't think so," you can expect to be called on them. If you
    consider that a "personal insult" then you should quit playing such
    games.

    > But every OTHER sentence is providing some information, so I will
    > try to deal with that.


    To date, you have primarily dealt with that by complaining that there
    was too MUCH information, that it used too many hard words, or that
    the citations weren't oversimplified enough for your tastes. And then
    "challenging" me to answer questions that I had repeatedly (and at
    length) answered in those posts.

    > Simply put, how do you reconcile the fact that forms, controls, and
    > ActiveX DLLs are all OO-based (without inheritance, granted), in the
    > context of modular programming in VB?


    By taking the long view and the deep view of such components, and
    treating them as components. The long view considers the fact that
    the specific predecessors of those components were not OO, and their
    eventual successors will probably not be OO. The deep view notes that
    M$ (like most large organizations) tends to leverage existing code
    rather than unnecessarily rewriting it. Very little of the code in
    those M$ forms, controls, and ActiveX DLLs is OO in origin or
    structure. Instead, it is the older, non-OO code in an OO wrapper.
    If I have to deal with the counterproductive wrapper to get to the
    otherwise useful functionality underneath, I will have to make a
    case by case cost/benefit judgment. In those cases where I use the
    component, I minimize the problems by treating it much the same way
    I would treat the equivalent non-OO component. I do not explicitly use
    the problematic OO specific constructs (inheritance, overloading, etc.)
    with them, I simply use the components as components.

    How do you reconcile the fact that most of those components are non OO
    code in an OO wrapper with your "products of OO" argument?

    > What I mean is, there are a number of programs that are written in
    > C that are still around, and these programs are strictly MP.


    No, many of them are not even MP. You still seem unable to grasp the
    difference between MP and "not OO", just as you seem unable to grasp
    the difference between OO code and any-way code which uses one or more
    OO specific construct(s).

    > But with VB, you can't write more than about 10 lines of code
    > without using some sort of object.


    With M$ redefining data structures and variants, that claim (while
    effectively meaningless) has some superficial semblance of fact for
    VB.NET. Much less so for VB6. The central issue is whether they are
    being used AS "objects" in any meaningful way, or are being used as
    data structures and "functions with funny calling sequences". In the
    latter case, it is completely preposterous to claim that the program
    is "using objects" in any meaningful sense. And since the "funny
    calling sequence" is most often passing through a superficial OO
    wrapper to a non OO body of functional code, attempts to use the
    nature of the wrapper to bolster a "using OO" claim are particularly
    pointless.

    > What I am trying to understand here is, are you for "strict" MP,
    > or MP that makes use of object libraries others have written, or do
    > the object libraries in VB somehow fall under the MP umbrella, so
    > they are not actually object libraries at all?


    What you are calling "object libraries" are by and large just
    component libraries with superficial OO wrappers to begin with. So
    they are not really "object libraries" at all in any meaningful
    sense. Creating and using component libraries is entirely consistent
    with MP, irrespective of such superficial wrappers.

    And again you seem to be falling into the false dichotomy of OO/MP.
    It is NOT true that every approach which is not OO is therefore MP.
    The kinds of "any way", undesigned, code as you go development you
    have tried to ascribe to MP is neither MP nor OO. Just as such
    undesigned, off the cuff programming does not become OOP if you throw
    in a library class or two.

    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  9. #159
    Blob Guest

    Re: Speaking of strings...


    ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ ZZzzz.
    Chirp Chirp(Crickets). Snore. Zzzzzzzzzzzzzz. huh? ZZZZZZZZZZZZZZZZZZZZZZZZZZZZ.


    Auntie Emm? Toto? ?ZZZZZZZZZZZZZZZ?


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
    >In article <3dad961d$1@tnews.web.devx.com>,
    >"Jason" <jason@hotmail.com> writes:
    >
    >> Yuh know, I am trying not to post negatively,

    >
    >You're not trying very hard, apparently. Your posts in this thread
    >have consistently been heavily laced with personal insults, sarcasm,
    >misrepresentation, inappropriate language, and other hallmarks of
    >negativity. You set the tone for the exchange, and now it is a little
    >late to complain that I was less than consistently "positive" in
    >response to your childish outbursts.
    >
    >> and to try to understand your point of view.

    >
    >Then try actually READING what I write and cite, rather than scanning
    >it for "sound bytes" you can twist into excuses for your continuing
    >negativity.
    >
    >> And you still post an insult in every other sentence.

    >
    >Hardly. Of course, you have shown a consistent tendency to ignore the
    >substance of the posts, so I can see how your little sound byte exerpts


    >can make it look that way. However, if you are going to engage in games


    >like "that was too hard to read" and "did I use the word you quoted my
    >use of? I don't think so," you can expect to be called on them. If you
    >consider that a "personal insult" then you should quit playing such
    >games.
    >
    >> But every OTHER sentence is providing some information, so I will
    >> try to deal with that.

    >
    >To date, you have primarily dealt with that by complaining that there
    >was too MUCH information, that it used too many hard words, or that
    >the citations weren't oversimplified enough for your tastes. And then
    >"challenging" me to answer questions that I had repeatedly (and at
    >length) answered in those posts.
    >
    >> Simply put, how do you reconcile the fact that forms, controls, and
    >> ActiveX DLLs are all OO-based (without inheritance, granted), in the
    >> context of modular programming in VB?

    >
    >By taking the long view and the deep view of such components, and
    >treating them as components. The long view considers the fact that
    >the specific predecessors of those components were not OO, and their
    >eventual successors will probably not be OO. The deep view notes that
    >M$ (like most large organizations) tends to leverage existing code
    >rather than unnecessarily rewriting it. Very little of the code in
    >those M$ forms, controls, and ActiveX DLLs is OO in origin or
    >structure. Instead, it is the older, non-OO code in an OO wrapper.
    >If I have to deal with the counterproductive wrapper to get to the
    >otherwise useful functionality underneath, I will have to make a
    >case by case cost/benefit judgment. In those cases where I use the
    >component, I minimize the problems by treating it much the same way
    >I would treat the equivalent non-OO component. I do not explicitly use
    >the problematic OO specific constructs (inheritance, overloading, etc.)


    >with them, I simply use the components as components.
    >
    >How do you reconcile the fact that most of those components are non OO
    >code in an OO wrapper with your "products of OO" argument?
    >
    >> What I mean is, there are a number of programs that are written in
    >> C that are still around, and these programs are strictly MP.

    >
    >No, many of them are not even MP. You still seem unable to grasp the
    >difference between MP and "not OO", just as you seem unable to grasp
    >the difference between OO code and any-way code which uses one or more
    >OO specific construct(s).
    >
    >> But with VB, you can't write more than about 10 lines of code
    >> without using some sort of object.

    >
    >With M$ redefining data structures and variants, that claim (while
    >effectively meaningless) has some superficial semblance of fact for
    >VB.NET. Much less so for VB6. The central issue is whether they are
    >being used AS "objects" in any meaningful way, or are being used as
    >data structures and "functions with funny calling sequences". In the
    >latter case, it is completely preposterous to claim that the program
    >is "using objects" in any meaningful sense. And since the "funny
    >calling sequence" is most often passing through a superficial OO
    >wrapper to a non OO body of functional code, attempts to use the
    >nature of the wrapper to bolster a "using OO" claim are particularly
    >pointless.
    >
    >> What I am trying to understand here is, are you for "strict" MP,
    >> or MP that makes use of object libraries others have written, or do
    >> the object libraries in VB somehow fall under the MP umbrella, so
    >> they are not actually object libraries at all?

    >
    >What you are calling "object libraries" are by and large just
    >component libraries with superficial OO wrappers to begin with. So
    >they are not really "object libraries" at all in any meaningful
    >sense. Creating and using component libraries is entirely consistent
    >with MP, irrespective of such superficial wrappers.
    >
    >And again you seem to be falling into the false dichotomy of OO/MP.
    >It is NOT true that every approach which is not OO is therefore MP.
    >The kinds of "any way", undesigned, code as you go development you
    >have tried to ascribe to MP is neither MP nor OO. Just as such
    >undesigned, off the cuff programming does not become OOP if you throw
    >in a library class or two.
    >
    >--
    >
    >W.E. (Bill) Goodrich, PhD
    >
    >*-----------------------*--------------------------------------------*
    >* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    >* * *
    >* Without Aversive * ctgcentral@earthlink.net *
    >* Behavior Modification * Creative Technology Group *
    >* or Drugs * PO Box 286 *
    >* * Englewood, CO 80151-0286 *
    >*-----------------------*--------------------------------------------*



  10. #160
    Jason Guest

    Re: Speaking of strings...


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
    >In article <3dad961d$1@tnews.web.devx.com>,
    >"Jason" <jason@hotmail.com> writes:
    >
    >> Yuh know, I am trying not to post negatively,

    >
    >You're not trying very hard, apparently. Your posts in this thread
    >have consistently been heavily laced with personal insults, sarcasm,
    >misrepresentation, inappropriate language, and other hallmarks of
    >negativity. You set the tone for the exchange, and now it is a little
    >late to complain that I was less than consistently "positive" in
    >response to your childish outbursts.

    <<snip>>

    Since you seem unable to "let it go," and since you don't seem to have anything
    relevant to the title of this group to say, this is it for me. I have other
    things to do. You've won by fillabuster.

    Keep posting though. The more you write here, the less time you have to
    code anything, and that has to be a net plus. :-)

  11. #161
    W.E. (Bill) Goodrich, PhD Guest

    Re: Speaking of strings...

    In article <3dada114$1@tnews.web.devx.com>,
    "Jason" <jason@hotmail.com> writes:

    > "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
    > <<snip>>


    > Geesh, Bill, are you even capable of writing a succinct answer
    > to anything?


    You mean reduce technical issues to oversimplified sound bytes? No.
    The very fact that you ask technical questions and technical claims,
    and then complain because you get a technical answer rather than a
    meaningless sound byte speaks volumes. Especially when the questions
    and claims are based on false premises which, themselves, need to be
    addressed before the alleged "points" can be meaningfully addressed.

    Try to learn the difference between "succinct" and "short and
    superficial".

    > I wrote, what, 3 paragraphs?


    And packed volumes worth of misinformation and fallacy into them.

    > But let's get to the point.


    But as we see below, you don't. In fact, you try very hard to avoid
    doing so.

    > >> Either you use a language that does not use any object
    > >> constructs, or you don't.


    > >That is entirely meaningless. C++ "uses" object constructs, but it
    > >entirely possible - and common - to write major programs in it
    > >without using the OO specifics. Even the usual components are
    > >widely available in non-OO configurations (although many also have
    > >OO compatible versions for those who like such things).


    > Let's stick to VB.


    Typical. You make a claim about languages, then try to dodge the
    answer (which demolishes your claim, as usual) by trying to
    retroactively reduce the scope of the discussion from characteristics
    of "a language" to a single, somewhat anomalous language. No, when
    you are making broad, false claims about OOP, Languages, etc. we will
    NOT retroactively "stick" to VB - especially when YOU have not been
    doing so.

    > This group is all about VB, not C++.


    Nor is it about Java. Or C. Or C#. Or the .NET framework. But that
    hasn't kept you from bringing them into the discussion when it suited
    your purpose. Nor has it kept others here from basing entire threads
    on such "off topic" subjects.

    > There are a whole different set of arguments around C++.


    You did not make a claim about VB, you made a general (false) claim
    about languages. C++ is a good example of a language which illustrates
    the fallacy inherent in your claim.

    > >> Like I have been saying, OO is very useful when applied correctly
    > >> (the component model for OCXs, for instance).


    > >For that claim to be meaningful, you would have to show that the OO
    > >implementation has some concrete advantage for non-OO programmers
    > >over an equivalent component written (and interfaced) in a non-OO
    > >manner. You have not done so. All you seem to be doing is trying
    > >to obscure the fact that components and component libraries are
    > >not OO specific, and that the implementation style of a given
    > >component is irrelevant to its utility.


    > The components and component libraries in VB are very much OO
    > specific.


    Wrong. For the most part, they are non OO components with OO wrappers.
    There is nothing about most of them that is OO specific.

    > OCXs are objects.


    OCXs are rarely - if ever - anything but wrappers.

    > They have encapsulation, they contain other objects (usually),
    > and they extend from Control.


    They are wrappers. Those characteristics may be useful for those who
    are overenthusiastic about such things, but otherwise they just get
    in the way.

    > A Form is a Class.


    No, a form is a construct WRAPPED in a class. There is a big
    difference. And even that is a relatively recent change. Some of
    the earlier versions were not even object wrapped.

    > It can be cast to Object. It has properties and methods. It
    > encapsulates data.


    > These are facts, not my opinion.


    Those are "facts" about the WRAPPER, not the component itself. And
    that is a large part of the point (and the central fallacy of your
    argument). You have ABSOLUTELY NO IDEA how those components were
    actually implemented. Instead, you ascribe disproportionate
    importance to the apparent nature of the wrapper and center your
    argument around it.

    > Now, if you are programming in VB, you are using OO, even if you
    > never write a class module.


    Nonsense. Dangerous nonsense, at that. You seem to have no concept of
    the difference between object USING code and object ORIENTED code. If
    you are using those so-called "objects" as data structures and
    "functions with funny calling sequences", then your code is not object
    ORIENTED in any meaningful way. And when those so-called "objects" are
    nothing more than non OO code in an "object" wrapper, it is absolutely
    preposterous to point to that wrapper as though it was meaningful.

    > You can use MP methodology for your code, but if you use any
    > libraries in VB or if you build forms, then you are using objects,


    Or other things which happen to be hidden behind "object" wrappers.

    > or you are doing simple OO programming.


    Utter nonsense. If you were explicitly using the so-called objects AS
    objects, there might be a grain of truth in there. If you are merely
    using them as generic components, and playing none of the OO specific
    games (inheritance, overloading, etc.) with them, then it is
    completely preposterous to claim that you are "doing OO programming",
    simple or otherwise. You are trying to focus obsessively on the
    "object" part and hide from the "Oriented" part. You need BOTH for
    it to be OO even superficially. You need the explicit design and
    use patterns inherent in OOD and OOP for it to be OO in any semblance
    of a meaningful way.

    > You are using VB because you can write programs with it faster
    > than C++, right?


    Not necessarily. In fact, I can often write the programs faster AND
    better in C++. Especially when I can use components from my libraries
    with few or no changes. That is the whole point of component libraries,
    irrespective of the methodology (if any) which was used to build those
    components.

    I use VB mostly when I am implementing trivial new code behind a new
    GUI, and the GUI is the most significant element. If the VC++ IDE did
    as good a job as that of VB, I would rarely - if ever - be using VB at
    all.

    > And in doing so, you are either using or creating objects regularly,
    > right?


    Wrong. I am using COMPONENTS which may - or may not - be hidden behind
    "object" wrappers, but I am not using them AS "objects" in any
    meaningful way. And I am not "creating" objects in my VB code.

    > So you are not doing "strict" modular programming. You are benefitting
    > from an OO design.


    I am benefiting from the modules which have been WRAPPED in the
    semblance of "objects" or "classes", but which may or may not have been
    originally implemented as anything of the sort. Just as I benefited
    from their equivalent components BEFORE M$ decided to thus wrap them.
    The fundamental design of VB.classic was COMPONENT oriented rather than
    Object Oriented. And I continue to benefit from that COMPONENT oriented
    design.

    > I'm not saying there is anything wrong with modular programming.


    Which is good, since you continue to demonstrate an almost total
    ignorance of what constitutes MP.

    > What I am saying is that some things, like the libraries you use
    > in VB6, work better when they are structured as objects.


    You are CLAIMING that. But all you have offered to support that claim
    to date has been unjustified games and claims. There is absolutely
    nothing about the "wrapped" msgbox which makes it more useful than
    its unwrapped, non OO predecessor. The only real difference is a
    slight change in the calling sequence.

    > If you think otherwise, then point me to a tool that uses
    > "strict" MP that is more productive than VB6. I haven't seen one
    > yet.


    Again, your claim that the effectiveness of VB has ANYTHING to do
    with the recently added object wrappers. In fact, it seems to be
    based on some mistaken idea that VB was object oriented from the
    beginning. It wasn't. The only benefit is that those people who have
    been convinced that they "should" use an OO approach can use the
    components in their preferred manner. The productivity of VB.classic
    comes from the IDE (which is not inherently OO), the BASIC language
    (which is not OO), and the wide range of available components (SOME
    of which are OO, some of which are non OO but available with OO
    wrappers, and the rest are non OO without such wrappers).

    > Or, you could just admit that MP and OO are two methodologies that
    > complement each other.


    You are the one advancing fallacies in a pointless attempt to support
    your earlier claims about OO. OO is useful under very narrow
    circumstances, and counterproductive and dangerous in a wide variety
    of other circumstances.

    > Try not to phrase your answer(s) in the form of an unending string
    > of insults this time, eh?


    What, you don't like the competition? If you avoid the games, insults,
    and other negativity I will do likewise. If you continue them, your
    hypocritical plea for unilateral restraint on my part will be treated
    as it deserves.

    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  12. #162
    Phil Weber Guest

    Re: Speaking of strings...

    > This is it for me...You've won by fillabuster.

    Jason: Actually, I thought PhD's post to which you replied was better than most:
    he provided straight answers to several of your questions, he didn't prattle on
    about how "interesting" it was that you had trimmed your quotes, and the whole
    thing came in at under 10KB. Kudos, PhD!
    --
    Phil Weber



  13. #163
    Phil Weber Guest

    Re: Speaking of strings...

    > 2) It is closer to the way people normally think...
    > 3) It is closer to the way computers operate...


    PhD: The above two points seem to me to be contradictory. Otherwise, they would
    imply that people normally think the way computers operate. If people do not
    normally think the way computers operate, then MP cannot be "closer" to both of
    them, can it?
    --
    Phil Weber



  14. #164
    Phil Weber Guest

    Re: Speaking of strings...

    >> I wrote, what, 3 paragraphs?
    >
    > And packed volumes worth of misinformation and
    > fallacy into them.


    PhD: It takes skill to pack "volumes' worth" of anything into three paragraphs.
    If only you were half as skilled.

    > If you avoid the games, insults, and other negativity
    > I will do likewise.


    Not one to take the high road, eh? "Interesting."
    --
    Phil Weber



  15. #165
    Phil Weber Guest

    Re: Speaking of strings...

    > Very little of the code in those [MS] forms, controls, and
    > ActiveX DLLs is OO in origin or structure. Instead, it is the
    > older, non-OO code in an OO wrapper.


    PhD: Isn't /most/ OO code implemented as "non-OO code in an OO wrapper?" Most of
    the C++, C#, Java and VB code I've seen certainly has been. I've always thought
    that the "wrapper" (interface) is a large part of what /makes/ it OO. Are you
    saying that code doesn't qualify as "OO" unless it employs inheritance or
    overloading?
    --
    Phil Weber



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