Xref: utzoo comp.object:437 comp.lang.c++:5564
Path: utzoo!mnetor!tmsoft!torsqnt!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard
From: eberard@ajpo.sei.cmu.edu (Edward Berard)
Newsgroups: comp.object,comp.lang.c++
Subject: Re: Has X Widget Library Collapsed?
Summary: accuracy, ... and human frailties
Message-ID: <625@ajpo.sei.cmu.edu>
Date: 19 Nov 89 18:43:58 GMT
References: <28.UUL1.3#913@acw.UUCP>
Lines: 87

In article <28.UUL1.3#913@acw.UUCP>, guthery@acw.UUCP (Scott Guthery) writes:
> There is a story making the rounds of the X-windows community that
> the reason there isn't any documentation on the X widget library is
> that no one knows how it works any more; that it is such a twisted
> mass of inheritance, mix-ins, and polymorphisms that it is no longer
> comprehensible let alone maintainable.  In fact, consideration
> is now being given to wholly rewriting the X widget library.

As Scott has correctly pointed out, human beings have a good deal of
difficulty distinguishing between a "bad idea" and "a bad
_implementation_ of a _good_ idea."

Given the need for interoperability (i.e., the degree to which an
application running on one node in a network of (potentially
dissimilar) computers, can use the (hardware or software) resources
of a different computer in the same network), and the commitment from
major vendors, the X Windows System seems to be a viable choice. Few
people, however, want to use only the low-level intrinsics defined by
the de facto standard. Thus, we have the strong desire (if not the
outright need) for a library of higher-level capabilities (i.e.,
"widgets") fashioned from the basic intrinsics.

Few public domain items represent the quality of product on which an
organization would want to "bet its future." Very often, public domain
libraries are meant to represent some simple examples of basic
concepts. It should surprise no one that these libraries frequently
contain partially formed ideas, and many examples of "build one to
throw away." I could also observe that very few "for profit"
organizations wish to share their hard won capabilities with their
competitors, and would not place "quality software" in the public
domain.

Suppose, however, that someone did not like a concept -- maybe simply
because the idea was new, or because they seemed to be having little
success while others reported a good deal of success. Instead of
blaming one's self, it might be easier to pretend that the concept was
"just a bunch of hot air." But, how could one justify such a claim? A
very common technique is to search for a "horror story" which can be
twisted into a "plausible justification." Once such a horror story was
found, the more plausible explanations could be ignored, and the focus
could be shifted to create the desired effect.

Scott is honestly concerned with the viability of object-oriented
technology. To that end, he has volunteered to point out potential
problems. Whereas some people would only point out problems to
"discredit" a technology, Scott's primary aim is that object-oriented
technology be well-thought-out, and implemented correctly (where
appropriate).

> Does this remind anyone but me of the go-to spagetti code days?  
> Do you then wonder what the OO version of Knuth's famous "Go To
> Considered Harmful" will look like?  How about "Inheritance
> Considered Harmful"?  And then aren't you just breathless waiting 
> for the flood of structured object-oriented programming papers?  

Here, Scott is attempting to accomplish two goals:

	1. He wants to see if we are really reading his messages. Most
	   people know that it was E.W. Dijkstra who authored the
	   famous 1968 letter to the Communications of the ACM, i.e.,
	   "Go To Statements Considered Harmful." [It was six years
	   later that Knuth published his famous "Structured
	   Programming With Go To Statements" article.]

	2. His sarcasm in the second part of the paragraph does not
	   mean that he is against an organized approach to
	   object-oriented software engineering. He merely wants us to
	   demand rigor. For example, the rigor that people such as
	   Dijkstra, Harlan Mills, F. Terry Baker, and Knuth brought
	   to structured programming.

Finally, before someone labels me "an apologist for object-oriented
technology," or (worse) "an object-oriented purist," remember that I
too demand rigor, and well-researched justifications. I feel strongly
that object-oriented technology can make major contributions to the
state of the practice (and the state of the art). However, like Scott,
I want a reasonable degree of rigor in the process.

				-- Ed Berard
				   (301) 353-9652

P.S.: I just got back from two weeks in Germany, where I was providing
      consulting and training to a large chemical company on
      object-oriented requirements analysis, and object-oriented
      design. I informed them of the potential problems, as well as
      the potential benefits of object-oriented technology. They now
      know that OO offers potential benefits, but no guarantees.