Speaking of strings...

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

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

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

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

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

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

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

> >[...]

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

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

> ><<SNIP>>

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

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

> >1) It is simpler.

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

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

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

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

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

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

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

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

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

> Okay, just two more questions:

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


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

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

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

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

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

Only for limited problem domains, as described above.

> What is a ListBox?

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

> What is a Collection?

Different things in different contexts.

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

When appropriate. As it often is.

> and program char-array strings

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

> and use functions for everything.

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

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

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

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

> you just prefer that someone else write them.

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

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

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

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

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

> (2) Which is it?

Neither, as described above.

> You can't have it both ways.

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

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

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

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

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

--

W.E. (Bill) Goodrich, PhD

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

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

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

>> Either you use a language that does not use any object constructs,
>> or you don't.
>
>That is entirely meaningless. C++ "uses" object constructs, but it
>entirely possible - and common - to write major programs in it without
>using the OO specifics. Even the usual components are widely available
>in non-OO configurations (although many also have OO compatible
>versions for those who like such things).

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


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

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

These are facts, not my opinion.

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

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

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

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

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

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

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


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

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

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

> > <snip/>

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

> > 1) It is simpler.

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

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

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

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

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

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

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

> So?

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

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

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

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

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

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

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

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

More like deceptively natural-appearing code.

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

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

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

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

> What confusion?

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

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

> It also makes that function large and unwieldy,

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

> prone to error and difficult to manage.

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

[...]

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

> Why have OO languages been developed then?

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

> Why have they proved so popular?

Because of the Academic fad.

> Are we being brainwashed,

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

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

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

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

--

W.E. (Bill) Goodrich, PhD

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

"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
>> > 2) It is closer to the way people normally think, and is
>> > therefore more intuitive.
>
>> I disagree. I find OO based design much more natural than plain
>> Modular development.
>
>So you have claimed. However, the Cognitive researchers, from Piaget
>to Gazzaniga, paint a different picture. And since your "observation"
>is neither systematic nor objective, I will pay more attention to
>their claims than to yours.
>
>Contrary to the misplaced claims of some early OO advocates, people
>clearly think of "things" and "actions" differently and separately.
>MRI studies and the like have even shown that they use different
>parts of the brain to do so.

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

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


>> > 3) It is closer to the way computers operate, and generally
>> > creates less unnecessary overhead.
>
>> So?
>
>So, the unnecessary overhead slows down execution and impairs the
>ability to multitask with other programs. ESPECIALLY when the other
>programs are similarly bloated.

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

>> Write your code in hex if you want to get down to the metal.
>
>Hardly a surprising rejoinder from one of the Cheerleaders for the
>20 MB runtime. Completely irrelevant - and preposterous - but hardly
>surprising.

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

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

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

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

>> > 4) It is closer to the realities of most problem domains.
>
>> Not in any large scale developments that I've worked on; invariably
>> OO design has been able to model the 'real-world' problem at a much
>> closer level.
>
>More like *you*, with your personal prejudices and limitations, were
>more comfortable doing so. The large scale developments I have worked
>on, from spacecraft to network backbones, have consistently mapped
>more closely to the modular analysis than to OOD.

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

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

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

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

Can we please stay on subject, which is VB?


>> > 5) It avoids all of the problems inherent in class related OO
>> > constructs (inheritance, overloading, etc.).
>
>> Operator overloading can be a thorny issue; if used correctly it's
>> a boon, if not it's a problem I'll grant you. However, it can make
>> for very natural code;
>
>More like deceptively natural-appearing code.

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

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

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

>> Point p = new Point(1, 2);
>> Point q = new Point(4, 5);
>> Point r = p + q;
>
>> When you change the *meaning* of the overloaded operator, then you
>> cause problems and lead to code obfuscation.
>
>And you didn't even touch on the problems caused by excessive
>inheritance, fragile base classes, and the like.

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

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

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

>> > 6) It avoids problems caused by confusion between data access
>> > and code execution.
>
>> What confusion?
>
>For instance, the confusion caused by unexpected execution of seeming
>data members in various conditional operations.

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

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

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

