Re: Writer's Uninformed Statements


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 3 123 LastLast
Results 1 to 15 of 39

Thread: Re: Writer's Uninformed Statements

Hybrid View

  1. #1
    Rich Guest

    Re: Writer's Uninformed Statements


    John,

    The author makes some uninformed statements:

    "Procedural languages such as COBOL and VB are being rewritten for .NET to
    be object-oriented. Teaching developers object-oriented programming is much
    more of a stepping stone than understanding syntactical rules.

    Languages such as COBOL or VB were never intended to be object-oriented."

    Calling VB procedural is totally idiotic. VB was not "intended to be object-oriented?"
    I guess he FORGOT VB is object based. To gain some credibility, he could
    have pointed this out. This is yet another uniformed individual. I hope they
    did not pay much for his "professional" opinion. :-)

    Rich

    --------------------------------------------------------------------------


    "John Butler" <jrbutler@nospambtclick.com> wrote:
    >Hi
    >
    >Came across this article today:
    >http://www.theserverside.com/resourc...T/article.html
    >
    >It's written by a company, FOR Sun , but is fairly neutral (I thought),
    >although I don't think the authors live up to the promises they make at

    the
    >beginning...
    >
    >If you're looking for a comparison, listing of pro's and con's etc between
    >the J2EE platform and DotNet, then it is certainly worth a read.
    >
    >I'd be interested to hear what the various luminaries that hang out here
    >think of it....
    >
    >Rgds
    >John Butler
    >
    >
    >



  2. #2
    Ted Guest

    Re: Writer's Uninformed Statements


    Forgive my VB ignorance once again, but how is VB object based? I would think
    that component based and event driven would more sum up VB. Is that wrong?

    "Rich" <nospam@nospamy.com> wrote:
    >
    >John,
    >
    >The author makes some uninformed statements:
    >
    >"Procedural languages such as COBOL and VB are being rewritten for .NET

    to
    >be object-oriented. Teaching developers object-oriented programming is much
    >more of a stepping stone than understanding syntactical rules.
    >
    >Languages such as COBOL or VB were never intended to be object-oriented."
    >
    >Calling VB procedural is totally idiotic. VB was not "intended to be object-oriented?"
    >I guess he FORGOT VB is object based. To gain some credibility, he could
    >have pointed this out. This is yet another uniformed individual. I hope

    they
    >did not pay much for his "professional" opinion. :-)
    >
    >Rich
    >
    >--------------------------------------------------------------------------
    >
    >
    >"John Butler" <jrbutler@nospambtclick.com> wrote:
    >>Hi
    >>
    >>Came across this article today:
    >>http://www.theserverside.com/resourc...T/article.html
    >>
    >>It's written by a company, FOR Sun , but is fairly neutral (I thought),
    >>although I don't think the authors live up to the promises they make at

    >the
    >>beginning...
    >>
    >>If you're looking for a comparison, listing of pro's and con's etc between
    >>the J2EE platform and DotNet, then it is certainly worth a read.
    >>
    >>I'd be interested to hear what the various luminaries that hang out here
    >>think of it....
    >>
    >>Rgds
    >>John Butler
    >>
    >>
    >>

    >



  3. #3
    Rich Guest

    Re: Writer's Uninformed Statements


    Ted,

    I think you are getting some semantics confused. By stating a development
    tool is object oriented or object based, Iím stating the features the toolís
    language provides.

    The issue of a tool being component based is really a general term originally
    used to describe the "ancient" VB development. It is probably still used
    by some who have not kept up with VB's metamorphosis over the last seven
    years.

    In the old days, VB applications were hacked together with controls (VB intrinsic
    and third party) and "glued" together with VB code to get it to "work." These
    were generally small or medium one tier or two tiered applications. Much
    of the code was thrown into the events on the form. Needless to say, this
    design was flawed for many reasons.

    Unfortunately, many people are still either unaware or ignore the fact VB
    has developed into a very strong development tool for business applications.
    It has been, for the last three versions, object based. There are actually
    some companies out there successfully building solid object based applications.


    By stating VB is object based, I am stating that VB language supports most
    of the requirements to be object oriented. The classes (class modules) created
    within VB meet all of the "traditional" criteria except for implementation
    inheritance. Hence, it is called object based instead of object oriented.

    Now, utilizing components is something different. This is done in Visual
    C++, Delphi, Java, Visual Basic and many other tools. Very generally speaking,
    they can be in the form of a DLL, ActiveX control, static library, VCL or
    JavaBean. It is simply a way to utilize third party code or reuse internally
    developed code. This has nothing to do with the development tool's language
    features or capabilities.

    Rich


    -----------------------------------------------------------------------

    "Ted" <TTarney@hotmail.com> wrote:
    >
    >Forgive my VB ignorance once again, but how is VB object based? I would

    think
    >that component based and event driven would more sum up VB. Is that wrong?



  4. #4
    Mike Mitchell Guest

    Re: Writer's Uninformed Statements

    On 1 Sep 2001 09:47:28 -0700, "Rich" <nomail@nomail.com> wrote:

    >In the old days, VB applications were hacked together with controls (VB intrinsic
    >and third party) and "glued" together with VB code to get it to "work." These
    >were generally small or medium one tier or two tiered applications. Much
    >of the code was thrown into the events on the form. Needless to say, this
    >design was flawed for many reasons.


    "Flawed"? I think you need to explain your complaints about it before
    we start discussing "flaws", ecxept maybe the ones in your argument.

    First, what does "in the old days" mean? Like, yesterday was "the old
    days"? Because I was using classic VB yesterday, and I'll probably use
    it today as well. Hardly "the old days" when over three million
    developers are using it, and many of them right this minute. This
    situation will continue (shock, horror!) for years, as most classic VB
    developers will not find even a minute of fun in the new VB.NET.

    Second, "hacked together" implies you don't like the concept of RAD.
    What is the key concept to take home from RAD? That's right, it's "R",
    isn't it? Rapid. Productive. Fast. Profits! Pretty obvious to most
    people - see "Rapid Transportation Systems", for example, or "Rapid
    Response Teams". You wouldn't want to pay taxes for a "Lethargic
    Response Team", would you? Classic VB is one of the few truly RAD
    environments available. There is, I would argue, nothing quicker than
    firing up VB1,2,3,4,5 or 6, selecting a control from the toolbox,
    placing it on the form, and adding some event handling code. (Well, I
    suppose shooting oneself in the foot is pretty quick, too.)

    Now, I agree with your choice of words in "glue", although I suspect
    you are using it in a pejorative sense, as you more obviously are when
    we come to the part where we "get it to 'work'". You're obviously
    assuming that it's happenstance that such an abortion as "old days" VB
    could ever work, so the devs are continually trying their damndest to
    make this happy event, er, happen.

    "Much of the code was thrown into the events", you say, but what else
    would the events have thrown at them? Apples? Dead rabbits? I would
    rather you wrote that code was written in the event handlers, and
    leave the throwing to the next ball game, where it makes more sense.

    Finally, let me remind you, lest you forget the importance of VB's
    role in bringing computing to the masses, that classic Visual Basic is
    the lingua franca of modern computing. With VB, VBA, and VBScript it
    is ubiquitous, powerful, accessible, and simple to understand and use
    by vast millions of workers as they pursue their RAD dreams and
    actually produce apps that work and do it very successfully without
    OOP, UML, XML, and all the other bloated ballyhoo buzz words that are
    sadly rife in computing nowadays.

    Strange, isn't it, as you reflect upon the huge level of support there
    is from developers and corporates for such a "flawed" design as
    classic Visual Basic?

    MM


  5. #5
    Gregor R. Peisker Guest

    Re: Writer's Uninformed Statements

    Hi Mike,

    > Well, I suppose shooting oneself in the foot is pretty quick, too.


    Exactly.

    Regards,
    Gregor



  6. #6
    Ted Guest

    Re: Writer's Uninformed Statements


    Mike,

    I thought you might enjoy this article:
    http://www.computerworld.com/cwi/sto...O63340,00.html

    I would care to guess that your title is "NOT" Software Engineer? I would
    also guess that due to your use of the "bloated ballyhoo buzz words" like
    OOP and UML( and possibly patterns, but since you don't do OO and you write
    VB you probably don't know about patterns ) that in your opinion, these "essential"
    tools of a true SE are not needed? Hmmm. Well I guess RAD can take care
    of all of that? I mean "R" is rapid. So that time honored tradition of
    software engineering can go by the wayside. 3 months in a VB continuing
    education class at some community college can make you a software engineer
    these days anyway.

    Well as you have said, VB did bring computing to the masses, and fortunately
    for an SE like myself, a good majority of those in the masses( including
    you ) will continue to be code monkeys and keep my salary continually rising.

    Oh and by the way, do you really think that 3 million number is all "workers"?

    >Finally, let me remind you, lest you forget the importance of VB's
    >role in bringing computing to the masses, that classic Visual Basic is
    >the lingua franca of modern computing. With VB, VBA, and VBScript it
    >is ubiquitous, powerful, accessible, and simple to understand and use
    >by vast millions of workers as they pursue their RAD dreams and
    >actually produce apps that work and do it very successfully without
    >OOP, UML, XML, and all the other bloated ballyhoo buzz words that are
    >sadly rife in computing nowadays.
    >
    >Strange, isn't it, as you reflect upon the huge level of support there
    >is from developers and corporates for such a "flawed" design as
    >classic Visual Basic?



  7. #7
    Rich Guest

    Re: Writer's Uninformed Statements


    Mike,

    Your rant was totally off. My statement was simply this. Once upon a time
    VB (1-3) was NOT object based. Many people hacked together monolithic applications
    with much of the code in events. These applications were not easily extended
    or maintained. Anyone, including Rocky Lhotka, Deborah Kurata or myself who
    has paid attention will admit object based application development is far
    superior to the "throw the code in events" garbage. Please, point out the
    flaw.

    I suppose you thought I was ripping on VB 6. Again, you were WRONG. I was
    pointing out how some "programmers" hacked things together in the past. I'm
    assuming all professional programmers now know and use the object based features
    of VB6. :-)

    I think you missed the boat on RAD. Maybe, for your small applications, hacking
    is the way. That is your choice. For me, I write medium to large applications,
    which contain code, which is scalable, maintainable and reusable. Not one
    offs.

    As for code in events, that is a hack. Tons of code in the events. This is
    the way I would expect a neophyte to write applications. There is no design.
    Just hack it together. You know what I meant. There should be minimal code
    in the events calling objects properties or methods.

    As for VB's role, I have been using VB for over eight years each and every
    day for eight hours a day or more. The "Ruby VB" was an excellent start.
    It was never intended to last as long as it did. It had a great run. Now,
    it is off to VB.NET. This is the future. You can like it or not.

    Rich

    ---------------------------------------------------------------------------

    kylix_is@hotmail.com (Mike Mitchell) wrote:
    >On 1 Sep 2001 09:47:28 -0700, "Rich" <nomail@nomail.com> wrote:
    >
    >>In the old days, VB applications were hacked together with controls (VB

    intrinsic
    >>and third party) and "glued" together with VB code to get it to "work."

    These
    >>were generally small or medium one tier or two tiered applications. Much
    >>of the code was thrown into the events on the form. Needless to say, this
    >>design was flawed for many reasons.

    >
    >"Flawed"? I think you need to explain your complaints about it before
    >we start discussing "flaws", ecxept maybe the ones in your argument.
    >
    >First, what does "in the old days" mean? Like, yesterday was "the old
    >days"? Because I was using classic VB yesterday, and I'll probably use
    >it today as well. Hardly "the old days" when over three million
    >developers are using it, and many of them right this minute. This
    >situation will continue (shock, horror!) for years, as most classic VB
    >developers will not find even a minute of fun in the new VB.NET.
    >
    >Second, "hacked together" implies you don't like the concept of RAD.
    >What is the key concept to take home from RAD? That's right, it's "R",
    >isn't it? Rapid. Productive. Fast. Profits! Pretty obvious to most
    >people - see "Rapid Transportation Systems", for example, or "Rapid
    >Response Teams". You wouldn't want to pay taxes for a "Lethargic
    >Response Team", would you? Classic VB is one of the few truly RAD
    >environments available. There is, I would argue, nothing quicker than
    >firing up VB1,2,3,4,5 or 6, selecting a control from the toolbox,
    >placing it on the form, and adding some event handling code. (Well, I
    >suppose shooting oneself in the foot is pretty quick, too.)
    >
    >Now, I agree with your choice of words in "glue", although I suspect
    >you are using it in a pejorative sense, as you more obviously are when
    >we come to the part where we "get it to 'work'". You're obviously
    >assuming that it's happenstance that such an abortion as "old days" VB
    >could ever work, so the devs are continually trying their damndest to
    >make this happy event, er, happen.
    >
    >"Much of the code was thrown into the events", you say, but what else
    >would the events have thrown at them? Apples? Dead rabbits? I would
    >rather you wrote that code was written in the event handlers, and
    >leave the throwing to the next ball game, where it makes more sense.
    >
    >Finally, let me remind you, lest you forget the importance of VB's
    >role in bringing computing to the masses, that classic Visual Basic is
    >the lingua franca of modern computing. With VB, VBA, and VBScript it
    >is ubiquitous, powerful, accessible, and simple to understand and use
    >by vast millions of workers as they pursue their RAD dreams and
    >actually produce apps that work and do it very successfully without
    >OOP, UML, XML, and all the other bloated ballyhoo buzz words that are
    >sadly rife in computing nowadays.
    >
    >Strange, isn't it, as you reflect upon the huge level of support there
    >is from developers and corporates for such a "flawed" design as
    >classic Visual Basic?
    >
    >MM
    >



  8. #8
    Larry Linson Guest

    Re: Writer's Uninformed Statements


    "Rich" <nomail@nomail.com> wrote:

    > Your rant was totally off. My statement was simply this.
    > Once upon a time VB (1-3) was NOT object based. Many
    > people hacked together monolithic applications with
    > much of the code in events. These applications were not
    > easily extended or maintained.


    From version 1, VB has been "object based". For example, controls were objects
    with properties, and controls and forms had events (of course, maybe in your
    definition, events aren't associated with objects, but they seemed to be
    in the eyes of the developers of all versions of VB). The versions you described
    simply did not support the developer creating his/her own class modules.


    > Anyone, including Rocky
    > Lhotka, Deborah Kurata or myself who has paid attention
    > will admit object based application development is far
    > superior to the "throw the code in events" garbage.


    Deborah Kurata has, as long as I have known of her, been an _advocate_, in
    fact, a strong advocate, of using Objects. Yet, you say "admit", as though
    that admission had been wrung out of her _grudgingly_. Rocky and you, I don't
    know about, but if you say you have "paid attention", I suppose you must
    have, though you don't make it clear to _what_ you paid attention.

    On the other hand, there are a good many who have, in fact, "paid attention"
    but who aren't convinced that creating applications which aren't necessarily
    based on putting just about everything in developer-created class modules
    is bad practice and amounts to "throw code in events garbage". There have
    always been standard modules available (from VB1 on) into which more widely-used,
    even globally-used, procedures and variables can be placed. And, in general,
    even in RAD applications, I've seen those used appropriately.

    It is the events that fire in response to actions of various kinds and where
    some code, perhaps little, perhaps more, must be put in classic VB, even...
    I stress _even_... in applications making extensive use of class modules,
    if the application is to respond to those actions.

    > Please, point out the flaw.


    In only the parts which I have quoted here, there are several. First flaw:
    stating that VB 1-3 were not "object-based". Second flaw: trying to give
    the impression that DK had to be "convinced" that object is better and implying
    that she "admitted" that was the case rather than the actual case which is
    that she has long "advocated" object-orientation. Third flaw: trying to give
    the impression that anyone who has "paid attention" will "admit" that object-oriented
    is always better. Fourth flaw: denigrating the utility of events and implying
    that "throwing code into events" is "garbage".

    It has, of course, been possible to create applications that were "garbage"
    with every version of VB (and assembler, and Fortran, and C of all flavors,
    and Pascal, and ...); whether or not you're a bettin' man, you can safely
    wager your future salary that it will be possible to do so in future versions,
    as well.



  9. #9
    Rich Guest

    Re: Writer's Uninformed Statements


    Larry,

    >First flaw: stating that VB 1-3 were not "object-based".


    You are confusing objects and components(VBXs and ActiveX controls). Components
    are not the same as VB class modules. VB being object based is a semantic
    used to describe the VB language class module capabilities. The VB language
    is not a 100% pure object oriented language. As I said before, it is missing
    implementation inheritance. Hence, the object-oriented purists would not
    consider it object oriented. Many would say it is object based. Since this
    was added in VB 4, one could not say VB 1-3 is object based. "Flaw" refuted.


    >Second flaw: trying to give the impression that DK had to be "convinced"

    that object is better and implying >that she "admitted" that was the case
    rather than the actual case which is>that she has long "advocated" object-orientation.


    I guess you missed my point. I was attempting to be diplomatic. I did not
    want to say, "Here is what the experts say, if you do not believe them your
    are an idiot." "Flaw" refuted.

    Third flaw: trying to give >the impression that anyone who has "paid attention"
    will "admit" that object-oriented
    >is always better.


    When I said, "paid attention" I meant anyone who has kept up with the object-based
    capabilities added in VB. It was hard to miss. :-)

    For an application of any size, it is almost always better. In a rare occasion
    one may want to functionally decompose to increase performance. Sometimes
    this works, sometimes it does not increase performance. Whether or not the
    performance is increased, maintainability is decreased. "Flaw" refuted.


    >Fourth flaw: denigrating the utility of events and implying
    >that "throwing code into events" is "garbage".


    Again, using solid OOD always leads to maintainable, reusable and extensible
    applications. Believe it or not. Enough said. "Flaw" refuted.



    Rich
    ---------------------------------------------------------------------------

    "Larry Linson" <larry.linson@ntpcug.org> wrote:
    >
    >"Rich" <nomail@nomail.com> wrote:
    >
    > > Your rant was totally off. My statement was simply this.
    > > Once upon a time VB (1-3) was NOT object based. Many
    > > people hacked together monolithic applications with
    > > much of the code in events. These applications were not
    > > easily extended or maintained.

    >
    >From version 1, VB has been "object based". For example, controls were objects
    >with properties, and controls and forms had events (of course, maybe in

    your
    >definition, events aren't associated with objects, but they seemed to be
    >in the eyes of the developers of all versions of VB). The versions you described
    >simply did not support the developer creating his/her own class modules.
    >
    >
    > > Anyone, including Rocky
    > > Lhotka, Deborah Kurata or myself who has paid attention
    > > will admit object based application development is far
    > > superior to the "throw the code in events" garbage.

    >
    >Deborah Kurata has, as long as I have known of her, been an _advocate_,

    in
    >fact, a strong advocate, of using Objects. Yet, you say "admit", as though
    >that admission had been wrung out of her _grudgingly_. Rocky and you, I

    don't
    >know about, but if you say you have "paid attention", I suppose you must
    >have, though you don't make it clear to _what_ you paid attention.
    >
    >On the other hand, there are a good many who have, in fact, "paid attention"
    >but who aren't convinced that creating applications which aren't necessarily
    >based on putting just about everything in developer-created class modules
    >is bad practice and amounts to "throw code in events garbage". There have
    >always been standard modules available (from VB1 on) into which more widely-used,
    >even globally-used, procedures and variables can be placed. And, in general,
    >even in RAD applications, I've seen those used appropriately.
    >
    >It is the events that fire in response to actions of various kinds and where
    >some code, perhaps little, perhaps more, must be put in classic VB, even...
    >I stress _even_... in applications making extensive use of class modules,
    >if the application is to respond to those actions.
    >
    > > Please, point out the flaw.

    >
    >In only the parts which I have quoted here, there are several. First flaw:
    >stating that VB 1-3 were not "object-based". Second flaw: trying to give
    >the impression that DK had to be "convinced" that object is better and implying
    >that she "admitted" that was the case rather than the actual case which

    is
    >that she has long "advocated" object-orientation. Third flaw: trying to

    give
    >the impression that anyone who has "paid attention" will "admit" that object-oriented
    >is always better. Fourth flaw: denigrating the utility of events and implying
    >that "throwing code into events" is "garbage".
    >
    >It has, of course, been possible to create applications that were "garbage"
    >with every version of VB (and assembler, and Fortran, and C of all flavors,
    >and Pascal, and ...); whether or not you're a bettin' man, you can safely
    >wager your future salary that it will be possible to do so in future versions,
    >as well.
    >
    >



  10. #10
    Bob O`Bob Guest

    Re: Writer's Uninformed Statements

    Larry Linson wrote:
    > "Rich" <nomail@nomail.com> wrote:
    >
    > > Your rant was totally off. My statement was simply this.
    > > Once upon a time VB (1-3) was NOT object based. Many
    > > people hacked together monolithic applications with
    > > much of the code in events. These applications were not
    > > easily extended or maintained.

    >
    > From version 1, VB has been "object based". For example, controls were objects
    > with properties, and controls and forms had events (of course, maybe in your
    > definition, events aren't associated with objects, but they seemed to be
    > in the eyes of the developers of all versions of VB). The versions you described
    > simply did not support the developer creating his/her own class modules.



    No, it did, sort of ... forms actually were already classes, and could be used as such.

    I once implemented a design (from 'CRC' cards) in VB3 using a significant number of
    form types which were never shown. But they had initialize and destruct events,
    properties of controls could act as properties of the object, and I built a fairly
    robust set of textbox change event handlers to act as methods.

    Performance was (as predicted) miserable.
    But the point of RAD was driven home quite dramatically.


    Bob
    --
    Life makes SO much less sense when you're sane.

  11. #11
    Craig Burkett Guest

    Re: Writer's Uninformed Statements

    > >First flaw: stating that VB 1-3 were not "object-based".
    >
    > You are confusing objects and components(VBXs and ActiveX controls).

    Components
    > are not the same as VB class modules. VB being object based is a semantic
    > used to describe the VB language class module capabilities. The VB

    language
    > is not a 100% pure object oriented language. As I said before, it is

    missing
    > implementation inheritance. Hence, the object-oriented purists would not
    > consider it object oriented. Many would say it is object based. Since this
    > was added in VB 4, one could not say VB 1-3 is object based. "Flaw"

    refuted.
    >

    VB 1-3 were object based. The definition of an object is an instantiated
    class correct? There is nothing in OOP that states how that class is
    supposed to be defined. It is only an abstract concept. And believe it or
    not - at least since VB2 - a form was a way for a VB programmer to
    encapsulate code in an object. This is because you actually could
    instantiate a seperate instance of the form and assign it to a variable.

    Dim objMyForm As Form1

    Set objMyForm = New Form1

    'These wind up being two different instances of the same form
    objMyForm.Show
    Form1.Show

    The only problem at this point is that the developer could not define custom
    methods or properties for the form. I personally overcame this limitation
    by employing windows messaging to pass in or send values to and from other
    form objects (using Spyworks). I would submit that the Form was a crude
    form of a class at this stage of VB's life cycle.

    With each subsequent version of VB (4-6) more object oriented features were
    added. Starting with version 5 polymorphism was introduced to VB. This was
    the feature that made VB completely object oriented, it was just more
    involved to implement. This is accomplished through the concept known as
    "Delegation". Frankly, I do not believe "implementation inheritance" is
    required for a language to achieve the ballyhooed status of being "object
    oriented". I believe the only required elements are "encapsulation" and
    "polymorphism". "Implementation inheritance" (just as "Delegation" is one)
    is just a means for achieving polymorphism. So a good CASE tool
    implementing UML can be used to generate code in any language which supports
    these two concepts. Remember, even the early C++ environments were only
    translators. They would translate the C++ code to C code and then compiled.

    > >Second flaw: trying to give the impression that DK had to be "convinced"

    > that object is better and implying >that she "admitted" that was the case
    > rather than the actual case which is>that she has long "advocated"

    object-orientation.

    Frankly, I knew Deborah Kurata from Compuserve and she did not give me the
    impression of being a well informed Computer Science expert. She didn't
    even know how to implement a linked list using VB3. So basically I just see
    her as an author who takes other ptrogrammers ideas and claim them for her
    own.

    >
    > For an application of any size, it is almost always better. In a rare

    occasion
    > one may want to functionally decompose to increase performance. Sometimes
    > this works, sometimes it does not increase performance. Whether or not the
    > performance is increased, maintainability is decreased. "Flaw" refuted.
    >

    Oh I don't know about that. I think structured programming (as defined by
    Dykstra) was more than sufficient for creating large systems. However it
    did require a great deal of discipline to not take shortcuts to the
    implementation of the system. As a matter of fact I believe OOP is an
    extension of structured and helps to enforce the rules as laid out by
    Dykstra.

    >
    > Again, using solid OOD always leads to maintainable, reusable and

    extensible
    > applications. Believe it or not. Enough said. "Flaw" refuted.
    >

    I can't believe this was even typed. Yes OOD (or OOAD) reduces the
    introduction of errors into the design of a system it does not always lead
    to the goals you expoused. I have seen many failed attempts at OOAD.
    However, as long as we learn from those failures that's ok.

    --
    JMHO,
    Craig Burkett MSCS
    "A VB Developer since its coming out party"
    "An OO VB Developer since VB4"

    "Rich" <nomail@nomail.com> wrote in message news:3b93001d$1@news.devx.com...
    >
    > Larry,
    >
    > >First flaw: stating that VB 1-3 were not "object-based".

    >
    > You are confusing objects and components(VBXs and ActiveX controls).

    Components
    > are not the same as VB class modules. VB being object based is a semantic
    > used to describe the VB language class module capabilities. The VB

    language
    > is not a 100% pure object oriented language. As I said before, it is

    missing
    > implementation inheritance. Hence, the object-oriented purists would not
    > consider it object oriented. Many would say it is object based. Since this
    > was added in VB 4, one could not say VB 1-3 is object based. "Flaw"

    refuted.
    >
    >
    > >Second flaw: trying to give the impression that DK had to be "convinced"

    > that object is better and implying >that she "admitted" that was the case
    > rather than the actual case which is>that she has long "advocated"

    object-orientation.
    >
    >
    > I guess you missed my point. I was attempting to be diplomatic. I did not
    > want to say, "Here is what the experts say, if you do not believe them

    your
    > are an idiot." "Flaw" refuted.
    >
    > Third flaw: trying to give >the impression that anyone who has "paid

    attention"
    > will "admit" that object-oriented
    > >is always better.

    >
    > When I said, "paid attention" I meant anyone who has kept up with the

    object-based
    > capabilities added in VB. It was hard to miss. :-)
    >
    > For an application of any size, it is almost always better. In a rare

    occasion
    > one may want to functionally decompose to increase performance. Sometimes
    > this works, sometimes it does not increase performance. Whether or not the
    > performance is increased, maintainability is decreased. "Flaw" refuted.
    >
    >
    > >Fourth flaw: denigrating the utility of events and implying
    > >that "throwing code into events" is "garbage".

    >
    > Again, using solid OOD always leads to maintainable, reusable and

    extensible
    > applications. Believe it or not. Enough said. "Flaw" refuted.
    >
    >
    >
    > Rich
    > --------------------------------------------------------------------------

    -




  12. #12
    Mike Mitchell Guest

    Re: Writer's Uninformed Statements

    On 2 Sep 2001 17:08:31 -0700, "Rich" <nomail@nomail.com> wrote:

    >Your rant was totally off. My statement was simply this. Once upon a time
    >VB (1-3) was NOT object based.


    Please explain how firing up VB6 and placing a control on a form with
    some code "thrown" into the events is any different from doing exactly
    the same thing in VB1. That's right, it isn't in anyway different.
    It's the SAME. That is, there is NOTHING different fundamentally
    between VB1 and VB6. I and 2,999,999 other VB programmers got hooked
    on VB because it allowed us to create Windows programs without the
    huge learning curve and pain of C. That simple truth has held good for
    ten years. No amount of bells and whistles in VB6 will change it. VB
    *is* the shortest route there is to a Windows app. What's more,
    corporates all over the world love VB. They see it as their salvation
    for implementing changes in the business quickly and reliably. Instead
    of a three-month turnaround in other language disciplines they are
    used to a one-day or one-week turnaround in VB. I know the C coders
    don't like it; they're miffed, understandably, that VB should enjoy
    such a lot of icing on the cake, but it's their choice if they don't
    want to be more productive by dumbing down to a "toy" language.

    VB.NET on the other hand is so full of bells and whistles you can
    barely see the player any more. The thing needs a framework many times
    larger than any of the VB1/2/3/4/5/6 packages did. You cannot just
    fire up VB.NET, create an app, then give it to someone else on the
    offchance they may have the framework. This, however, is what you CAN
    do very easily with VB. It's a given that your "someone else" will
    have a version of Windows that will run your app, and the most they'll
    need, if they haven't already got it, is the VB runtime, a measly
    megabyte or so.

    You can witter on about "objects", and "object-based" till the cows
    come home, but millions of VB users couldn't care less. They see VB,
    as I do, as a kind of graphics package in which you "paint" your app
    on a "canvas", and then "animate" it by adding event handling code.
    The fact that I do not need to know about trigonometry, geometry,
    algebra and other arcane stuff to produce a graphics creation is just
    as valid in my use of VB.

    But in VB.NET the underbelly of the language is now exposed. No longer
    is it sufficient for a programmer just to use it. They have to
    understand how the intestines fit in the underbelly. We are now
    expected to be our own butchers. VB.Halal, anybody?

    > Many people hacked together monolithic applications
    >with much of the code in events. These applications were not easily extended
    >or maintained. Anyone, including Rocky Lhotka, Deborah Kurata or myself who
    >has paid attention will admit object based application development is far
    >superior to the "throw the code in events" garbage. Please, point out the
    >flaw.


    The flaw here is your assertion that those "monolithic" applications
    were neither easily extended nor maintainable. Your assertion that an
    app which does not follow object-based principles is not easily
    extendible or maintainable is a flawed assertion. Surely the holy
    grail of object-based development is software reuse? Otherwise, how do
    you become more productive? And yet, as we all know, despite the hype
    of the last five years since OOP was rediscovered, reuse is an elusive
    goal most people have yet to attain. I would argue that a
    well-designed "monolithic" app has more chance of promoting software
    reuse by dint of procedure libraries which can easily be decoupled and
    used in many other apps. In fact, the components I use in VB are only
    a minor deviation from that concept, which is probably why I like VB
    so much. I can buy for a few hundred dollars or less a "library" of
    components about whose underbelly I know absolutely zilch and that's
    great! I can re-use software (in the form of "component" libraries) in
    many different apps. So, if I'm using professionally-written
    components and they have been already "re-used" (i.e. tested) by many
    thousands of other customers before I buy my copy, surely I am
    enjoying optimum reuse? I place my control on a form and throw some
    code at the events. Job done. And very productively.

    Question: At what point does a monolithic app become monolithic? I
    believe you chose the word "monolithic" without really savouring its
    meaning in terms of computer applications. Do you want "monolithic" to
    mean "procedural" by any chance?

    Another question: If you are so sure that object-based VB.NET is
    better than the classic VB people are actually using, how do you think
    those VB users now will be persuaded over to VB.NET? I mean, let's
    look at its selling points:

    - more complex
    - needs a huge framework
    - is still proprietary
    - only available along with C#, C++ etc etc
    - not backward compatible
    - needs more memory
    - won't run on Windows 95
    - etc etc

    I mean, which one of those features do you think will be the killer
    which will cause swarms of willing VB developers to rush to the shops
    on D Day?

    >I suppose you thought I was ripping on VB 6. Again, you were WRONG. I was
    >pointing out how some "programmers" hacked things together in the past. I'm
    >assuming all professional programmers now know and use the object based features
    >of VB6. :-)


    Your assumption is misplaced since 70% of VB applications don't use
    objects in the way you mean and contain no classes. Huge numbers of VB
    devs have never written a class and will never write one. Why do you
    think there are now rumours that Microsoft may be dumbing down VB.NET
    in future versions? Could it be that they fear it's too complex for
    ordinary users to contemplate or comprehend? Ah, but it's the ordinary
    users wot pays the bills, not the relatively small number of purists
    to whom a deliverable is less important than how it gets written.

    >I think you missed the boat on RAD. Maybe, for your small applications, hacking
    >is the way. That is your choice. For me, I write medium to large applications,
    >which contain code, which is scalable, maintainable and reusable. Not one
    >offs.


    Again, it depends on where a "small" app becomes a "monolithic" one.
    If our "small" apps can feature in 25% of annual income for a
    multi-billion dollar international company, well, I'll happily accept
    "small" as an accolade, thanks!

    >As for code in events, that is a hack. Tons of code in the events. This is
    >the way I would expect a neophyte to write applications. There is no design.
    >Just hack it together. You know what I meant. There should be minimal code
    >in the events calling objects properties or methods.


    Or procedures and functions.

    >As for VB's role, I have been using VB for over eight years each and every
    >day for eight hours a day or more. The "Ruby VB" was an excellent start.
    >It was never intended to last as long as it did. It had a great run. Now,
    >it is off to VB.NET. This is the future. You can like it or not.


    I think you're jumping the gun here by predicting the future even
    before Microsoft have released the product. I think I'd prefer to wait
    and see first. Meanwhile, there are other products and avenues to
    explore, none of which chooses the "monolithic" Microsoft proprietary
    route. That I do like!

    MM


  13. #13
    Mike Mitchell Guest

    Re: Writer's Uninformed Statements

    On 2 Sep 2001 20:59:25 -0700, "Rich" <nomail@nomail.com> wrote:

    >I guess you missed my point. I was attempting to be diplomatic. I did not
    >want to say, "Here is what the experts say, if you do not believe them your
    >are an idiot." "Flaw" refuted.


    Many experts once said what a good idea eugenics was.

    First, choose your experts!

    MM

  14. #14
    Mike Mitchell Guest

    Re: Writer's Uninformed Statements

    On 2 Sep 2001 20:59:25 -0700, "Rich" <nomail@nomail.com> wrote:

    >Again, using solid OOD always leads to maintainable, reusable and extensible
    >applications.


    Evidence?

    MM

  15. #15
    Ian R Guest

    Re: Writer's Uninformed Statements


    "Mike Mitchell" <kylix_is@hotmail.com> wrote in message
    news:3b94a4ab.10708110@news.devx.com...
    >
    > VB.NET on the other hand is so full of bells and whistles you can
    > barely see the player any more. The thing needs a framework many times
    > larger than any of the VB1/2/3/4/5/6 packages did. You cannot just
    > fire up VB.NET, create an app, then give it to someone else on the
    > offchance they may have the framework. This, however, is what you CAN
    > do very easily with VB. It's a given that your "someone else" will
    > have a version of Windows that will run your app, and the most they'll
    > need, if they haven't already got it, is the VB runtime, a measly
    > megabyte or so.
    >


    No Mike, perhaps *you* can't "see the players any more". A lot of others
    can. If you don't need or want all the "extra features" don't use them. With
    a few exceptions you can still write pretty much the same VB6 code. As far
    as the framework goes, you're being deliberately thick again. We've gone
    through this before. All languages need some type of runtime and/or support
    files. Try using some of the tools you have for a change, like Depends and
    you'll soon find out that your "measly megabyte" isn't so "measly". If
    you're writing simple "Hello World" apps as you apparently do, it'll
    probally run as is, anything larger and you'll probally need the entire
    distribution.

    > You can witter on about "objects", and "object-based" till the cows
    > come home, but millions of VB users couldn't care less. They see VB,


    And millions of others do care.

    > as I do, as a kind of graphics package in which you "paint" your app
    > on a "canvas", and then "animate" it by adding event handling code.
    > The fact that I do not need to know about trigonometry, geometry,
    > algebra and other arcane stuff to produce a graphics creation is just
    > as valid in my use of VB.
    >
    > But in VB.NET the underbelly of the language is now exposed. No longer
    > is it sufficient for a programmer just to use it. They have to
    > understand how the intestines fit in the underbelly. We are now
    > expected to be our own butchers. VB.Halal, anybody?
    >


    The framework exposes a lot of things for those that need it. For those who
    don't, and want a simple drag and drop [insert control here] onto form then
    double click and type a couple of line of code type of approach, VB.NET does
    that as well. The new form object alone has numerous new properties that
    eliminate a lot of code that needed to be done in VB6. Heck, even *you* can
    use it.

    >
    > you become more productive? And yet, as we all know, despite the hype
    > of the last five years since OOP was rediscovered, reuse is an elusive
    > goal most people have yet to attain. I would argue that a


    That has nothing to do with OOP. It like anything, including procedural
    code, can be abused. For those who do understand it, it can make development
    easier, faster and more scaleable.

    > so much. I can buy for a few hundred dollars or less a "library" of
    > components about whose underbelly I know absolutely zilch and that's
    > great! I can re-use software (in the form of "component" libraries) in
    > many different apps. So, if I'm using professionally-written
    > components and they have been already "re-used" (i.e. tested) by many
    > thousands of other customers before I buy my copy, surely I am
    > enjoying optimum reuse? I place my control on a form and throw some
    > code at the events. Job done. And very productively.
    >


    You're using a form of OOP whether you like it or not. Which just shows that
    either you're extremely thick or extremely stubborn.

    >
    > Another question: If you are so sure that object-based VB.NET is
    > better than the classic VB people are actually using, how do you think
    > those VB users now will be persuaded over to VB.NET? I mean, let's
    > look at its selling points:
    >
    > - more complex


    In your mind perhaps. But then again I get the impression you find a form
    with one button fairly complex.

    > - needs a huge framework


    14 meg as opposed to VB6's 8 meg. Considering some of the installation
    benefits like XCOPY installs, side by side versioning etc, I think the
    slight difference is worth it.

    > - is still proprietary


    Earth to Mike. So is VB6 et al.

    > - only available along with C#, C++ etc etc


    What does that have to do with anything ? You're grasping at straws again
    Mike. If you don't want to use the other languages then don't.

    > - not backward compatible


    Not fully backwards compatible you mean. I've ported a number of my VB6
    projects over to .NET and with the exception of a few things I had to
    change, it runs fine. If you're coding in a PDS style or just simply a lazy
    *** programmer then yes you'll probally run into problems.

    > - needs more memory


    Requires about the same. Might help if you actually tried some of this stuff
    before you started passing hot air.

    > - won't run on Windows 95


    Windows 95 will be obsolete by the end of this year. Most business's have
    either already upgraded or will have by the time .NET gets released. Most
    new PC's ship with Windows ME or Windows 2000 and have been for the past
    year or so. The transition to .NET won't happen overnight so for the few
    Windows 95 diehards you can still develop in VB6, C++, Delphi or whatever.

    > - etc etc


    Care to be more specific on that one or is that too much for you ?

    >
    > Your assumption is misplaced since 70% of VB applications don't use
    > objects in the way you mean and contain no classes. Huge numbers of VB


    All VB apps use objects. Think about it.
    If 70% of VB developers don't use classes that's fine. That means there's
    30% who do and need a language that supports it. If the other 70% don't,
    then they don't have to use it just because the language supports it.

    > devs have never written a class and will never write one. Why do you
    > think there are now rumours that Microsoft may be dumbing down VB.NET
    > in future versions? Could it be that they fear it's too complex for
    > ordinary users to contemplate or comprehend? Ah, but it's the ordinary


    They're not "dumbing down" VB.NET. They're adding features to C#.

    > users wot pays the bills, not the relatively small number of purists
    > to whom a deliverable is less important than how it gets written.


    You obviously don't do code maintenance.

    >
    > I think you're jumping the gun here by predicting the future even
    > before Microsoft have released the product. I think I'd prefer to wait


    Considering it's Microsoft that's backing it and actually using it, it's
    pretty safe bet.

    > and see first. Meanwhile, there are other products and avenues to
    > explore, none of which chooses the "monolithic" Microsoft proprietary
    > route. That I do like!
    >


    HP is buying Compaq. That makes them the biggest PC maker. Does that mean
    you won't be using any hardware from them because they're "Monolithic" ?
    VB1-6 is proprietary,Delphi is proprietary, Kylix is proprietary, PowerBasic
    is proprietary. The code you develop at your company (assuming that you
    actually do development) is proprietary. If you don't like Microsoft for
    whatever reason, that's your right but don't knock what you don't understand
    much less tried. Finished that book yet ?




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