Can a low-level programmer learn OOP?

[Wayne Brehaut]

On Sat, 14 Jul 2007 19:18:05 +0530, "Rustom Mody"
<rustompmody at gmail.com> wrote:

>On 7/14/07, Alex Martelli <aleax at mac.com> wrote:
>>
>> OOP can be abused (particularly with deep or intricate inheritance
>> structures).  But the base concept is simple and clear: you can bundle
>> state and behavior into a stateful "black box" (of which you may make as
>> many instances, with independent state but equal behavior, as you need).
>>
>
>Many years ago (86??) Wegner wrote a paper in OOPSLA called Dimensions
>of Object Orientation in which he called the 'base concept' of 'bundle
>of state and behavior' as 'object based' programming and
>'object-oriented' as object-based + inheritance.

Not quite--according to him:

object-based + classes => class-based
class-based + class inheritance => object-oriented

I.e., "object-oriented = objects + classes + inheritance".

This was not the, by then, standard definition: to be OO would require
all four of:

1.  modularity (class-based? object-based?)
2.  inheritance (sub-classing)
3.  encapsulation (information hiding)
4.  polymorphism ((sub-) class-specific response to a message, or
processing of a method)

Unfortunately, most of the "definitions" (usually just hand-waving,
loosey-goosey descriptions) found on the web include none--or only one
or two--of these fundamental requirements by name, and are so loose
that almost any proramming paradigm or style would be OO.

>What Alex is saying is (in effect) that object-based is simple and
>clear (and useful) whereas the object-orientation is subject to abuse.

But OO is also simple and clear (if clearly defined and explained and
illustrated and implemented), and ANY programming style is subject to
abuse. During the hey-day of Pascal as an introductory programming
language (as often misused as more than that) I found many  often
spent much of their time defining the data types their program would
use.

>This anyway is my experience: C++ programmers are distinctly poorer
>programmers than C programmers -- for some strange reason closeness to
>the machine has a salutary effect whereas the encouragment of
>uselessly over-engineered programs makes worse programmers.

But this is a tautology: "over-engineered" programs are, by definition
or terminology,  not a good thing--independent of what PL or style
they're finally implemented in (assuming that by "engineering" you
mean "design" or similar).  Many of my Pascal students over-engineered
their solutions to simple problems too?

>GUI is one of those cases wherein inheritance actually helps people
>produce better code but this is something of an exception.

This seems to imply that the list of applications you have in mind or
have worked on includes fewer domains that might profit from full OO
instead of just OB. My guess is that there are many application
domains in which analysts and programmers often think in an "OO way",
but implement  in just an OB way because of the PL they or their
employer requires or prefers: in some--perhaps many--of these cases
they have to do "manually" what OO would have automated.  

There is a problem, though, of (especially university and college)
education and training in OOP  "talking about" how glorious OO is, and
requiring students to use OO techniques whether they're most
appropriate or not (the "classes early" pedagogical mindset).  And
this problem is compounded by teaching introductory programming using
a language like Java that requires one to use an OO style for even
trivial programs. And by using one of the many very similar
introductory texbooks that talk a lot about OO before actually getting
started on programming, so students don't realize how trivial a
program is required to solve a trivial problem, and hence  look for
complexity everywhere--whether it exists or not--and spend a lot of
time supposedly reducing the complexity of an already simple problem
and its method of solution.

But as I noted above, a similar problem occurred with the crop of
students who first learned Pascal: they often spent much of their time
defining the data types their program would use, just as OO
(especially "classes early")  graduates tend to waste time
"over-subclassing" and developing libraries of little-used classes.

The answer is always balance, and having an extensive enough toolkit
that one is not forced or encouraged to apply a programming model that
isn't appropriate and doesn't help in any way (including
maintainability).  And starting with a language that doesn't brainwash
one into believing that the style it enforces or implies is always the
best--and texbooks that teach proper choice of programming style
instead of rigid adherence to one.

wwwayne