Re: Unix and OO Avoidance
From: peter_douglass (baisly_at_gis.net)
Date: Fri, 2 Jan 2004 22:14:08 -0500
"Bob Summers" <firstname.lastname@example.org> wrote in message
> On Tue, 30 Dec 2003 22:23:05 -0500, "peter_douglass" <email@example.com>
> > In a court of law, expert witnesses are given more latitude in their
> > testimony than non-experts. If Unix programmers, as a group, tend to
> > experts in the area of program design, then the fact that Unix
> > avoid OO would be highly significant. I will readily grant expert
> > Unix programmers with regard to the abilities to understand and maintain
> > highly complex code. (However, it could be argued that the greater the
> > ability in program design, the less the need for high-end talent in
> > maintenance.) I would question, however, whether Unix programmers, as a
> > whole, ought to be accorded the status of expert witnesses with respect
> > program design. I have supported my doubts with a data point, a data
> > which objective in the sense of being open to verification or
> > If someone believes we *ought* to accord Unix programmers expert status
> > the sphere of program design, then perhaps we need more data points to
> > consider.
> > I'd be interested to know what you really think on
> > this score. Should we treat Unix programmers, as a group, as experts in
> > this area?
[snip of hyperbole]
> Unix has also been wildly successful and it doesn't even have a monopoly
> it. That argues that Unix programmers in general must be doing something
Yes, they must be doing something right, but that is trivially true.
However, it doesn't address whether they are doing software design right.
It is certainly possible to be successful doing "something" right, yet doing
many things wrong.
> That OO doesn't seem to fit into a community that has been rather rabid
> simplicity and modularity is a very interesting data point.
I don't know that the Unix community is "rabid" about simplicity. Perhaps
they are known for this, and I haven't heard it. However, one could argue
that programs such as emacs refute the claim that the Unix community is
"rabid" about simplicity.
> However, back to your question. IME Unix programmers tend to be better
> than Windows programmers for a couple of reasons: the Unix programmers
> tend to be older, more experienced and thereby make fewer mistakes.
I worked with a C programmer who could (and unfortunately did) write
procedures spanning 6 or more pages of dense uncommented code, using
variables named i, ii, j, jj etc. He was incredibly fluent in C and I was
amazed that his code worked flawlessly. (I could never have written code
like that which worked at all). Yet perhaps because he was so fluent in C,
he did not appreciate the problems his style was for others. Mere mortals
like myself could never hope to reach his level of ability, and so it would
have been for our benefit if he had used less of his talent and more of his
I point this out to illustrate that code fluency need not go hand in hand
with good software practice.
> exposes its internals more than most OSs. That transparency attracts
> people who want to know how things work to Unix more than to Windows;
> Understanding how things work can improve someone's ability to build
> things. Someone who wants a turnkey solution will be more attracted by the
> Windows philosophy. There's nothing wrong with wanting a turnkey
> but that's poor preparation for building the solution yourself.
Again, this is not necessarily tied to good software practice. The desire
to work with the guts of a system is of course commendable, and the ability
to do so successfully is true talent. But...
About two years ago I was travelling in Canada. At a particular truck stop
there were a number of very unual objects. One was a jeep or something
similar with tires in the range of 20 ft diameter. Much bigger than a
monster truck. It was quite a sight. However, I was unable to determine
what one particular contraption was, so I inquired. I was told it was a
perpetual motion machine. I wasn't quite complete (or running), because the
owner hand not yet figured out how to harness the energy that it would
release. ;-). Anyway, it was a well constructed device some 15 or 20 feet
high which obviously required significant mechanical talent to construct.
Unfortunately, the inventor of this device had much greater mechanical
ability than scientific understanding (or perhaps he was just an artist with
a sense of humor, I never really knew).
Anyway, understanding how things work, in a nuts and bolts sense, does not
necessarily correlate with understanding how things work in a more general
sense. The inventor of the "perpetual motion machine" clearly understood
gears and pulleys and mechanical devices, but if we accept that he sincerely
believed his device to be a perpetual motion machine, we must conclude that
his nuts and bolts knowledge was not combined with a broader theoretical
[I know this example is a bit far afield, but its memory brings a smile to
my face ;-)].
> For example, the last company that I worked at had two projects side by
> that were developing two different products on the same ugly C++
> One group had all Windows programmers, the other had about half Unix
> call them Unix folks because they got their email on Unix workstations in
> spite of strong company pressure to use Windows. They also tended to do
> development on Unix.
> The Unix folk were also much more skeptical of OO than the Windows folk.
> The project with the Unix folks got done reasonably on time. The other
> project fired serveral managers due to lack of progress. They did
> ship their product.
This is an interesting anecdote. But alas, it is just an anecdote, and as
such is not likely to be persuasive among people whose experience supports a
> >> About as easily as object hierarchies can. Also,
> >> any large piece of software that has been extensively enhanced by
> >> of people over a long period of time will show some wear and tear.
> >Again, perhaps they are no worse than average.
> >> However, this example is similar to what happens when someone factors
> >> out every two line piece of code into its own method and wraps an
> >> every data structure. IME, this describes a lot of OO code.
> >> I've worked on several OO software products where the code was worn out
> >> at first release. Before OO, it seemed to take at least 5 or 10
> >> get to that state. It wasn't obvious to me that the designers of those
> >> had violated any OO dogma.
> >Yes, I worked on an "OO" project that had its entire code base scapped
> >the first release. The person in charge was an OO zealot, but to me his
> >design (to the extent there was a design) seemed very confused. Our own
> >experiences affect us profoundly. (Unfortunately, what I experience
> >affect others in the same way ;-). Was my experience an the result of an
> >organization that had poorly assimilated OO? The point could be debated
> >without end. That is why it is always nice to have objective data
> They were lucky that they could scrap it. I'm coming around to the
> the problem is with OO. If people drinking the water from a particular
> get sick, at what point do you conclude that the problem is with the well,
> with the constitutions of the people drinking from the well?
Perhaps never, because perhaps the problem is not in the well. It is
precisely on points like this that science differs from superstition.
Drinking water from the same well may be one factor that all the sick people
have in common, but it may not be the only factor, and it may not be the
causative factor. Again, I am not arguing that you are wrong in your
opinion of OO, I am arguing that your arguments are insufficiently precise.
> A couple of counter examples could sway me back towards the OO camp.
> my experience has been that the more influenced by OO a project is, the
> complicated, brittle, slower to build and slower to run it is.
Are you sure you mean this? A couple of counter examples and you would
switch camps? I think a more likely scenario is that you would conclude
that OO may be good in some situations but perhaps not in others. At least
that is what I would conclude.
I would offer as a "counter-example" a gui calculator, such as comes with
windows. [Such a calculator can be written in a purely functional style.
John Hughes wrote a paper on "arrows" which illustrates how this can be done
in a language such as Haskell. However, you will notice that he constructs
guis from composible pieces of code, and these pieces of code transform one
or more streams of data into another one or more streams of data. If you
squint, you will see a remarkable similarity to objects. Whether his
approach ought to be called object oriented, is an issue which others may
debate. Perhaps it is really "object based", or perhaps it is really
neither, as his code pieces are not the "objects" with which OO
practitioners are familiar. But "arrow" technology is almost completely
unknown outside of functional programming circles, and is arguably no
simpler than the OO or object based approach for GUI construction. Thus, I
would argue that OO or object based technology is likely to be the best
approach for GUI projects.] But I bet it was just an oversight on your part
that you weren't thinking of GUIs.
A second "counter-example" might be the very simulation problems that led to
Simula. I don't know if there are better alternative approaches, but in
some cases it seems that "modelling" some aspect of the real world would be
far more likely to succeed than an approach which doesn't involve such
modelling. Simulation is not something that I am knowledgable about, so I
won't give any concrete examples.
Note that these two "counter-examples" are very, very far from implying that
OO is the best choice, or even a good choice, for the majority of software
> I don't really understand why. I'm an engineer, to solve problems
> I need to use things that work. I don't have to understand why gravity
> to know that jumping off of a high place is likely to be painful.
Presumably you know enough physics to know that flying in an airplane can be
safe, and that skydiving might not have a painful ending. It's good to have
a rough idea of what will fail. It's even better to have a more precise
idea of what works and what will fail.
> I do have some vague ideas of the problems with OO.
That is good, but I would argue that you should try to refine these ideas.
Debate is not always useful, but it sometimes helps to clarify some issues.
> One thing that seems to go wrong with OO is that people build highly
> deep hierarchies into their code. There seems to a general principle (or
> least a guideline) that narrow, deep hierarchies are less flexible than
> wide, flat hierarchies. This can explain at least part of the
I think the most popular opinion these days is that deep hierarchies are
> People using OO also tend to go past modularity deeply into fragmentation;
> hoards of tiny methods that each do approximately nothing. Much like the
> people who went crazy with tiny functions in structured programming, the
> that do this are quite proud of their "really thin layers". These
> fragmented methods often end up being quite closely and implicitly coupled
> with each other. So, you end up with the worst of all worlds; fragmented
> spaghetti code.
A useful observation.
> The people that do this ignore warning signs like circular build
> just create a few more DLLs to continue on their course.
> Are these problems intrinsic to OO? It seems to be the logical outcome of
> what OO enthusiasts recommend; at least I have to work very hard to avoid
> those pitfalls when I apply OO techniques.
Could you spell out the logic for this logical outcome? I would suspect
that you, as many other including myself, have been the victim of
"enthusiats" who were not really that skilled, and who used dogma as a
> Another problem seems to be that a poor programmer can have much more
> with OO methods. With functional methods and languages the impact of
> people seemed to be much more limited. You could draw a line around their
> work, cut it out and replace it.
I definitely agree with that point. One poster on this news group, several
years ago compared OO to dynamite. I.e. something dangerous to let into
the wrong hands, but useful in some situations (such as mining) nonetheless.
> Between non-OO languages like C and OO languages, there was an
> step, module based languages. The ones I'm familiar with were proprietary
> and not widely used but they did seem to work fairly well. One big
> was that a module tended to be much larger than an object, say 10K to 20K
> of code instead of a hundred lines of code. Modules usually had much
> external interface methods for their size. A typical module might have
> half-a-dozen to 20 interface methods.
> Whenever I suggest that OO techniques might not lead to good results,
> resonds that my examples "aren't OO". I think that's what another poster
> this thread was getting at with his post on P-OOP.
Yes, Joe "Nuke me Xenu" Foster and the strawberry patch. I personally think
that for some problem domains OO has little or no benefit and significant
costs and risks. It therefore seems to me stupid to claim that if one
experiences troubles in an OO project, then the OO must not be "proper" OO.
That mentality says one size fits all, and that OO is the key to good
software everywhere. I don't buy it, and I think such ideas are dangerous.
> Bob S
I've enjoyed this little exchange.