>> > 7) It concentrates the code for a given function in one place, and
>> > limits the potential range and scope of unwanted side effects
>> > from changes to that code.
>
>> It also makes that function large and unwieldy,
>
>No more so than the equivalent "method". And generally less so, since
>commonalties which are not obvious when spread out across several
>generations of inheritance can be collapsed into a more compact form.
>Also, MP design calls for breaking large, multifunction code into
>separate, single function modules. That serves to limit such bloat as
>well.

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

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


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

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

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


>> > 9) It is practical to do in most languages, from Assembly up.
>
>> Why have OO languages been developed then?
>
>For the same reason that "Structured Programming" languages (such as
>Structured COBOL) were. The academic fad - and associated propaganda -
>created a perceived demand. And there was money to be made by filling
>that demand (no matter how irrational).

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

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

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

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


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


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


>> Why have they proved so popular?
>
>Because of the Academic fad.

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

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

Why have they proved so popular?

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

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

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

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

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

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

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

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

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

>> or have we actually proved to ourselves that this is a viable
>> method of development?
>
>Generally "accepted uncritically" rather than "proved". It is no
>coincidence that the most outspoken advocates of the fad exhibit a
>strong tendency to validate their beliefs based on statements of
>"appropriate authorities" rather than personal evaluation of
>objective evidence.

Pot, kettle, tope.

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

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

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

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

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

Or were you expecting something different, maybe more theoretical?

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

> > > 2) It is closer to the way people normally think, and is
> > > therefore more intuitive.
>
> > I disagree. I find OO based design much more natural than plain
> > Modular development.
>
> So you have claimed. However, the Cognitive researchers, from Piaget
> to Gazzaniga, paint a different picture. And since your "observation"
> is neither systematic nor objective, I will pay more attention to
> their claims than to yours.
>
> Contrary to the misplaced claims of some early OO advocates, people
> clearly think of "things" and "actions" differently and separately.
> MRI studies and the like have even shown that they use different
> parts of the brain to do so.

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

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

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

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

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

> and to try to understand your point of view.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--

W.E. (Bill) Goodrich, PhD

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

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


Auntie Emm? Toto? ?ZZZZZZZZZZZZZZZ?


"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
>In article <3dad961d$1@tnews.web.devx.com>,
>"Jason" <jason@hotmail.com> writes:
>
>> Yuh know, I am trying not to post negatively,
>
>You're not trying very hard, apparently. Your posts in this thread
>have consistently been heavily laced with personal insults, sarcasm,
>misrepresentation, inappropriate language, and other hallmarks of
>negativity. You set the tone for the exchange, and now it is a little
>late to complain that I was less than consistently "positive" in
>response to your childish outbursts.
>
>> and to try to understand your point of view.
>
>Then try actually READING what I write and cite, rather than scanning
>it for "sound bytes" you can twist into excuses for your continuing
>negativity.
>
>> And you still post an insult in every other sentence.
>
>Hardly. Of course, you have shown a consistent tendency to ignore the
>substance of the posts, so I can see how your little sound byte exerpts

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

>like "that was too hard to read" and "did I use the word you quoted my
>use of? I don't think so," you can expect to be called on them. If you
>consider that a "personal insult" then you should quit playing such
>games.
>
>> But every OTHER sentence is providing some information, so I will
>> try to deal with that.
>
>To date, you have primarily dealt with that by complaining that there
>was too MUCH information, that it used too many hard words, or that
>the citations weren't oversimplified enough for your tastes. And then
>"challenging" me to answer questions that I had repeatedly (and at
>length) answered in those posts.
>
>> Simply put, how do you reconcile the fact that forms, controls, and
>> ActiveX DLLs are all OO-based (without inheritance, granted), in the
>> context of modular programming in VB?
>
>By taking the long view and the deep view of such components, and
>treating them as components. The long view considers the fact that
>the specific predecessors of those components were not OO, and their
>eventual successors will probably not be OO. The deep view notes that
>M$ (like most large organizations) tends to leverage existing code
>rather than unnecessarily rewriting it. Very little of the code in
>those M$ forms, controls, and ActiveX DLLs is OO in origin or
>structure. Instead, it is the older, non-OO code in an OO wrapper.
>If I have to deal with the counterproductive wrapper to get to the
>otherwise useful functionality underneath, I will have to make a
>case by case cost/benefit judgment. In those cases where I use the
>component, I minimize the problems by treating it much the same way
>I would treat the equivalent non-OO component. I do not explicitly use
>the problematic OO specific constructs (inheritance, overloading, etc.)

