guthery@acw.UUCP (Scott Guthery) (11/17/89)
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.
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?
In the words of Yogi Bera, "It's deja vu all over again." I
wonder if our bosses will ever catch on.
Cheers, Scott
+*+*+*+*+*+*+*+*+*+*+*+*+ Austin Code Works +*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+
NET Domain: guthery@uunet.uu.net Post: 11100 Leafwood Lane
COM Domain: guthery@acw.com Austin, Texas 78750-3409 USA
US Domain: guthery@acw.austin.tx.us FAX: +1 (512) 258-1342
Usenet: {uunet}!acw!guthery Voice: +1 (512) 258-0785
CompuServe: 70240,221 TELEX: 446370 (austincodewrks)
Packet: N5MDE @ KB5PM EasyLink: 62752994
Fidonet: 1:382/12 Prodigy: KSWS89A
+*+*+*+*+*+*+*+*+*+*+*+*+* The Source of C +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+eberard@ajpo.sei.cmu.edu (Edward Berard) (11/20/89)
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.
dlw@odi.com (Dan Weinreb) (11/20/89)
Well, that story doesn't hold a lot of water. For one thing, there is no such thing as "the X widget library"; there are many separate X widget libraries. Some are undocumented, but others have very extensive documentation (such as the Motif library). So whoever told you this story is pretty confused. It's true that the code for the typical X widget (in any of the libraries) is pretty hard to understand. But inheritance is not the cause of the problem. The problem is that they are written in C, which does not provide support for inheritance. The poor widget-writers have to do object-oriented programming without any help from the language. The resulting code is extremely verbose, and, in my opinion, often obtuse. If they used, say (just to pick a language at random :-) C++, the code might be much cleaner. For an example of a user interface toolkit, based on X but not on the X intrinsics, and written in C++, study InterViews. It uses inheritance very heavily, and inheritance makes its code much cleaner and easier to maintain than if inheritance had not been used. Dan Weinreb Object Design, Inc. dlw@odi.com
sakkinen@tukki.jyu.fi (Markku Sakkinen) (11/21/89)
In article <28.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes:
- [...]
-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?
- [...]
The flood has started already (at least to dribble).
The working title of the paper I wrote for ECOOP'89 was just that,
although not in 100% earnest (the final title was "Disciplined inheritance").
As I mentioned about that at the conference, it appeared that at least
one other speaker had thought about using that title.
Markku Sakkinen
Department of Computer Science
University of Jyvaskyla (a's with umlauts)
Seminaarinkatu 15
SF-40100 Jyvaskyla (umlauts again)
Finlandmujica@ra.cs.ucla.edu (S. Mujica) (11/21/89)
on 17 Nov 89 03:29:27 GMT, guthery@acw.UUCP (Scott Guthery) said: > 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 you really meant "Dijkstra", right? ^^^^^ Sergio Mujica mujica@cs.ucla.edu Computer Science Department, UCLA
kcr@netxdev.DHL.COM (Ken Ritchie) (11/21/89)
Newsgroups: comp.object,comp.lang.c++,comp.lang.smalltalk Subject: DIRECT REFERENCE CONSIDERED HARMFUL Summary: Use message passing, not variable reference. No fondling. References: <28.UUL1.3#913@acw.UUCP> Reply-To: kcr@netxdev.UUCP (Ken Ritchie) Followup-To: comp.object Organization: /etc/organization Keywords: In article <28.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes: >Do you then wonder what the OO version of [Edsger Dijkstra's] famous "Go To >Considered Harmful" will look like? Yes, Scott... I've wondered... and maybe we just saw it this year... hmmm? Get out your JOOP vol.2, no.1 (May/June 1989) and see pages 34-40. "VARIABLES LIMIT REUSABILITY" -- sounds like a dire pronouncement! Allen Wirfs-Brock and Brian Wilkerson provide a very convincing argument against using direct reference to variables -- recommending, instead, that methods ALWAYS be implemented for evaluating/changing state variables. AWB & BW say "Direct references to variables severly limit the ability of programmers to refine existing classes." It probably won't take six years for the follow-up controversy to emerge, but if history has any hints for us, there WILL be lots of dialogue over efficiencies and such.... Perhaps this initial argument will also be extended to prohibit "fondling" (friends accessing private parts). AWB & BW briefly discuss the potential tradeoff of man/machine efficiency. I say we should follow Dijkstra's admonition (1972) to make the most of our limited mental capacities -- rather than fuss over micro-efficiency. [Put your torches away, folks, I KNOW there's a time to split nano-secs!] As a system designer, I've often found it advantageous to design for some distribution of function even if you [initially] cast it all into a monolith. >>> CONSIDER THIS: As soon as you decide you need to distribute an example application across a multi-nodal network system -- local or otherwise -- YOU'LL SUDDENLY BE VERY GLAD YOU DID IT WITH MESSAGES (in whatever language). Except for the speed of light (186Kmi/s - "it's the law") there is virtually no limit to the kind of architectures which will support applications based on message passing models. Besides, in the event of a monolithic or shared storage environment for some application, optimizers could tweak the code. NOTE: Scott's posting <reference above> was to comp.object and comp.lang.c++, to which I've added comp.lang.smalltalk. For general discussion, I recommend we FOLOWUP-TO: comp.object (only) -- except for language-specific issues. OK? Regards to all! ...and, as Ed [Berard] would say: "Thanks for listening!" BIBLIOGRAPHY Edsger W. Dijkstra, "The Humble Programmer", CACM 15(10), Oct. 1972, 859-866. [This was an inspiring lecture, given upon receipt of the ACM Turing Award.] [I have heard it on audio-tape, but I don't know if such is available now.] For you history buffs... EWD, "Go to statement considered harmful", CACM 11(3), Mar. 1968, 147-148, & 538, 541. [This is the (in)famous letter to the ACM forum, leading to war!] Donald E. Knuth, "Structured Programming with GO TO Statements", ACM COMPUTING SURVEYS 6(4), Dec. 1974, 261-301. [It's not the goto's or lack thereof...] _______________________________________________________________________________ Ken Ritchie (d/b/a KCR) Usenet: ...!uunet!netxcom!netxdev!kcr c/o NetExpress Communications, Inc. FAX/office: USA (703) 749-2375 8500 Falling Leaf Road Voice/office: USA (703) 749-2268 Springfield, Virginia (USA) 22153-2505 Voice/home: USA (703) 455-7514 "OBJECTS... ARE CLOSER THAN THEY APPEAR" -- inscription from a convex mirror _______________________________________________________________________________
shap@delrey.sgi.com (Jonathan Shapiro) (11/24/89)
In article <1862@netxcom.DHL.COM> kcr@netxdev.UUCP (Ken Ritchie) writes: >Get out your JOOP vol.2, no.1 (May/June 1989) and see pages 34-40. >"VARIABLES LIMIT REUSABILITY" -- sounds like a dire pronouncement! >Allen Wirfs-Brock and Brian Wilkerson provide a very convincing argument >against using direct reference to variables -- recommending, instead, that >methods ALWAYS be implemented for evaluating/changing state variables. Sigh. Okay. Who's going to write the next famous article: "Variables Considered Harmful"? You know, once you stick a function name out there, you're stuck with it forever, and I have occasionally found that to be a real bugaboo. I think that in our next major programming language we should abandon the notion of "names". Jonathan S. Shapiro Silicon Graphics, Inc.