Speaking of strings...

[Jason]

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

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

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

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

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

[Phil Weber]

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

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

txtBox.Font.Italic = True

--
Phil Weber

[W.E. (Bill) Goodrich, PhD]

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

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

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

> >> > ***snip***

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

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

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

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

a.b = c.d + e.f

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

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

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

You might want to consider two points:

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

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

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

> >Wrong again.

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

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

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

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

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

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

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

[...]

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

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

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

> This article is all written for Java,

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

> and all the terminology is targeted at OO.

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

> And academia.

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

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

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

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

> The key phrase being "not necessarily."

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

[...]

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

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

> >> That makes things more modular.

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

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

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

> Good encapsulation hides complex code behind simpler interfaces.

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

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

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

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

> Not the code. Not the data.

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

> This is modular.

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

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

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

> which makes it a good tool.

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

> Good tools do not need to be perfect.

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

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

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

> >And even more inimical to modularity.

> If used incorrectly.

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

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

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

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

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

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

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

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

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

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

> Are you incapable on common sense on this point?

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

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

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

> Okay, what would you suggest would be better?

Old fashioned modularity. As I have consistently maintained.

> Let's have a specific example.

The C I/O libraries.

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

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

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

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

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

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

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

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

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

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

Ok, an even more simplified summary:

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

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

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

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

> Or shut up.

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

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

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

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

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

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

1) It is simpler.

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

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

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

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

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

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

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

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

And of course, that doesn't even begin to touch on the areas where it
is merely "as good as" OO. Or those where it is only "a little better"
than OO. Or the fact that MP has been in productive use for the better
part of a half century, with more or less continual refinements along
the way.

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

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

> Well, I could break down an object

....OO specific construct...

> into a virtual function table associated

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

> with some arbitrary data set,

Why?

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

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

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

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

> So nyah. :-P

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

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

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

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

Not even in many situations.

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

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

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

[Mike Mitchell]

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

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

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

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

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

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

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

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

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

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

Ditto.

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

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

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

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

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

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

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

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

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

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

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

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

MM

[Jason]

Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
>On 14 Oct 2002 13:42:03 -0700, "Jason" <jason@hotmail.com> wrote:
<<SNIP>>
>Great! I shall update my CV this very day and make sure OOP figures
>largely in my long list of skills and talents.
>
>MM

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

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

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

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

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

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

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

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

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

[Jason]

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

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

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

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

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

[W.E. (Bill) Goodrich, PhD]

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

[...]

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

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

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

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

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

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

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

> You trash everything anyone has to say,

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

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

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

> Don't like OO?

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

> What's better?

Modular programming, under equivalent conditions.

> And why?

Here is a brief list I gave in another post:

1) It is simpler.

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

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

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

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

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

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

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

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

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

> Put up or shut up.

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

--

W.E. (Bill) Goodrich, PhD

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

[Mike Mitchell]

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

> 1) It is simpler.
>
> 2) It is closer to the way people normally think, and is therefore
> more intuitive.
>
> 3) It is closer to the way computers operate, and generally creates
> less unnecessary overhead.
>
> 4) It is closer to the realities of most problem domains.
>
> 5) It avoids all of the problems inherent in class related OO
> constructs (inheritance, overloading, etc.).
>
> 6) It avoids problems caused by confusion between data access and
> code execution.
>
> 7) It concentrates the code for a given function in one place, and
> limits the potential range and scope of unwanted side effects
> from changes to that code.
>
> 8) It is easier to maintain and upgrade by people other than the
> original designer(s) and programmer(s).
>
> 9) It is practical to do in most languages, from Assembly up.

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

MM

[Jason]

Mike Mitchell <kylix_is@yahoo.co.uk> wrote:
>On Tue, 15 Oct 2002 01:14:38 -0600, "W.E. (Bill) Goodrich, PhD"
><bgoodric@netzero.net> wrote:
>
>> 1) It is simpler.
>>
>> 2) It is closer to the way people normally think, and is therefore
>> more intuitive.
>>
>> 3) It is closer to the way computers operate, and generally creates
>> less unnecessary overhead.
>>
>> 4) It is closer to the realities of most problem domains.
>>
>> 5) It avoids all of the problems inherent in class related OO
>> constructs (inheritance, overloading, etc.).
>>
>> 6) It avoids problems caused by confusion between data access and
>> code execution.
>>
>> 7) It concentrates the code for a given function in one place, and
>> limits the potential range and scope of unwanted side effects
>> from changes to that code.
>>
>> 8) It is easier to maintain and upgrade by people other than the
>> original designer(s) and programmer(s).
>>
>> 9) It is practical to do in most languages, from Assembly up.
>
>A very succinct summary of my feelings about this! Brilliant!
>
>MM

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

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

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

[Mike Mitchell]

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

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

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

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

MM

[Jason]

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


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

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


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

Really. Seriously.

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

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

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

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

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

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

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

[Mike Mitchell]

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

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

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

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

See above.

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

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

MM

[Jason]

"W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
>In article <3daa3d7a$1@10.1.10.29>,
>"Jason" <jason@hotmail.com> writes:
>
>[...]
>
>> Hey, Bill, instead of trashing OO, why don't you suggest something
>> better.
>
>Yet more of your tactical illiteracy? I have consistently been
>suggesting something better: modular programming. You have even quoted
>such suggestions.
><<SNIP>>
>Here is a brief list I gave in another post:
>
>1) It is simpler.
>
> 2) It is closer to the way people normally think, and is therefore
> more intuitive.
>
> 3) It is closer to the way computers operate, and generally creates
> less unnecessary overhead.
>
> 4) It is closer to the realities of most problem domains.
>
> 5) It avoids all of the problems inherent in class related OO
> constructs (inheritance, overloading, etc.).
>
> 6) It avoids problems caused by confusion between data access and
> code execution.
>
> 7) It concentrates the code for a given function in one place, and
> limits the potential range and scope of unwanted side effects
> from changes to that code.
>
> 8) It is easier to maintain and upgrade by people other than the
> original designer(s) and programmer(s).
>
> 9) It is practical to do in most languages, from Assembly up.
>
>And of course, that doesn't even begin to touch on the areas where it
>is merely "as good as" OO (such as handling of complex data
>structures). Or those where it is only "a little better" than OO (such
>as availability of libraries of existing source code). Or the fact
>that MP has been in productive use for the better part of a half
>century, with more or less continual refinements along the way.

Okay, just two more questions:

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

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

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

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

(2) Which is it?

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

[Jason]

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

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

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

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

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

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

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

Correct me on this if I am wrong here.

[PWilmarth]

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

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

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