Borland and me: We both want less code and more pictures! - Page 2


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 2 of 5 FirstFirst 1234 ... LastLast
Results 16 to 30 of 61

Thread: Borland and me: We both want less code and more pictures!

  1. #16
    David Bayley Guest

    Re: Borland and me: We both want less code and more pictures!

    Mike Mitchell wrote:

    >> The availability of re-usable, protocol rich, components across
    >> company boundaries, is something that has driven the popularity of
    >> OOP languages. Even the anti-OO Mike Mitchell agrees with this
    >> point, in that he advocates the easy re-use of other people's OO
    >> components (so long as he doesn't have to write them himself!).

    >
    > But it's not the OOP aspect of those components that interests me,
    > it's the components themselves. [...]


    Yes it is the OO aspects of those components, you just don't realise it.
    A component is a physical file that defines one or more Objects, and all
    their associated meta-data.

    > [...] Were VBX components written according
    > to OOD principles?


    Yes, they were. There is possibly a criticism that VBX/OCX components
    are "Object-Based", rather than full blown "Object-Oriented", but I
    think this is nit picking around the essence of OO.

    > I lift the hood on my car and study the alternator. It makes juice for
    > the battery. How it works internally interests me not one iota. If it
    > breaks I can fit a new part for 50 bucks. End of story.


    Bingo! Apply the same principles to your own modules, it really isn't
    that difficult. There are even visual modelling tools around that I
    guess you will find appealing, but they are rather expensive at the
    moment.

    --
    David




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

    Re: Borland and me: We both want less code and more pictures!

    In article <3d6beb2c@10.1.10.29>,
    "Tom Shelton" <toms@dakcs.com> writes:

    > "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    > news:3d6bea9f.1221944@news.devx.com...


    > > On Tue, 27 Aug 2002 11:15:03 -0600, "Tom Shelton"
    > > <toms@dakcs.com> wrote:


    > > >And there Mike is the beauty of OOP. It is so wonderful you
    > > >finally got it! Welcome to the fold!


    > > Excuse I, Mr Clever ****! Show me where I got down and dirty
    > > with classes! Show me where I had to plan for my inheritance!
    > > Show me where I first designed my object hierarchy! Those
    > > components could be written in hand-coded assembler for all I
    > > know (or care). I just use the results, and that's all I want to
    > > know (or do).


    > Again, you get it!


    But apparently you don't. Or choose not to. He is very explicitly
    pointing to the difference between modular programming (which he
    supports) and OOP (which he doesn't). You (and others here) keep
    trying to blur that distinction and muddy the debate by incorrectly
    characterizing OOP as an improved version of modularity and thereby
    claiming the benefits of modularity for OOP.

    > That is the whole point of OOP - code reuse.


    No, that is the whole point of modularity. The elements which
    differentiate OOP from modularity actively weaken the benefits and
    complicate the mechanics of code reuse. As he has repeatedly pointed
    out.

    > The user of your library cares nothing about implementation - only
    > the interface and the results.


    In modular programming that would be true. In OOP, the user also
    cares about issues of inheritance, overloading, fragile base classes,
    etc. Unlike a modular Black Box, the OOP libraries are white and gray
    boxes. The issues of the "interface" of a class are far more complex
    than those for a Black Box module. And the ability to corrupt the
    behavior of class "methods" is far more easily available than any
    ability to corrupt the behavior of black box modules. And the issues
    surrounding the "results" are similarly impacted.

    > It is modular programming taken to the next step.


    No, it is modular programming corrupted and weakened by faddish
    constructs. Contrary to your characterization, classes, inheritance,
    overloading, etc. - those elements which differentiate OOP from
    standard Modular Programming - weaken modularity.

    --

    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. #18
    Tom Shelton Guest

    Re: Borland and me: We both want less code and more pictures!


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
    news:3D6C4291.63A22D8C@netzero.net...
    > In article <3d6beb2c@10.1.10.29>,
    > "Tom Shelton" <toms@dakcs.com> writes:
    >
    > > "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    > > news:3d6bea9f.1221944@news.devx.com...

    >
    > > > On Tue, 27 Aug 2002 11:15:03 -0600, "Tom Shelton"
    > > > <toms@dakcs.com> wrote:

    >
    > > > >And there Mike is the beauty of OOP. It is so wonderful you
    > > > >finally got it! Welcome to the fold!

    >
    > > > Excuse I, Mr Clever ****! Show me where I got down and dirty
    > > > with classes! Show me where I had to plan for my inheritance!
    > > > Show me where I first designed my object hierarchy! Those
    > > > components could be written in hand-coded assembler for all I
    > > > know (or care). I just use the results, and that's all I want to
    > > > know (or do).

    >
    > > Again, you get it!

    >
    > But apparently you don't. Or choose not to. He is very explicitly
    > pointing to the difference between modular programming (which he
    > supports) and OOP (which he doesn't). You (and others here) keep
    > trying to blur that distinction and muddy the debate by incorrectly
    > characterizing OOP as an improved version of modularity and thereby
    > claiming the benefits of modularity for OOP.


    Nothing muddy about it - OOP IS an improved version of modular programming.

    > > That is the whole point of OOP - code reuse.

    >
    > No, that is the whole point of modularity. The elements which
    > differentiate OOP from modularity actively weaken the benefits and
    > complicate the mechanics of code reuse. As he has repeatedly pointed
    > out.


    Not. There isn't much difference between a poorly written module and a
    poorly written class. Though a well written class provids a lot more saftey
    then a module.

    > > The user of your library cares nothing about implementation - only
    > > the interface and the results.

    >
    > In modular programming that would be true. In OOP, the user also
    > cares about issues of inheritance, overloading, fragile base classes,
    > etc. Unlike a modular Black Box, the OOP libraries are white and gray
    > boxes. The issues of the "interface" of a class are far more complex
    > than those for a Black Box module. And the ability to corrupt the
    > behavior of class "methods" is far more easily available than any
    > ability to corrupt the behavior of black box modules. And the issues
    > surrounding the "results" are similarly impacted.


    Bill, I can tell you have never worked with OOP. Most OOP languages draw a
    strict line between interface and implementation. Providing very strict
    access control to methods and fields. Something that is often not available
    in more modular/procedural programming languages. Yes, you can get your
    self in trouble if your not careful. I don't think anyone has ever said you
    couldn't, but overall the benifits, IMHO and experience, far outway the
    "pitfalls". If anything, OOP tends to force the developer to spend more
    time in the design phase of the project - which is a good thing if you ask
    me. VB and other procedural type languages tend to encourage the
    design-as-you-code philosphy, and we both know what kind of mess that can
    result in.

    > > It is modular programming taken to the next step.

    >
    > No, it is modular programming corrupted and weakened by faddish
    > constructs. Contrary to your characterization, classes, inheritance,
    > overloading, etc. - those elements which differentiate OOP from
    > standard Modular Programming - weaken modularity.


    Bull crap, you can hardly call OOP a fad - it is a concept almost as old as
    I am. But, hey in VB.NET you don't have to use OOP if you don't want to...
    It still allows the same old object based, mixed mode, programming style of
    VB.CLASSIC. And despite you and MM's tired claims to the contrary, I think
    it has been amply shown that VB.NET makes most tasks simpler then
    VB.CLASSIC. I can tell you, that now that I've been working almost
    exclusively with C# (I know, I know, but that is the .NET language the
    company I work for standardized on... Thank goodnes...) for the last few
    months, I simply dread every time I have to open one of my VB5/6 programms
    for maintenance.


    Tom Shelton



  4. #19
    Zane Thomas Guest

    Re: Borland and me: We both want less code and more pictures!

    On Tue, 27 Aug 2002 21:25:05 -0600, "W.E. (Bill) Goodrich, PhD"
    <bgoodric@netzero.net> wrote:

    >> It is modular programming taken to the next step.

    >
    >No, it is modular programming corrupted and weakened by faddish
    >constructs.


    I love it when you and your buddy Mikee so clearly expose your ignorance.
    OOP has been around in various versions for well over 20 years. Smalltalk
    and SCOOPS, for instance, predate c++ by several years. Object-oriented
    languages and concepts were the subject of much research for a very long
    time before they suddenly became fads to people like you.

    If you don't want to stay current with programming technologies from the
    80s then fine don't. But please try to scrape together $0.25 worth of
    integrity and quit blathering on as if you know something about
    programming ok?



    --

    *--------={ Fine Art for .NET }=--------*
    | .Net Components @ www.abderaware.com |
    *---------------------------------------*

    Turn on, tune in, download.
    zane a@t abderaware.com

  5. #20
    W.E. (Bill) Goodrich, PhD Guest

    Re: Borland and me: We both want less code and more pictures!

    In article <3d6c463c@10.1.10.29>,
    "Tom Shelton" <tom@mtogden.com> writes:

    > "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
    > news:3D6C4291.63A22D8C@netzero.net...


    > > In article <3d6beb2c@10.1.10.29>,
    > > "Tom Shelton" <toms@dakcs.com> writes:


    > > > "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    > > > news:3d6bea9f.1221944@news.devx.com...


    > > > > On Tue, 27 Aug 2002 11:15:03 -0600, "Tom Shelton"
    > > > > <toms@dakcs.com> wrote:


    > > > > >And there Mike is the beauty of OOP. It is so wonderful you
    > > > > >finally got it! Welcome to the fold!


    > > > > Excuse I, Mr Clever ****! Show me where I got down and dirty
    > > > > with classes! Show me where I had to plan for my inheritance!
    > > > > Show me where I first designed my object hierarchy! Those
    > > > > components could be written in hand-coded assembler for all I
    > > > > know (or care). I just use the results, and that's all I want
    > > > > to know (or do).


    > > > Again, you get it!


    > > But apparently you don't. Or choose not to. He is very explicitly
    > > pointing to the difference between modular programming (which he
    > > supports) and OOP (which he doesn't). You (and others here) keep
    > > trying to blur that distinction and muddy the debate by incorrectly
    > > characterizing OOP as an improved version of modularity and thereby
    > > claiming the benefits of modularity for OOP.


    > Nothing muddy about it - OOP IS an improved version of modular

    ^^^^^^^^

    To use the local vernacular, you misspelled "degraded". Having lost
    the very essence of modularity, it is no longer modular programming.

    > programming.


    > > > That is the whole point of OOP - code reuse.


    > > No, that is the whole point of modularity. The elements which
    > > differentiate OOP from modularity actively weaken the benefits and
    > > complicate the mechanics of code reuse. As he has repeatedly
    > > pointed out.


    > Not.


    Deny it all you choose - the facts remain the facts. And I notice that
    you were unable to offer even one substantial refutation. Plenty of ad
    hominem, scatology, unsupported assertion, and the like. But no
    substance.

    > There isn't much difference between a poorly written module and a
    > poorly written class.


    I notice you pad your bet there. And in so doing, invalidate your
    argument. Let's be specific here: EVERY potential problem with a
    "poorly written module" is ALSO a potential problem with each and
    every method of a poorly written class. You cannot name an exception,
    because there are none. By contrast, there are many potential problems
    with poorly written classes that are NOT applicable to a (non OOP)
    module - even a poorly written one. How many of those can you name?
    Here, I'll give you one for free: Fragile Base Class.

    > Though a well written class provids a lot more saftey
    > then a module.


    Wrong. And again, your choice of wording (comparing "well written
    class" with undifferentiated "module") shows your own lack of
    confidence in your argument. You play the "well written" game so that
    any specific elements used to refute your claim can be waved aside
    with "But a 'well written' class would not..."). Inheritance,
    overloading, etc. render even well written classes less safe than
    the corresponding modules. Even the Academics have started to admit
    that.

    > > > The user of your library cares nothing about implementation -
    > > > only the interface and the results.


    > > In modular programming that would be true. In OOP, the user also
    > > cares about issues of inheritance, overloading, fragile base classes,
    > > etc. Unlike a modular Black Box, the OOP libraries are white and gray
    > > boxes. The issues of the "interface" of a class are far more complex
    > > than those for a Black Box module. And the ability to corrupt the
    > > behavior of class "methods" is far more easily available than any
    > > ability to corrupt the behavior of black box modules. And the issues
    > > surrounding the "results" are similarly impacted.


    > Bill, I can tell you have never worked with OOP.


    Not only is that a rather pointless ad hominem, it is incorrect. I
    have worked extensively with OOP, and seen many of the disastrous
    problems I have been describing. Badly done OOP is even harder to
    debug and maintain than old fashioned "spaghetti code" - especially
    when the original designer(s) and/or programmer(s) are no longer
    available.

    > Most OOP languages draw a strict line between interface and
    > implementation.


    So do most modular languages, such as C. But nothing prevents a
    programmer from circumventing that "strict line" in the OO languages.
    In fact, mechanisms such as inheritance make it easier to do so in
    the OO languages than in the modular languages.

    > Providing very strict access control to methods and fields.


    And then providing convenient ways to circumvent them. Thereby
    rendering them LESS safe than the purely modular languages.

    > Something that is often not available in more modular/procedural
    > programming languages.


    Nonsense. Even assemblers have tools for defining scope, etc. While
    the modular "access control" mechanisms allow fewer options for
    extending access in elaborate ways, that tends to render them more
    (rather than less) secure. And unlike those elaborate OO constructs,
    the modular access control mechanisms add little or no overhead.

    > Yes, you can get your self in trouble if your not careful.


    Exactly. More to the point, you can get yourself - and your
    successors on the project - in trouble in more ways (and more
    severely) in OOP than you can in MP. And in OOP you can get yourself
    in trouble in ALL the same ways you can in MP, as well as in so many
    ways which are unique to OOP.

    > I don't think anyone has ever said you couldn't, but overall the
    > benifits, IMHO and experience, far outway the "pitfalls".


    Your mode of argument strongly indicates that your perception of those
    benefits (and experiences) is heavily colored by your expectations -
    your opinion. But as badly as you want to maintain that belief, your
    doubts continue to leak out. You continue to "qualify" your claims and
    attempt to shift the scope of the discussion (as below), as well as to
    use ad hominem arguments and inappropriate language to draw attention
    away from the substantial problems with your claims.

    > If anything, OOP tends to force the developer to spend more time in
    > the design phase of the project - which is a good thing if you ask
    > me. VB and other procedural type languages tend to encourage the
    > design-as-you-code philosphy, and we both know what kind of mess
    > that can result in.


    You *do* realize what you just wrote, don't you? You just declared OOP
    inappropriate for RAD, for environments with evolving specs, and for the
    VERY large percentage of IT and engineering shops in which the ratio
    of design time to coding time is set by management fiat rather than
    chosen by the programmer. Worse (from the standpoint of your thesis),
    you have acknowledged MM's points about complexity and the fact that
    OOP requires more design effort than MP.

    If your work environment allows you the luxury of such extended design
    phases, you could just as easily use that additional time to more
    rigorously design an MP implementation. The argument that the tool
    "forces" changes in management and programmer practice toward more
    rigorous practices has been used - and refuted - since the early days
    of "Structured Programming". In practice, "design-as-you-code" (with
    minimal upfront design and incomplete specs) is far more prevalent
    than extensive, lengthy, rigorous up-front design. And as long as
    "time is money" in business, that will continue to be true. And in
    such an environment, OOP is a recipe for disaster.

    > > > It is modular programming taken to the next step.


    > > No, it is modular programming corrupted and weakened by faddish
    > > constructs. Contrary to your characterization, classes, inheritance,
    > > overloading, etc. - those elements which differentiate OOP from
    > > standard Modular Programming - weaken modularity.


    > Bull crap,


    There you go with your scatology. All that does is reinforce the idea
    that your belief is emotional rather than rational.

    > you can hardly call OOP a fad - it is a concept almost as old as
    > I am.


    I didn't realize you were that young. That explains some things. The
    application of the OOP specific elements (as opposed to the MP
    elements which you lump together with them) to general problem areas
    rather than the relatively narrow and specialized areas of AI,
    simulation, and the like is both relatively recent and distinctly
    faddish. And as with most such fads, it is primarily supported by
    emotional testimonials, subjective claims, and contrived comparisons
    to unrealistic "samples" of other methodologies.

    > But, hey in VB.NET you don't have to use OOP if you don't want to...


    Really? I can define UDTs without them becoming Objects? And use them
    as variable types rather than objects? I can use variants for my
    "flexible" variables rather than using Objects?

    > It still allows the same old object based, mixed mode, programming
    > style of VB.CLASSIC.


    Not quite. It can't do such "mixed mode" things as populating
    contiguous UDT variables from - and saving them to - binary files. In
    fact, there are quite a few such elements of VB.CLASSIC programming
    that it does not allow.

    > And despite you and MM's tired claims to the contrary, I think
    > it has been amply shown that VB.NET makes most tasks simpler then
    > VB.CLASSIC.


    No at all. It has only been shown that it makes certain narrow
    categories of tasks (such as ASP projects) simpler. OTOH, it HAS been
    shown that it makes a wide variety of tasks and applications more
    difficult or outright impossible. For instance, a program to read a
    ..WAV file, chart the samples, and allow manipulation of individual
    data points (trivial in VB6) is far more complicated in VB.NET, and
    impossible if the program has to run on Win95 machines in addition to
    later systems.

    > I can tell you, that now that I've been working almost exclusively
    > with C# (I know, I know, but that is the .NET language the company
    > I work for standardized on... Thank goodnes...)


    Isn't it interesting how many of the most vocal and assertive
    supporters of VB.NET are using C# instead?

    > for the last few months, I simply dread every time I have to open
    > one of my VB5/6 programms for maintenance.


    Not surprising. Given the proclivities you have exhibited here, your
    attempts to coerce VB5/6 into your notion of OOP must be nightmarish
    to behold - much less to maintain.

    --

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

  6. #21
    Tom Shelton Guest

    Re: Borland and me: We both want less code and more pictures!

    [snip pompus, insulting, and clueless arguments]

    Bill we obviously disagree on the worth of OOP. But who cares, you don't
    have to use it in VB.NET anymore then you have to in VB.CLASSIC. You can
    continue to create modules and use them just like in VB.CLASSIC.

    By the way, I use C# in .NET for 2 reasons:

    1. My company standardized on it for the simple reason that we are primarily
    a Unix shop. Until .NET I was basically the only full time windows guy in
    the company. When .NET came out, we decided to create a Windows interface
    for our Unix software - but since most of the guys are C/C++/Java guys it
    made sense for use to use a C-style language.

    2. I like it better. Simply because I prefer C-style syntax.

    I'm not sure what other peoples reasons are.

    Tom Shelton




  7. #22
    Patrick Troughton Guest

    Re: Borland and me: We both want less code and more pictures!


    Well, there you go!

    /Pat

    "Keith" <keith@nospam_softwire.com> wrote:
    >Well, I'm probably not the one you were looking for, but I guess I'll
    >de-lurk for a moment. VS.Net was easier for us to integrate into for a
    >couple of reasons. 1) MS provided support for integration as a product
    >feature, rather than as and add-on to an existing product. This allowed

    the
    >integration to be deeper, so we can become more a part of VS than just an
    >addition. (2) When you went under the hood, you can see a bit of the history
    >of VB6. It did not present a consistent interface, and things were not
    >always as they appeared. For example, the controls in VB6 appeared to be

    COM
    >objects, but they actually have a wrapper for extended properties. These
    >objects don't really act quite like they should, and don't expose interfaces
    >that are supposed to be there. I believe this just reflects that COM was
    >added into VB afterwards, and they kept their control code rather than
    >totally rewriting it. There were a number of areas where VB6 caused us to
    >scratch our heads, and some, like control arrays, that we just couldn't
    >support.
    >
    >In general, .Net has been a much more stable, efficient environment for

    us,
    >and I would suspect that MSs experience with VB addins and designers helped
    >in their making it so. BTW, the subject of this thread was not lost on me.
    >Any guesses as to how similar Delphi and VS are in terms of integration,
    >given some of the common personnel? Just wondering Back to lurking.
    >Keith



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

    Re: Borland and me: We both want less code and more pictures!

    In article <3d6d6f7c@10.1.10.29>,
    "Tom Shelton" <tom@mtogden.com> writes:

    .... a typical response from someone faced with the fact that he
    cannot factually refute statements which threaten a cherished
    belief. But no matter how hard you try to hide that fact from the
    others here, you cannot hide the facts from yourself: you are unable
    to name even one "unsafe" aspect of modular programming which does
    not apply equally to the equivalent OOP. Not one. Nor can you hide
    from yourself the emotional reaction that inability raises in you.

    The facts remain. Best practices modular programs are at least as
    safe as best practices OOP. Well written "standard practice" modular
    programs are at least as safe as well written "standard practice" OOP.
    Poorly written OOP programs are significantly less safe than poorly
    written modular programs - there are more ways they can be unsafe. And
    badly written OOP programs can be far more disastrous than badly
    written modular programs, with misuse of classes, overloading, etc.

    Your emotional reaction to those facts should tell you something.

    > Bill we obviously disagree on the worth of OOP.


    More on the dangers of OOP. You are willfully blind to their extent.
    and I am not. And that affects evaluation of the risk/benefit ratio.

    > But who cares,


    Apparently, you do. You have invested a lot of emotion in your
    attempts to evangelize OOP, and you react emotionally every time those
    attempts faulter in the face of contradictory facts.

    If you simply stuck to your "I like it better" argument, no one could
    really refute you. But when you try making more objective claims,
    such as increased safety, you are going to be challenged. And it is
    going to take more than personal insults and mindless repetition of
    buzzwords to answer those challenges.

    > you don't have to use it in VB.NET anymore then you have to in
    > VB.CLASSIC.


    Wrong. Data structures - especially UDTs - are no longer "pure data".
    They have been transformed into "objects", with the corresponding
    drawbacks.

    But the more interesting aspect of your statement is your shift from
    your claims about "OOP" to other (also untrue) claims about VB.NET.
    You have used such attempted shifts before, when you have faced your
    inability to factually advance your argument.

    > You can continue to create modules and use them just like in
    > VB.CLASSIC.


    Wrong. Since I cannot create data structures and use them "just like
    in VB.CLASSIC" I cannot create and use modules in the same way.



    --

    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. #24
    Robert Lantry Guest

    Re: Borland and me: We both want less code and more pictures!

    It's so fun watching you split hairs, further reducing any point you had
    drivel. The greatest part of all is, given enough time, you argue yourself
    right out of your own position.

    You're brilliant Bill.


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
    news:3D73B68D.92681647@netzero.net...
    > In article <3d6d6f7c@10.1.10.29>,
    > "Tom Shelton" <tom@mtogden.com> writes:
    >





  10. #25
    Tom Shelton Guest

    Re: Borland and me: We both want less code and more pictures!


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote in message
    news:3D73B68D.92681647@netzero.net...
    > In article <3d6d6f7c@10.1.10.29>,
    > "Tom Shelton" <tom@mtogden.com> writes:
    >
    > ... a typical response from someone faced with the fact that he
    > cannot factually refute statements which threaten a cherished
    > belief. But no matter how hard you try to hide that fact from the
    > others here, you cannot hide the facts from yourself: you are unable
    > to name even one "unsafe" aspect of modular programming which does
    > not apply equally to the equivalent OOP. Not one. Nor can you hide
    > from yourself the emotional reaction that inability raises in you.


    No, it is the typical response from someone who is just fed up with your
    double speak and hair splitting, as well as your insulting condecending
    tone - Oh, great Bill, gift of the gods to all mortal programmers! If you
    want to have a more in depth disscussion on this then fine. I have an open
    mind. I personally like the OOP approach. Maybe because of my experience
    with procedural languages such as C. In C the typical libary of functions
    uses a struct and a bunch of functions that work on that struct. The struct
    members are completly exposed to the client programmer - even if you don't
    want them to touch them. The only way you have to enforce this is through
    documentation - in C++ and other OO languages, you simply turn the object
    into a class. Then you have total control over what members the client has
    access to, as well as the freedom to change the underlying implementaion
    without breaking client code. Not so with a struct. In reality a class is
    not much more than a struct with access control and methods bound to it.

    Does OOP have problems, sure. I tend to agree with you when it comes to
    implementaion inheritance (to distinguish from interface inheritance, which
    I think is fine). And I think this is generally true in the OO comunity.
    Implementation inheritance can lead to some nasty problems if not used
    correctly. In general, plain old delegation is the way to reuse an
    implementation. That said, implentation inheritance is a valid tool and is
    nice to have when used effectively.

    Your other comments about VB.NET just show your ignorance of the product.
    You can create and use a UDT in the same way as in VB.CLASSIC (except for
    fixed size arrays and strings) and you access them in the same way. If your
    worried about inheritance - don't. UDT's (structures) in .NET do not
    participate in inheritance. Again, a VB.NET programmer does not need to
    know very much more, if any more, about OOP then he did in VB.CLASSIC.
    VB.NET is a mixed mode language - sort of like C++. You often use objects,
    but you don't have to implement your own. How they are handled on the IL
    level is, IMHO, irrelavent.

    Tom Shelton



  11. #26
    Jason Guest

    Re: Borland and me: We both want less code and more pictures!


    I must say that I personally find OOP to be a great improvement over modular,
    procedural programming. When you get right down to it, passing around structures
    to functions and using odd naming conventions usually turns out to be a hard
    way of implementing OO, with the caveat that it is easy to break encapsulation
    and difficult to implement inheritance (which is useful if used correctly
    - and carefully).

    I have seen bad OO designs. Yes. They usually stem from way too much planning
    and too little doing, from academics who understand UML and not their customers'
    needs. I have also seen good OO designs. Good OO designs can hide millions
    of lines of complex code in ways that make them simple to use for developers.
    Take a look at the "java.util" package in Java, or the System.IO packages
    in .NET. They tackle some very difficult problems, but they aren't hard
    to understand or use.

    And, by the way, you can use these kinds of libraries using "best practices,"
    or you can use "quick-and-dirty" programming, and the code ends up looking
    much the same. No need for special naming conventions that make the code
    nearly unreadable to the uninitiated, you know?

    Just like anything else, you can do bad OO and you can do good OO. For really
    big programs, I find that it is easier to do good OO than good modular procedural
    programming. Just my 2 cents.

  12. #27
    Kunle Odutola Guest

    Re: Borland and me: We both want less code and more pictures!

    W.E. (Bill) Goodrich, PhD wrote:
    > In article <3d6d6f7c@10.1.10.29>,
    > "Tom Shelton" <tom@mtogden.com> writes:
    >
    > ... a typical response from someone faced with the fact that he
    > cannot factually refute statements which threaten a cherished
    > belief. But no matter how hard you try to hide that fact from the
    > others here, you cannot hide the facts from yourself: you are unable
    > to name even one "unsafe" aspect of modular programming which does
    > not apply equally to the equivalent OOP. Not one. Nor can you hide
    > from yourself the emotional reaction that inability raises in you.


    1. To implement an ADT that is similar but not identical to an exisitng ADT,
    you *have* to copy and paste a lot of code.

    OOP: With OOP you have the option of white-box inheritance
    (implementation inheritance) or black-box inheritance
    (delegation/composition or interface inheritance).

    2. Given an ADT, there is no easy way to find all operations that apply to
    it (all it's creation/destruction/accessor/mutator/service functions).
    Typically, a text search of the source code base is required.

    OOP: With OOP, all the operations are part of the definition of it's
    expanded ADT concept - the object/class.

    3. Developing and using containers (array, lists, stacks, trees, graphs etc)
    that can store multiple datatypes requires "code hackery".

    OOP: It's trivial. Implement a container that can store anything and use
    the appropriate type of inheritance to create sub-classes that can store
    whatever subset takes your fancy. It's so trivial most OO systems include
    them for free.

    3. Because data structures are not bound to the operations that are valid
    for them and, there is no acces control, it is easy (and a common occurence
    in reality) to break the "contract" for the correct use of all and any ADT
    (well-designed or not).

    OOP: Try doing that to a well-defined object!

    There are more but this will do for the moment.


    > The facts remain. Best practices modular programs are at least as
    > safe as best practices OOP.


    You assume OOP does not have any new tools to deal with problems with MP and
    ypu are wrong in that respect.

    > Well written "standard practice" modular
    > programs are at least as safe as well written "standard practice" OOP.


    I have already shown that to be false above.

    >> you don't have to use it in VB.NET anymore then you have to in
    >> VB.CLASSIC.

    >
    > Wrong. Data structures - especially UDTs - are no longer "pure data".
    > They have been transformed into "objects", with the corresponding
    > drawbacks.


    No. Structs in VB.NET are "value types". They can be "boxed" into "reference
    types" (aka.objects) and treated as such but, they aren't objects. If we
    were discussing Smalltalk, you would be right but, I do not recall *any*
    drawbacks to Smalltalk because of it's everything is an object purity. Can
    you present any?

    >> You can continue to create modules and use them just like in
    >> VB.CLASSIC.

    >
    > Wrong. Since I cannot create data structures and use them "just like
    > in VB.CLASSIC" I cannot create and use modules in the same way.


    Yes you can. If you used VB.NET that is....

    Kunle



  13. #28
    W.E. (Bill) Goodrich, PhD Guest

    Re: Borland and me: We both want less code and more pictures!

    In article <3d73e0e4@10.1.10.29>,
    "Tom Shelton" <tom@mtogden.com> writes:

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


    > > In article <3d6d6f7c@10.1.10.29>,
    > > "Tom Shelton" <tom@mtogden.com> writes:


    > > ... a typical response from someone faced with the fact that he
    > > cannot factually refute statements which threaten a cherished
    > > belief. But no matter how hard you try to hide that fact from the
    > > others here, you cannot hide the facts from yourself: you are unable
    > > to name even one "unsafe" aspect of modular programming which does
    > > not apply equally to the equivalent OOP. Not one. Nor can you hide
    > > from yourself the emotional reaction that inability raises in you.


    > No, it is the typical response from someone who is just fed up
    > with your double speak and hair splitting, as well as your
    > insulting condecending tone - Oh, great Bill, gift of the gods to
    > all mortal programmers!


    There you go again - foaming at the keyboard because someone had the
    temerity to expose the flaws in your ex cathedra pronouncements about
    OOP. Which part was the "hair splitting" - the part where I indicated
    that your "safety" pronouncement was 100% wrong, or the part where I
    noted the difference between debating modalities (OOP, MP, etc.) and
    debating aspects of specific programming languages (e.g. VB.NET)? And
    how is my "tone" any more insulting than your recent characterizations?

    > If you want to have a more in depth disscussion on this then fine.


    That would make a pleasant change.

    > I have an open mind.


    You have not demonstrated that so far.

    > I personally like the OOP approach.


    That is fine, as far as it goes. The problem comes in when you try to
    translate that personal preference into arguments concerning its
    objective value as a general purpose approach.

    > Maybe because of my experience with procedural languages such as C.


    And once again, you go from discussion of a modality (OOP) to
    discussion of a language. And in the process, entirely avoid the issue
    of OOP vs MP.

    > In C the typical libary of functions uses a struct and a bunch of
    > functions that work on that struct.


    Often more than one struct. And often, it made more sense to make the
    functions operate on a passed struct.

    > The struct members are completly exposed to the client programmer -
    > even if you don't want them to touch them.


    Nonsense. Any competent C programmer knew to use blocking to limit
    the scope of the variables. If you chose to ignore that mechanism,
    you were doing the same thing as declaring your class members
    "public" in your sainted VB.NET. And again, the language specifics
    have nothing to do with the modality issues. Modular programming
    as a modality calls for such scope limitation on variables.

    > The only way you have to enforce this is through documentation


    Nonsense. You could (and we did) enforce it by use of blocking. You
    could have solved your entire problem with a simple pair of curly
    brackets.

    > - in C++ and other OO languages, you simply turn the object into a
    > class.


    And in C, you just block the variable to the appropriate scope.

    > Then you have total control over what members the client has access
    > to,


    Producing LESS, rather than more, safety than the all or nothing
    protection of C blocking. Not to mention the additional complexity
    and overhead, and the potential for significant cascade problems
    from changes to those permissions.

    > as well as the freedom to change the underlying implementaion
    > without breaking client code.


    In theory, perhaps. In practice, it provides a mechanism for MASSIVE
    disruption of the client code if handled the least bit wrong. As
    opposed to the MP model of the IPO Black Box, which DOES allow the
    freedom to change the underlying implementation without breaking
    client code.

    Let's take the classic instance of changing a data member to a
    put/get pair of methods. And then have the get method do something
    more than just return the value of the variable. Trouble, right here
    in River City. Various kinds of conditional execution statements,
    procedure (/sub/function/method/etc.) calls, and other elements which
    would not even be expected to access the value under the circumstances
    at hand will invoke the method anyway - with undesirable (and
    difficult to trace) results.

    > Not so with a struct.


    With a struct, the issue of "changing the underlying implementation"
    is largely limited to retyping elements, rearranging fields, and
    adding/removing them. And - when shifting from platform to platform -
    changing the size of individual elements (e.g. 16/32 bit integers). All
    apply equally to the OOP classes. But as noted above, the classes
    allow far more dangerous issues to imperil the client code.

    > In reality a class is not much more than a struct with access
    > control and methods bound to it.


    Not "much more" - just enough more to seriously reduce the safety of
    classes relative to that of equivalent combinations of structs and
    functions. Especially if those structs and functions were implemented
    in MP fashion.

    > Does OOP have problems, sure. I tend to agree with you when it
    > comes to implementaion inheritance (to distinguish from interface
    > inheritance, which I think is fine). And I think this is generally
    > true in the OO comunity.


    As you say, you "think" that is so. In practice, there are two major
    parts of the "OO community" - those thoughtfully and strictly using
    the OOD/OOP modality, and those doing time-pressured, any way
    programming using OO tools. The latter group - the equivalent of the
    non-OO ones you keep trying to compare OOP to - is the breeding
    ground for the kinds of problems I have been citing. And by and
    large, they outnumber the "thoughtful" group by a wide margin in the
    professional programming community. More so, when you remove
    "independent contractor/consultants" from the mix.

    > Implementation inheritance can lead to some nasty problems if not
    > used correctly.


    And that is inherent to OOP. Thus it is one element of the "OOP is
    less safe than MP" argument.

    > In general, plain old delegation is the way to reuse an
    > implementation.


    And reuse of properly modular code is even simpler. And safer.

    > That said, implentation inheritance is a valid tool and is
    > nice to have when used effectively.


    And horrific when later changed in an inappropriate way - a maintenance
    issue some of us have had to deal with.

    > Your other comments about VB.NET just show your ignorance of the
    > product.


    No, just your own blindness with regard to it.

    > You can create and use a UDT in the same way as in VB.CLASSIC


    Here you make a claim...

    > (except for fixed size arrays and strings)


    ....and here you refute it all by yourself. Interesting that when I
    point out that there are such differences, it is "ignorance of the
    product" but somehow YOUR statements to the same effect are not. And
    those are not exactly trivial exceptions. However, there is more.

    > and you access them in the same way.


    Not quite. In VB6, structures occupy contiguous blocks of memory,
    allowing certain useful (but politically incorrect) speedups. Such
    techniques cannot be used with VB.NET.

    > If your worried about inheritance - don't.


    I'm not. There are enough other problems to relegate that one to a low
    position on the list.

    > UDT's (structures) in .NET do not participate in inheritance.


    Unless, of course, you are trying to define a UDT which contains
    another UDT. The resulting mess is quite interesting.

    > Again, a VB.NET programmer does not need to know very much more,
    > if any more, about OOP then he did in VB.CLASSIC.


    There you go again with the weasel words. What is "not much" to you
    may be VERY much to the sorts of non-Programmers (subject area experts
    with little or no CS background) who have done so well with VB.Classic.
    And then there is the little matter of learning - and understanding -
    all those necessary details of the CLR (most, if not all, of which are
    solely documented in OOP terms).

    > VB.NET is a mixed mode language - sort of like C++.


    Far less so than VB6.

    > You often use objects, but you don't have to implement your own.


    As long as you don't use any UDTs or equivalents of the VB.Classic
    Variant data type.

    > How they are handled on the IL level is, IMHO, irrelavent.


    For the types of applications you limit yourself to, perhaps. For the
    types of applications I have spent much of my career on, it is VERY
    relevant - as shown in the "UDT vs class" discussion above.

    --

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

  14. #29
    Kunle Odutola Guest

    Re: Borland and me: We both want less code and more pictures!

    W.E. (Bill) Goodrich, PhD wrote:

    >> The struct members are completly exposed to the client programmer -
    >> even if you don't want them to touch them.

    >
    > Nonsense. Any competent C programmer knew to use blocking to limit
    > the scope of the variables.


    This isn't about variable visibility and scoping. The definitions of those
    structs are available to all clients -- <quote>The struct *members*
    are...</quote>.

    With any rebuff, pls please post an example of using C's mechanism for
    dealing with this issue.

    Kunle



  15. #30
    W.E. (Bill) Goodrich, PhD Guest

    Re: Borland and me: We both want less code and more pictures!

    In article <3d76898c@10.1.10.29>,
    "Kunle Odutola" <kunle.odutola@<REMOVETHIS>okocha.freeserve.co.uk>
    writes:

    > W.E. (Bill) Goodrich, PhD wrote:


    > >> The struct members are completly exposed to the client programmer -
    > >> even if you don't want them to touch them.


    > > Nonsense. Any competent C programmer knew to use blocking to limit
    > > the scope of the variables.


    > This isn't about variable visibility and scoping. The definitions
    > of those structs are available to all clients -- <quote>The struct
    > *members* are...</quote>.


    Try not to make your trolling quite so obvious. Or is it your
    illiteracy? Even the limited snippet you quoted established that the
    issue was whether the client can "touch" them. If the struct is not
    available to the client, the individual members are unavailable as
    well.

    > With any rebuff, pls please post an example of using C's mechanism
    > for dealing with this issue.


    Do not distribute the source code. The precompiled .obj (or system
    local equivalent) file does not expose those definitions.

    --

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

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