Speaking of strings... - Page 9


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 9 of 17 FirstFirst ... 7891011 ... LastLast
Results 121 to 135 of 247

Thread: Speaking of strings...

  1. #121
    Jason Guest

    Re: Speaking of strings...


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >But Microsoft did this quietly and without much of it in evidence
    >except for those who looked for, or knew what they wanted from, OOP.
    >Even my VB6 package carton states precisely nothing about it. It just
    >says it's: "The most productive tool for creating fast business
    >solutions."
    >
    >MM


    Have you taken the time to look in the Programmer's Manual? There really
    is nothing subtle at all about the OO extensions to VB-classic since VB4.
    Right there in the menus:
    Add Module
    Add Class Module
    Add User Control

    Oh, criminey, what about the "Object Browser"?

    The "New" keyword? "Implements"? Mike, are you sure you have been using
    VB6 and not some other language all this time?

    I mean, it is obvious you don't know anything about VB.NET, but now you are
    claiming ignorance of VB6 too? Why the heck do you post to this group?

  2. #122
    Phil Weber Guest

    Re: Speaking of strings...

    > Anyway, try doing the same thing in VB6. If I remember correctly,
    > you have to implement a StdFont class, put all the methods on it
    > from the StdFont interface, and pass that in. Messy, poor design.


    Jason: No, in VB6, you can simply say:

    txtBox.Font.Italic = True

    --
    Phil Weber



  3. #123
    W.E. (Bill) Goodrich, PhD Guest

    Re: Speaking of strings...


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

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


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


    > >> > ***snip***


    > >Interesting to note how much relevant material was excised with
    > >that snip - including the "inconvenient" specifics that you seem
    > >unable to address. Predictable, but interesting from a
    > >psychological POV.


    > Look, I am trying to tell you to keep it short. I don't have time
    > to respond to 100 points in a 50 page document.


    So you avoid the specifics, and respond (poorly) to brief exerpts of
    a few general comments as though they were the substance of the post?
    Interesting. And telling.

    For instance, I note that you did not respond at all to the issue of
    the maintenance nightmares posed by the simple line:

    a.b = c.d + e.f

    in an inexpertly written OO project. And most particularly that you
    did not respond to the fact that those nightmares stem exclusively
    from the OO specific constructs.

    I also notice that you did not respond to the "definition" issue.

    > I also do not believe that the length of an argument necessarily
    > makes it more right or wrong.


    You might want to consider two points:

    1) Most readers of such groups interpret avoidance of such specifics
    as a tacit admission that you are unable to answer the points -
    that they are correct, but you don't want to admit it.

    2) It is possible - even desirable - to make several small responses
    to specific points in separate messages when the articles get too
    long for your tastes.

    Interesting that you excised the antecedent of the following, without
    giving any indication of doing so.

    > >Wrong again.


    > >> You simply don't know how to think "OO" in a practical way.


    > >Apparently, the problem here is your unwillingness (inability?) to
    > >critically examine the claims of the OO propaganda.


    > >> Classes provide encapsulation. #1 trait of OO.


    > >That claim is no longer accepted as valid, outside of the
    > >oversimplifications of the classroom. In fact, that claim has been
    > >debunked both in the Software Engineering and Academic communities.
    > >Since you have complained about your difficulties with reading
    > >comprehension, I will only cite one of the many examples from each:


    > >Software Engineering:
    > > http://www.cuj.com/articles/2000/000...topic=articles


    > So this article says that sometimes writing a non-member function is
    > good.


    Ah, yes ... There's that "tactical illiteracy" again. The article is
    noted here because of the WHY - the fact that member functions
    actually BREAK encapsulation rather than "providing" it (per your
    claim). It is one of literally hundreds that have made that point.

    [...]

    > I am not arguing that OO should be used to the exclusion of all
    > other techniques. I am arguing that OO, when used in addition to
    > other techniques, helps make complex problem sets more managable.


    But in this context you were explicitly arguing that - by definition -
    "classes provide encapsulation", and that was the "#1 trait of OO."
    that claim of yours is not only false, but rejected by its former
    proponents.

    > >Academia:
    > >http://researchweb.watson.ibm.com/hy...rs/sac2000.pdf


    > This article is all written for Java,


    More of the "tactical illiteracy" attempts? No, the article uses Java
    examples, but it is written for the design process and makes the point
    that the encapsulation claim is not valid.

    > and all the terminology is targeted at OO.


    Gee... ya think? In case you forgot, it was cited in response to one
    of your false claims about what you claimed to be the "#1 trait of
    OO." Perhaps (in your mind) I should have cited a paper on Ornamental
    Horticulture?

    > And academia.


    And here I went to all the trouble of introducing and labeling it as
    indicating the rejection of your claim within Academia.

    > Lots of big words to describe a medium-sized idea.
    > I'll wait for the movie, thanks.


    Now that you think about it, do you REALLY want to cast yourself as
    a "know nothing" advancing the cause of "OO as the standard for
    functional illiterates"?

    > >While the original theory was that classes would provide
    > >encapsulation, the modern reality is that they do not necessarily
    > >do so - and they often interfere with both encapsulation and
    > >modularization.


    > The key phrase being "not necessarily."


    Which, in turn, completely invalidates your earlier argument. So
    glad that you now see the error of your ways.

    [...]

    > Still, what is there is better than name-mangling and unenforcable
    > encapsulation.


    Interesting that you keep trying to limit alternatives in that way.
    Far from valid, of course, but interesting.

    > >> That makes things more modular.


    > >Not necessarily. Modularity and encapsulation are not the same
    > >thing.


    > No, but see if you can follow me here.


    Ah, so you now admit that your claim about modularity was false. That
    is really all you needed to say.

    > Good encapsulation hides complex code behind simpler interfaces.


    Here we go again with your weasel words. By now everyone recognizes
    the game of "that counterexample doesn't really count because it
    wouldn't be "good" encapsulation." Standard modularity hides complex
    code behind simpler interfaces. It is one of the defining
    characteristics of modularity.

    > Data and code are combined together, meaning all you have to deal
    > with is the interface.


    That fallacy is where all the trouble comes in. No, the interface is
    NOT "all you have to deal with". You also have to deal with what other
    classes - "friends", "Daughters", etc. - may be doing with that data,
    and what effects arise from code which is "transparently" executed
    when you are supposedly accessing the data. Not to mention the code
    which may be invoked when you are trying to perform simple operations
    on that data. And the effects on all of those other constructs if you
    make a simple (but perhaps ill considered) change to your base class.

    By leaving the code and data distinct from each other, you are much
    closer to only having to deal with the interface.

    > Not the code. Not the data.


    Nonsense. Most problem domains are rather specifically involved with
    "dealing with the data".

    > This is modular.


    It might be, if it weren't for the above (rather glaring) fallacies.

    > If it does not apply in every case, fine. It applies in most cases,


    No, only those few cases in which there is absolutely NO use of
    inheritance, overloading, etc.

    > which makes it a good tool.


    But since the "most cases" claim is false, do you concede that it is
    not "a good tool" for general use?

    > Good tools do not need to be perfect.


    But those imperfections must be kept firmly in mind when using them.
    And that is even more true of less-than-good tools such as classes.

    > >> "friend" classes are defined differently in different languages.
    > >> The more modern thought on this is to wrap things into
    > >> namespaces or packages, with classes that are in the same
    > >> namespace having some extra access. This is something that is
    > >> necessary to encapsulation in practice.


    > >And ironically, something that is inimical to encapsulation in
    > >practice.


    > >And even more inimical to modularity.


    > If used incorrectly.


    More to the point, if used anything less than perfectly. And you have
    acknowledged the rarity of such perfection.

    > There is no language or programming practice that I have heard of
    > that completely prevents bad programmers from writing bad code, or
    > prevents people who don't understand correct and incorrect uses of
    > the toolsets they have available from writing bad code.


    All the more reason to highlight the potential problems such tools can
    and do cause, and to advocate limiting their use to those rare cases
    in which the dangers can be limited and the need is great.
    Unfortunately, what we are seeing in the current debate is "everybody
    should use OO (especially classes) for everything unless absolutely
    forced not to." And dangerously false claims about what OO constructs
    "automatically" (or by definition) do. Unrealistic comparisons of
    Best Practices OO to worst practice non-OO only serve to perpetuate
    and worsen such problems.

    > >> Inheritance is a very useful tool - when combined with well
    > >> thought, stable code libraries.


    > >And a quick road to disaster when misused. But the currently
    > >relevant part of that is that it offers a major route for
    > >careless violation of both encapsulation and modularity.


    > If you don't know how to use the toolset, then you will probably
    > write bad code. What don't you understand about this?


    Your advocacy of "tools" which can - and do - increase the potential
    for disaster under ordinary circumstances. What don't you understand
    about the difference between the unrealistic, idealized conditions
    you keep trying to invoke (perfect programmers of the right sort,
    perfect managers of the right sort, perfect and stable specifications
    up front and throughout the life of the project, etc.), and the real
    world conditions under which these tools are actually used?

    By your own arguments, you should be outspokenly condemning the use
    of classes and their related constructs (inheritance, overloading,
    etc.) under any but your ideal conditions. Instead, you have thrown
    your lot in with the yahoos proclaiming that OO constructs should be
    the first tools of choice for everyone who writes programs
    (irrespective of background) and every problem domain.

    > If you have been taught good OO practices, and you have practical
    > experience with it, then you tend to correctly.


    Not really. Instead, you tend to take shortcuts, do things "the usual
    way", and make careless mistakes. Such is human nature. Look at your
    own sentence above. You have been taught good English practices, and
    you have practical experience with sentence construction. But you
    came up with the clause "then you tend to correctly" at the end. Even
    your semi mythical "correct" programmers, under your even more
    mythical ideal conditions, will make such mistakes.

    > Are you incapable on common sense on this point?


    You seem to be the one lacking in that department. You try to
    "counter" points about the problems caused by real world use of the
    OO tools under real world conditions with claims about the utility of
    those tools under unrealistically idealized conditions in the hands
    of unrealistically perfect programmers. If you want to argue that the
    tools in question should ONLY be used by such paragons and under such
    ideal conditions, be my guest. Otherwise, common sense indicates that
    your unrealistic arguments are largely pointless.

    > >> A good example is the java.io library. You can extend an
    > >> OutputStream and use it polymorphically in lots of other places.


    > >How special. You can also corrupt it - a good indication of the
    > >broken modularity.


    > Okay, what would you suggest would be better?


    Old fashioned modularity. As I have consistently maintained.

    > Let's have a specific example.


    The C I/O libraries.

    > You are really good at pointing out the flaws in everything.


    Thank you. The problem is that so many of you Cheerleaders act as
    though you are completely blind to those flaws.

    > Show me a methodology for programming where the programmer can't
    > screw anything up.


    Again with the unrealistic appeal to perfection. And from the one
    trying to appeal to "common sense" elsewhere. Tsk.

    The "common sense" reaction would be to note those elements with the
    greatest potential for causing and/or aggravating significant
    problems, and limit their use to ONLY those circumstances which
    DEMAND their use. IOW, only use them when there are no practical
    alternatives.

    Outside of certain specialized domains, such as AI and certain other
    simulations, old fashioned modular programming meets such criteria.
    Complete "separation of concerns" (to use the current Academic phrase)
    between data and code has several benefits in that regard. Making the
    difference between data access and subprogram invocation absolutely
    clear and unmistakable avoids many of the common problems associated
    with classes. And (contrary to the claims of early OO advocates) it
    is more intuitive - people really do tend to separate "things" and
    "actions", according to the psychological studies.

    In the same way, keeping certain operators fixed (in a language
    defined manner) eliminates significant potential for problems when
    compared to the alternative. Once again, the "+" and "=" in my
    example equation ("a.b = c.d + e.f") need not - and should not - be
    potential gateways to arbitrarily defined functionality. While it
    may not please the aesthetic sensibilities of certain advocates to
    explicitly call functions for "customized" operations (such as
    "adding" two data structures), it is far less likely to cause errors
    and misunderstandings.

    Concentrating a given function in one place (as opposed to
    "inheriting" it all over the map) significantly limits the outside
    impact of any internal changes, and makes any negative impacts easier
    to trace and fix. It also makes several kinds of errors easier to
    spot and avoid or correct. It also makes it easier to implement access
    control to internal data and scope/validity checking for data
    transactions.

    > Please explain it in such a way that even someone of my limited
    > intellect can understand.


    Are you planning on adding "tactical incoherence" to your tactical
    illiteracy?

    Ok, an even more simplified summary:

    1) Make a clear and unmistakable difference between data access and
    code execution.

    2) Keep all the code for one level of one function in one place.

    3) Limit operators to their language defined functions. Use obvious
    function calls for special versions of the operation.

    4) Follow the other general guidelines of Modular Programming where
    and when they make sense.

    > Or shut up.


    In your dreams. You have already trashed your own arguments in favor
    of general use of OO. I'm just helping you along.

    > >> Yes, there are other ways to do polymorphism,


    > >And here again, you have slid entirely into one of the predicted
    > >games, as described in the excised part of the previous post:


    > >: A few of the more thoughtful ones will throw in some circular
    > >: arguments on the order of "it makes it easier to do OO" and/or
    > >: "it makes it quicker and easier to program the way I like to - OO".
    > >: None have been able to show objective benefits over a completely
    > >: equivalent MP construct for any specific problem domain.


    > Okay, let me throw this back at you. You show me how your beloved
    > MP programming thingy is superior to your basic OO programming.


    > Again, please make it simple so I can understand it.


    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. Or those where it is only "a little better"
    than OO. 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.

    > >Since "polymorphism" is explicitly an OO construct, your argument
    > >reduces to "this OO construct is good because it addresses this
    > >other OO construct". That CLAIMED benefit completely avoids the
    > >issue under discussion (the extent to which the constructs break
    > >modularity), and is not linked to anything outside of your little
    > >circle.


    > >But the interesting issue here is whether you are even capable of
    > >making your arguments without such circular appeals to OO specific
    > >constructs? Can you (personally) even define polymorphism in a
    > >concrete way, without doing so in terms of other OO constructs? I
    > >seriously doubt it.


    > Well, I could break down an object


    ....OO specific construct...

    > into a virtual function table associated


    ....another OO specific construct (association)...

    > with some arbitrary data set,


    Why?

    > and say that if you have multiple virtual function tables that have
    > compatible functions, then you can swap a pointer to those function
    > tables, thereby creating polymorphism.


    ....Yet another OO specific construct. And one which - as predicted -
    you appear unable to define in any non-circular manner...

    > Of course, you would have to use pointers, which would ruin
    > enforcable encapsulation.


    But such use of pointers can be entirely consistent with modularity.

    > So nyah. :-P


    So again, can you define "polymorphism" in a concrete way, without
    doing so in terms of other OO constructs? Apparently not. Larry
    made a very unsuccessful stab at it, but you haven't even tried.

    > >> but it is a lot cleaner when you don't have to implement every
    > >> method on the object from scratch. Sometimes.


    > >Of course, that argument tries to take "as given" the claim that the
    > >OO construct "polymorphism" is a desirable (even necessary) end to
    > >itself, rather than one of many means to a more valid end. But that
    > >is not a given.


    > Nope, it is not useful or advisable in every situation.


    Not even in many situations.

    > That does not mean, however, that it is not a useful construct,


    One which you apparently cannot even define in a concrete way, without
    doing so in terms of other OO constructs. Some PARTS of what the OO
    cheerleaders CALL "polymorphism" are useful under spec220 47018 <3dabd5eb@10.1.10.29> article retrieved - head and body follows
    From: "Phil Weber" <pweber@nospam.fawcette.com>
    Newsgroups: vb.dotnet.discussion
    References: <3dab6992$1@10.1.10.29>
    Subject: Re: Calling web service via SSL (https)
    Date: Tue, 15 Oct 2002 02:13:44 -0700
    Lines: 6
    MIME-Version: 1.0
    Content-Type: text/plain;
    charset="Windows-1252"
    Content-Transfer-Encoding: 7bit
    X-Priority: 3
    X-MSMail-Priority: Normal
    X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
    X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
    NNTP-Posting-Host: 216.99.209.81
    Message-ID: <3dabd5eb@10.1.10.29>
    X-Trace: 15 Oct 2002 01:46:35 -0700, 216.99.209.81
    X-Authenticated-User: pweber
    Path: 10.1.10.29
    Xref: 10.1.10.29 vb.dotnet.discussion:47018

    Taiwo: I have moved your question to the vb.dotnet.technical group. In the
    future, please post VB.NET technical questions there. Thanks!
    --
    Phil Weber



  4. #124
    Mike Mitchell Guest

    Re: Speaking of strings...

    On 14 Oct 2002 13:42:03 -0700, "Jason" <jason@hotmail.com> wrote:

    >What happens when you have several programmers, or the number of lines of
    >code gets into the hundreds of thousands?


    What happened before OOP with several programmers or hundreds of kloc?
    People worked through the spec and developed software, taking pains to
    do a good and thorough job, not swayed or blown off course by
    new-fangled magic bullets. Very many projects are still being done
    that way. More and more programs will be written by the computer from
    input directly from users who are intimately conected with the actual
    tasks to be computerised, without the intervention of system analysts
    and all the other IT plethora. Programming will become so easy and
    accessible that only a few mission-critical types of application
    (military, medicine) will still actively require the input from highly
    expert computer programmers. All business apps will be based on
    standard programs which ordinary workers will customise. You'd buy
    Payroll Construction Units S, T5, and Q43 (say), then glue them
    together by utilising the Smart Interfaces.

    >I'm not talking about scripting simple quick-and-dirty programs here. As
    >I have stated in every post on this subject, OOP is not necessary for smaller
    >programs with only one developer/maintainer. Doesn't hurt, and typically
    >only helps a little if at all.


    Why do you always equate "small to medium" with quick-and-dirty? To my
    mind, a quick-and-dirty solution is something I can cobble together in
    half-an-hour. In fact, I have often noticed just how difficult it is
    to take a quick-and-dirty app and then endeavour to "enhance" it, just
    a bit, to satisfy management when it's breathing down one's neck for
    an urgent fix. Nigh on impossible! A quick-and-dirty app is just that:
    Quick. And dirty. Just load this or that file, modify every nth
    character, then save it to these tables. That kind of thing.

    >OOP is a methodology that is meant to address complexity in software. You
    >have already stated that you have not worked on large code bases or with
    >lots of other programmers.


    Correct. But neither have very many other programmers, irrespective of
    the main language they write in, worked on other large code bases or
    with lots of other programmers. In the scheme of things, there ain't
    many programmers in the world anyway.

    >
    >************************************
    >
    >Anyway, Mike, do you realize that a Form in VB6 is a Class object? Do you
    >realize that every single OCX and ActiveX DLL you use in your project is
    >an object library (without inheritance, but having encapsulation and polymorphism)?


    Oh, so we're back to this old saw again, are we?!! Forms are objects,
    I use forms, ergo I am an OO programmer! OCXs, ActiveXs are objects, I
    use same, ergo I am an OO programmer! (Yawns...)

    >Do you use databases? ADO and DAO are both based around OO design principles.


    Ditto.

    >XML? MSXML is all objects, and lots of interfaces.


    I don't use XML or other bloatware. I get fat enough from eating
    Sausage 'n Egg McMuffins.

    >Do you use any OCXs in your applications? Objects again (that's what the
    >"O" stands for).


    I thought we'd already dealt with this one, but, yes, I do, and yes,
    they're objects, and yes, if it makes you happy, ergo I *am*
    indubitably an OO programmer!

    >You may not be writing your own classes in VB6 (unless you use Forms, which
    >are classes), but you are definitely using objects almost everywhere.


    Using...using...using. But not writing! That's the difference. Once,
    I'd link an object file created by MASM to a QuickBASIC program. Did
    that make me a MASM programmer?

    >If you REALLY don't want to use objects at all, may I suggest you go back
    >to programming C. Remember the 70 line "Hello World" programs???


    I couldn't go back to programming [in] C, as I never did it in the
    first place. Well, except to write a DLL or two for VB, or create some
    object files in C to link in with QuickBASIC/PDS.

    >Even VB3 used objects. Forms were basic objects, and VBXs were objects with
    >a poorly design communication standard. But they were definitely using a
    >component design even then, and components are objects.


    Okay, I'm getting the message now, I think...

    >Mike! Get this! You are using OO in every program you have written from
    >at least VB3 on! How 'bout them apples.


    Great! I shall update my CV this very day and make sure OOP figures
    largely in my long list of skills and talents.

    MM

  5. #125
    Jason Guest

    Re: Speaking of strings...


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >On 14 Oct 2002 13:42:03 -0700, "Jason" <jason@hotmail.com> wrote:

    <<SNIP>>
    >Great! I shall update my CV this very day and make sure OOP figures
    >largely in my long list of skills and talents.
    >
    >MM


    The point, Mike, is that even though you are not writing your software using
    OOP principles, you are using and benefitting from OOP libraries and methodologies.

    OCXs are useful. DLLs are useful. You, as the end-product programmer, don't
    have to structure your own code as OOP in order to productively use other
    people's OO libraries.

    The same thing is true of .NET. You don't have to do OO in order to use
    it effectively and productively. Not everything you write will use OO.
    In fact, much of it will use OO in the same manner you are used to - no new
    classes, no inheritance (or at least very little).

    Just as in VB6, in .NET you can use other people's objects without having
    to write everything as an object.

    VB.NET and C# both contain Select Case (or switch). Both have If ... Then
    constructs. Both support methods that do not run in the context of a class
    (properties, functions, subs).

    Mike, I am a guy who is used to programming with components. I have a bunch
    of stock DLLs that I use regularly, and I have even done some fairly complex
    OCXs at times. My job has typically been that when there is no architecture
    in place, I provide the libraries to put one in place.

    This is the kind of stuff that demanded OO even in VB6. For this stuff,
    you MUST write classes, and sometimes use interfaces and some form of polymorphism.
    There is a way in VB to work around this, but it is more trouble than it
    is worth.

    And anyway, anyone can use objects without understanding how to write a class.
    You've been doing it for years, using components written by guys like me,
    all the time saying how bad OO is.

    Again, OO, used correctly, is a great tool. And again, used incorrectly,
    you can make some pretty bad code.

  6. #126
    Jason Guest

    Re: Speaking of strings...


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

    Okay, bill. You win. I can't keep up. You are right. I am wrong.

    Of course, I have no idea why you are right, or even what you are talking
    about, really. I'm just tired of bantering back and forth when the only
    point you seem to have is that everyone else in the world but you is a big
    idiot.

    Heck, even the <<snip>> above took me about 30 seconds to scroll through
    so I could delete it. Should have done a "Select All...".

    You win. By sheer volume, you win. I am just amazed at how much text you
    can write without having a single factual statement. You should be in politics,
    not software.

  7. #127
    W.E. (Bill) Goodrich, PhD Guest

    Re: Speaking of strings...

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

    [...]

    Interesting that you went beyond your usual avoidance of substance to
    quote nothing more than my .sig and company attachment.

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

    > And don't just post some obscure academic articles that don't tell
    > anyone anything - actually explain what you are talking about.


    It would take a good sized book to fully explain modular programming,
    though I have covered some of the highlights from time to time. Your
    own demonstrated ignorance on the subject of modular programming says
    sad things about your education and experience. And I would hardly
    call Scott Meyers' piece an "obscure academic article."

    > I for one am getting really tired of your negative posts.


    LOL!!! Take a look in the mirror, kid. You are the one with "crap"
    this and name-call that, all tied up with sarcasm and "You're not
    capable" claims. You are also the one who started out with strident
    advocacy of things OO, and then - when called on specifics - hid
    behind weasel words about "in the right hands" and the like. When you
    set a negative tone with your own stridency, you lose the moral right
    to complain about the "negative tone" of the responses to your posts.

    > You trash everything anyone has to say,


    More tactical illiteracy? I have supported statements by Dan, Joe,
    Karl, Tim, and a number of others. And I have let quite a few
    statements pass without comment.

    > and you never offer up anything even remotely useful as a
    > substitute.


    Again with the tactical illiteracy? Or is it tactical amnesia? Under
    equivalent conditions, modular programming has proven far more useful
    (and safer) than OOP.

    > Don't like OO?


    Not for general use. The constructs cause far too many problems, far
    too easily. And it tends to introduce significant unnecessary
    overhead.

    > What's better?


    Modular programming, under equivalent conditions.

    > And why?


    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.

    > Put up or shut up.


    I have "put up" from the beginning. Unlike your arguments, which have
    consistently misrepresented my statements (and those of others) and
    modular programming, used terms you couldn't define or support without
    circular argument, and tried to "compare" the modalities under clearly
    non-equivalent conditions.

    --

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

  8. #128
    Mike Mitchell Guest

    Re: Speaking of strings...

    On Tue, 15 Oct 2002 01:14:38 -0600, "W.E. (Bill) Goodrich, PhD"
    <bgoodric@netzero.net> wrote:

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


    A very succinct summary of my feelings about this! Brilliant!

    MM

  9. #129
    Jason Guest

    Re: Speaking of strings...


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >On Tue, 15 Oct 2002 01:14:38 -0600, "W.E. (Bill) Goodrich, PhD"
    ><bgoodric@netzero.net> wrote:
    >
    >> 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.

    >
    >A very succinct summary of my feelings about this! Brilliant!
    >
    >MM


    The one thing you seem to be ignoring is that this is not how the components
    you use in VB are written.

    Mike, Bill, if either of you can honestly say that you don't use any other
    components in your code, that you use straight VB-classic syntax and do all
    your GUIs through the API, then you are doing strict modular programming.
    Otherwise, you are putting an MP wrapper over an architecture that is based
    on OO, which negates most of the arguments above.

    Heck, most of the arguments above are anti VB-classic. Think about it.


  10. #130
    Mike Mitchell Guest

    Re: Speaking of strings...

    On Tue, 15 Oct 2002 14:24:06 +0100, Mike Mitchell
    <kylix_is@yahoo.co.uk> wrote:

    > Programming will become so easy and
    >accessible that only a few mission-critical types of application
    >(military, medicine) will still actively require the input from highly
    >expert computer programmers. All business apps will be based on
    >standard programs which ordinary workers will customise. You'd buy
    >Payroll Construction Units S, T5, and Q43 (say), then glue them
    >together by utilising the Smart Interfaces.


    And I was just boning up on Gartner's recent projections for the next
    few years. One of the things they predicted was: "Business units, not
    IT, will make most application decisions" (see
    http://techupdate.zdnet.com/techupda...885192,00.html
    point 9)

    This is kind of what I mean by handing over development of common
    business apps to the end users, or pretty much the end users. They are
    the ones who know the business process inside their company inside
    out. Why go to the hassle of having to get their knowledge transferred
    to IT via system analysts or external consultants, who know computing
    but are not likely to be very conversant with the business, when the
    people at the coal face can do it for themselves?

    MM

  11. #131
    Jason Guest

    Re: Speaking of strings...


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
    >While classic VB in the later versions included more object-based
    >design features, it was still very much a component-based development
    >system which largely expected users to build their apps from building
    >blocks they painted on to a form. Which is how the majority of VB
    >users used it.
    >
    >With VB.Net and with respect to its oopification, I
    >don't think one can remain in splendid isolation from the concept of
    >OOP to quite the same degree. Sooner or later (and probably sooner) if
    >you're going to want to do things the VB.Net way, you're going to have
    >to know the OOP way of doing it, if only because you have to
    >continually talk to the framework. And the only way to do that is by
    >learning how. I cannot believe that anyone starting with VB.Net would
    >seriously contemplate a career with it without ever knowing OOP in
    >some depth.
    >
    >MM



    MM, you are mistaken. Just plain wrong. Object libraries in the framework
    can be used just the way object libraries wrapped in DLLs are used in VB-classic
    today.

    You refuse to try the language, and you refuse to accept this simple fact.


    If you want to extend controls or do advanced things in VB.NET (like write
    libraries, if you call that advanced), you need to know a bit more OO. If
    you are just using the libraries, then it is exactly like with VB-classic
    today, only you have a lot more functionality available to you.

    Really. Seriously.

    You can write a VB-classic-like application in .NET without using inheritance.
    Just using function and sub calls. Seriously. It even does events without
    resorting to that nasty polymorphic callback thing that Java does. It's
    just like VB6, but a little cleaned up. Not language compatible, but that
    isn't what we are talking about here.

    Seriously, you can start programming VB.NET without knowing a lick of OO.
    Well, you have to know how to USE objects. You had better be familiar with
    event-driven programming, but if you know VB6 then you already think that
    way.

    How did you do it in VB6? Create a form, add a button, double click on the
    button and add some code.

    How do you do it in VB.NET? Create a form, add a button, double click on
    the button and add some code.

    Mike, it is EXACTLY the same conceptually. VB.NET adds a few more OO bells
    and whistles which help with writing those components you love. It also
    cleans up the language a bit - it's a bit more consistent now. And better
    garbage collection. But that is about it.

    If you program by creating forms, adding controls, and then writing code
    behind them, you will be right at home in Visual Studio.NET.

    Really. Without any more OO than you are using right now.

  12. #132
    Mike Mitchell Guest

    Re: Speaking of strings...

    On 15 Oct 2002 07:30:20 -0700, "Jason" <jason@hotmail.com> wrote:

    >The point, Mike, is that even though you are not writing your software using
    >OOP principles, you are using and benefitting from OOP libraries and methodologies.


    I have absolutely no problem with that. I am grateful to those
    third-party companies that sell a whole bunch of functionality for
    just a couple of hundred dollars. Work that would take me weeks, if
    not months, to do on my own, and probably not as effectively. I don't
    cut my own screws, saw my own lumber, or mill my own flour. I go to
    the relevant supplier and buy the ingredients. This is how I see
    classic VB programming. I am pretty nifty in the kitchen and can
    rustle up quite a few tasty dishes if I have the ingredients. In a
    similar way I'll take this QuickSort routine and that B+ tree
    structure, then mould my app from these and other components. An
    object such as a list box is just a black box to me. Whether it got to
    my desktop via OOP or via the Staten Island Ferry, I just don't care.
    And if I need to enhance something with the API or even get the
    functionality I need solely by using the API, well, enough people have
    documented it by now to make it easy in the vast majority of cases.

    >OCXs are useful. DLLs are useful. You, as the end-product programmer, don't
    >have to structure your own code as OOP in order to productively use other
    >people's OO libraries.


    See above.

    >The same thing is true of .NET. You don't have to do OO in order to use
    >it effectively and productively. Not everything you write will use OO.
    >In fact, much of it will use OO in the same manner you are used to - no new
    >classes, no inheritance (or at least very little).


    While classic VB in the later versions included more object-based
    design features, it was still very much a component-based development
    system which largely expected users to build their apps from building
    blocks they painted on to a form. Which is how the majority of VB
    users used it. With VB.Net and with respect to its oopification, I
    don't think one can remain in splendid isolation from the concept of
    OOP to quite the same degree. Sooner or later (and probably sooner) if
    you're going to want to do things the VB.Net way, you're going to have
    to know the OOP way of doing it, if only because you have to
    continually talk to the framework. And the only way to do that is by
    learning how. I cannot believe that anyone starting with VB.Net would
    seriously contemplate a career with it without ever knowing OOP in
    some depth.

    MM

  13. #133
    Jason Guest

    Re: Speaking of strings...


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

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

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

    What is a ListBox? What is a Collection? What you are telling me is that
    you prefer to get right down to the metal and program char-array strings
    and use functions for everything.

    Or else you are telling me that you use objects all the time, you just prefer
    that someone else write them. In this case, you are saying that you like
    the results of OO programming, you just don't wish to use it yourself.

    (2) Which is it?

    You can't have it both ways. Either you use a language that does not use
    any object constructs, or you don't. Like I have been saying, OO is very
    useful when applied correctly (the component model for OCXs, for instance).

  14. #134
    Jason Guest

    Re: Speaking of strings...


    >It would take a good sized book to fully explain modular programming,
    >though I have covered some of the highlights from time to time.


    Then it is neither simple nor intuitive. It takes about 3 or 4 chapters
    to explain OO in the context of the .NET implementation.

    >Your
    >own demonstrated ignorance on the subject of modular programming says
    >sad things about your education and experience. And I would hardly
    >call Scott Meyers' piece an "obscure academic article."


    It sure looked academic to me. Did I use the word obscure? I don't know
    that for a fact. But the article - if I remember correctly - was not written
    in a way that made it all that useful to me. Sounded more like a thesis
    paper.

    *************************

    On another point, we are talking about things in the context of VB6 and VB.NET
    here, right? I mean, when you say "Modular Programming," you are referring
    to something you can do in VB6 and not some new concept for which a language
    still needs to be written. In other words, using modules of functions, arrays,
    Types, etc. Right? Instead of Class modules, the Implements keyword, etc.
    Correct?

    That is what you are advocating is superior in all ways to OO?

    Correct me on this if I am wrong here.

  15. #135
    PWilmarth Guest

    Re: Speaking of strings...


    If, as you imply, OOP is not the solution, but part of the problem, then what
    would you suggest as a solution?

    Using analagies to other professions is all very well and good, but none
    of them live in a perfect world either. To cite your example of the general
    practitioner, even a good general practitioner has to know something about
    about cardiology, as well as oncology, hematology, orthopedics, obstretrics,
    pharmacology, nutrition, neurology, dermatology, toxicology, emergency medicine,
    etc, etc. He (or she) doesn't need to be an expert in each of these areas,
    but needs to at least have enough fundamental knowledge of each area in order
    to know when a specialist in each of these areas is required. Each one of
    these specialists has their own paradigm, and you might get a different solution
    to a given problem, depending on who you ask.

    You write very lengthy dissertations about the weaknesses of OOP as a methodology,
    but, Mike, in your dream world, how would you like to see things done? And
    how are you moving your profession in that direction?



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