>with them, I simply use the components as components.
>
>How do you reconcile the fact that most of those components are non OO
>code in an OO wrapper with your "products of OO" argument?
>
>> What I mean is, there are a number of programs that are written in
>> C that are still around, and these programs are strictly MP.
>
>No, many of them are not even MP. You still seem unable to grasp the
>difference between MP and "not OO", just as you seem unable to grasp
>the difference between OO code and any-way code which uses one or more
>OO specific construct(s).
>
>> But with VB, you can't write more than about 10 lines of code
>> without using some sort of object.
>
>With M$ redefining data structures and variants, that claim (while
>effectively meaningless) has some superficial semblance of fact for
>VB.NET. Much less so for VB6. The central issue is whether they are
>being used AS "objects" in any meaningful way, or are being used as
>data structures and "functions with funny calling sequences". In the
>latter case, it is completely preposterous to claim that the program
>is "using objects" in any meaningful sense. And since the "funny
>calling sequence" is most often passing through a superficial OO
>wrapper to a non OO body of functional code, attempts to use the
>nature of the wrapper to bolster a "using OO" claim are particularly
>pointless.
>
>> What I am trying to understand here is, are you for "strict" MP,
>> or MP that makes use of object libraries others have written, or do
>> the object libraries in VB somehow fall under the MP umbrella, so
>> they are not actually object libraries at all?
>
>What you are calling "object libraries" are by and large just
>component libraries with superficial OO wrappers to begin with. So
>they are not really "object libraries" at all in any meaningful
>sense. Creating and using component libraries is entirely consistent
>with MP, irrespective of such superficial wrappers.
>
>And again you seem to be falling into the false dichotomy of OO/MP.
>It is NOT true that every approach which is not OO is therefore MP.
>The kinds of "any way", undesigned, code as you go development you
>have tried to ascribe to MP is neither MP nor OO. Just as such
>undesigned, off the cuff programming does not become OOP if you throw
>in a library class or two.
>
>--
>
>W.E. (Bill) Goodrich, PhD
>
>*-----------------------*--------------------------------------------*
>* CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
>* * *
>* Without Aversive * ctgcentral@earthlink.net *
>* Behavior Modification * Creative Technology Group *
>* or Drugs * PO Box 286 *
>* * Englewood, CO 80151-0286 *
>*-----------------------*--------------------------------------------*

"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
>In article <3dad961d$1@tnews.web.devx.com>,
>"Jason" <jason@hotmail.com> writes:
>
>> Yuh know, I am trying not to post negatively,
>
>You're not trying very hard, apparently. Your posts in this thread
>have consistently been heavily laced with personal insults, sarcasm,
>misrepresentation, inappropriate language, and other hallmarks of
>negativity. You set the tone for the exchange, and now it is a little
>late to complain that I was less than consistently "positive" in
>response to your childish outbursts.
<<snip>>

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

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

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

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

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

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

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

> I wrote, what, 3 paragraphs?

And packed volumes worth of misinformation and fallacy into them.

> But let's get to the point.

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

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

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

> Let's stick to VB.

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

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

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

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

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

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

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

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

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

> OCXs are objects.

OCXs are rarely - if ever - anything but wrappers.

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

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

> A Form is a Class.

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

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

> These are facts, not my opinion.

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

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

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

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

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

> or you are doing simple OO programming.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

--

W.E. (Bill) Goodrich, PhD

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

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

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

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

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

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

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

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

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

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

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