Jan 1998 Object Magazine Online Interview -- James Coplien
Object Magazine Online: What is your favorite programming language? James Coplien: I most enjoy programming in the Graphical Object System Interface Language, better known as GIL, an internal Bell Labs language developed by Tom Burrows more than 15 years ago. I still program in it, and it's still used on a few projects inside the Labs. It's kind of an applicative Smalltalk designed for graphics-intensive fault-tolerant applications. I've never had an easier time writing powerful programs in any other language. OMO: What is your favorite software tool? JC: It comes down to a contest between a #2 pencil and an index card. The former, with paper, is most useful for one-person forays into the structure of stuff. The two together are most useful with a group of friends as we explore the structure of stuff together. CRC cards are a wonderful tool. OMO: What is your favorite pattern? JC: We're less interested in individual patterns these days than in pattern languages. Ward Cunningham's CHECKS pattern language still stands in my mind as one of the best and most exemplary pattern languages, both in its content, its form, and its possible interpretations. OMO: Are there references available on the Web? JC: CHECKS is at c2.com/ppr/checks.html. The whole PPR site is a treat to visit. OMO: What is your favorite software methodology? JC: I don't have any. OMO: What do you think about the UML? JC: "Here is another liability: Beautiful drawings can become ends in themselves. Often, if the drawing deceives, it is not only the viewer who is enchanted but also the maker, who is the victim of his own artifice... Alberti understood, as many architects of today do not, that the rules of drawing and the rules of building are not one and the same, and mastery of the former does not ensure success in the latter." -- Witold Rybczynski, The Most Beautiful House in the World.1 OMO: What is your favorite operating system? JC: Probably UNIX before it gained weight around release 3.0 in the early 1980s. Actually, I'm pretty happy with most operating systems named A for which a book with the title "Undocumented A" does not exist. OMO: What computer do you work on everyday? JC: I move around quite a bit. I do genealogy and all my fax management on a Powerbook 160. My portable computing environment consists largely of a Powerbook 3400c. I do most of my computing from home on a high-resolution NCD X terminal from which I connect to many Suns, Macs, SGI boxes, and a few PCs. OMO: Are you much of a Web surfer? JC: I spend quite a bit of time on the Web. I spend some time surfing, but use it more as a research tool. OMO: What would you like for Christmas? :-) JC: My old shortwave receiver just died and the manufacturer no longer stocks parts, so I'm all set to get a replacement. OMO: What is your favorite Component Model? JC: I'm not big on the whole component concept. A major tenet of the pattern community is that great systems cannot easily be built from pre-defined parts. Systems are more than the sum of their parts, and it's systems thinking or the lack thereof that makes or breaks projects. OMO: Which do you think will win out? (CORBA, DCOM, OpenDoc, Beans/RMI) JC: I think this compares apples with oranges. If you're asking what I think the dominant distributed processing protocol will be, the answer is clear: HTML. What does it have going for it? Like most successful Internet protocols that preceded it, it came from a grass-roots effort that didn't have much support from any standards body. And it's easily understood and supported by the most ubiquitous software on earth. To a first order approximation, the other stuff doesn't matter -- except for the energy wasted in deciding between them and optimizing them. OMO: On systems thinking, are you a fan of Senge or Jay Forrester? If so, do you see this work as applied to (software) system design?
JC: I'm a big fan of Peter Senge. His ideas about emergent behavior in systems parallel what one finds in the ideas of Christopher Alexander. How does his work apply to software? Software is about building systems, and it's about people. Senge understands both systems and systems of people. He understands that difficult system problems and their solutions are not close in time and space. Too many people try to take quick engineering approaches to problem-solving, when sometimes it requires much deeper thinking. I think the software community wastes a lot of energy by not understanding this, and most of the time, there's never any learning from the costly experiences that result from not understanding this. Senge offers some useful models, metaphors, and experiences that open your eyes to some important realities. My favorite book on systems thinking is perhaps Becoming a Learning Organization2 by Swieringa and Wierdsma. It's a short book that gives a fresh, honest view of how organizations can really make major structural improvements, and it's based in some great experiences at companies like Royal Dutch Shell. Another tangentially related book I'm reading right now is Finite and Infinite Games3 by James Carse. OMO: What do you think about Java? JC: I like Java as a language. It has all the signs of success: both Smalltalk and C++ claim it as their successor. But I think too many people view it too superficially. What made C++ great was its cultural compatibility with C, in addition to its object abstracting facility; Java falls short on the C compatibility end. And what made Smalltalk great was its environment; Java falls short there. Java excels in a new style of programming that requires a different way of thinking about objects and about concurrency, a style of development foreign to most programmers today. It means thinking in terms of more dynamic binding, dynamically loading classes and dynamically interacting across distributed environments. I think Java's survival as a mainstream general-purpose programming language will depend not only on the ability of the market to ultimately appreciate a true Java style (to stop writing Smalltalk or C++ in Java) and on the timely deployment of rich, general-purpose programming environments that can easily be ported to many platforms, and which provide the degree of efficiency and C-language-level integration that one finds in C++. There's no fundmanental technical obstacle to doing this, but there are market and social forces that make it difficult. I would applaud a successful effort along these lines. OMO: What do you think will come of the Microsoft/Sun debate over Java? JC: Probably endless debate. OMO: Do you think any new language constructs should be added to C++, or taken away? JC: As a practical matter at this point in history, no. Multiple inheritance and exception handling are features I don't use very much. I would like to see a serious evaluation of multiple dispatch in C++. OMO: Me too. What do you think about the C++ Standard Library? What about its function templates approach? JC: Alex Stepanov and his colleagues showed collective genius in creating this library, and had a bit of luck on their side to see their ideas dovetail so well with C++. I think it represents a major step forward in the whole concept of library development, and I don't think many appreciate that enough. The STL is a kit for building libraries, a kit that seems to factor out some key concepts that generalize very well. That generalization was the product of years and years of experience and refinement, hard work, and insight. And it paid off. OMO: Could you tell us a little about your
background in computing? I noticed you work at Bell Labs, but not in Murray Hill,
the famous site where the transistor was invented and from whence C and UNIX came.
Could you tell me a little about the facility you work at? OMO: I remember that your book, Advanced C++,4 was the first book on C++ to come out with the word "advanced" in it and so I bought it as soon as it came out. Would you say that book really covered the topic of "Advanced C++ Programming," or do you think there is much more to say on the subject? JC: It would be crazy for any author in this day and age to claim that his or her book were the final word or even a comprehensive statement on any topic; the world is just too big, and things change too fast. Nonetheless, many crucial points of effective C++ programming are underscored in Advanced C++ today, seven years into its life without a [second] edition, that one just doesn't find in many other contemporary books. Other books that aren't quite as advanced but which are major stepping stones in the same direction are Cargill's Elements of C++ Programming
OMO: What do you now consider to be the most "advanced" topics in computing today? Maybe just some of your favorites or interests would do. JC: I think the people problems are the most challenging, because those problems face one of the largest areas of ignorance in our discipline. Few software professionals have a hundredth of the training in human issues [they do] in technological issues. That's pretty strange when you consider that most software development is an intensely social activity. I think we believe that we all instinctively know how to be good people, that any of us is as expert at being a good person as anyone else. But good human interaction is hard, and the individual actions that add up to communal accomplishment are complex. It's difficult to achieve optimized levels of human interaction, yet most organizations are barely competent at vesting architectural expertise, engaging customers, and valuing domain knowledge. I have been studying this aspect of software development for the past seven years in earnest, building on the work of many great people who've gone before me, like Jerry Weinberg and Larry Constantine. It's stunning how much there is to be learned in this area, it's stunning how inept we are as an industry, and it's stunning to see the power of a few common-sense principals in overcoming the obstacles. OMO: I once gave a lecture on your book, using its advanced idioms and the like to justify an "advanced" object language that had many of the features of Smalltalk, CLOS, and C++ combined; it was called OpenL. OpenL provided first class support for many of your idioms and styles directly in the language to make them user friendly, instead of requiring the programming tricks required in conventional languages. Do you think more powerful programming languages are called for, or do you think simpler languages like C++ and Java suffice? JC: First of all, it's difficult for me to let myself be drawn into a discussion about programming languages with someone who would use the phrase "simpler languages like C++ and Java," and who would pretend that meaningful dialogue could come out of a superficial description of a language ("had many of the features of Smalltalk, CLOS, and C++ combined"). Second, it's hard to know what it means to have "first class support" for idioms. High-level languages like Java don't provide first class support for idioms like reference counting; they simply make some of the need for them completely disappear. If you optimize for "user friendly," it's hard to avoid losing something else. What did you choose to give up? Unimportant stuff like efficiency and compatibility, I'd guess. Designing a good, successful language is hard; it's hard work, and is a delicate balancing act. Few have succeeded. I hope you had fun stepping out of the editor's role to take a shot at designing this language. But I'd advise you not to give up your day job. We'll need many languages, with many facilities, for many reasons, for a long time. OMO: I agree, and apologize for being superficial. Actually, people who prefer the more powerful dynamic facilities have "efficiency" as their middle name, because that is what they spend a great deal of their time thinking about. The Chambers work on optimizing compilers with Self and later languages is an example of power with speed. I always used to say powerful features should not cost anything to those not using them (in terms of efficiency) and that the more powerful features would cost if you needed them anyway, because you'd just have to do it ad hoc by hand as the need arose or settle for an inferior model. I was thinking of features like dynamic inheritance, dynamic method dispath, and dynamic classes as idioms in your book that were either implemented or on the table (dynamic inheritance) for OpenL. We needed the power to support OO environments including an OO database, OO GUI Libs, container Libs, etc. And the combination of simplicity to users (as with multimethods) with power was quite a combination. We also had full compatibility/interfacing with C code, or we wouldn't have wasted our time, including at the structure level for data. And there were much better ways of achieving compatibility with other languages than I see out there today. I think if we sat down and had lunch together you might just like our balancing act;-) I used to think/hope that a powerful reflective language could help to solve the plethora of languages problem, but it's been a few years since I was active on the subject. But you are quite correct, balance is a way of life for programming language designers. Anyway, I'll stop talking about my previous life. But by the way, this work was in Silicon Valley for several years, many years before I became an Editor and it was my day job;-) In fact, it was during that time that I started the comp.object FAQ. I settle for being mostly an architect (and business analyst, among other roles) during the day. JC: Well, maybe next time, I'll interview you. OMO: Do you see room for any new programming languages today? JC: Computing is no longer the domain of professional programmers; it has taken on mass market dimensions and must be responsive to the needs and demands of consumers who don't think in terms of general-purpose programming languages. I think we'll see a rise in the use of application-specific languages for specific business domains. One can only hope that the same discipline that came to the best designed general-purpose languages will come to application-specific languages as well. Today's tools (compiler compilers, scanner generators, application generators, etc.) make it easy to design a language and a translator for it in an afternoon. But designing a good language is hard. This is the hard problem facing computing today: how to optimize both the intuitiveness and expressiveness of the human/machine interface -- not just in the sense of GUIs, but also in the sense of the languages we design. And, after all, we can't ignore efficiency. Even in OpenL. One approach that's "worked" is to take the union of all possible programming language features and put them together in one language, so the language is accessible to anyone who has ever programmed. (Hey, is that what you had in mind for OpenL?) That's what leads to things like Perl. But I'd hate to use Perl to teach good principles of programming. There will be new languages that rise to address these challenges in varying degrees. If you believe Richard Gabriel (and I tend to believe him) most of the successful ones will look like C, at some level. OMO: Who is Richard Gabriel and do you have a reference to his work? JC: Richard Gabriel had a big hand in the creation of the CLOS and Scheme programming languages. He was a major player in the symbolic computing arena for years. He founded Lucid, a major player in the symbolic computing market when it was in its heyday, and he was VP of engineering at ParcPlace for a while. He was one of the very early people in the OO community and was there in formative roles in the formative years of OOPSLA. And he was interested in Alexander's work and its relevance to software since the very early days of software patterns. In addition to that, he is in a rock band, is a great writer, and is finishing up his MFA in poetry (this month, I believe) at Warren Wilson College. His most recent book, Patterns of Software: Tales from the Software Community8 is a must-read for any software professional. It is thought-provoking, it is keenly critical of many aspects of our discipline, and many will find it controversial. It is also richly insightful into areas as diverse as Alexander's theory of geometric beauty and the economic theories that drive mediocrity in the software business. Dick's work has had a remarkable effect on the way I think and on the things I take an interest in. OMO: What do you think are the hot new areas in patterns? JC: I think the main challenge for the pattern community will be to start taking individual patterns from many individuals and groups, and
OMO: For people interested in patterns, can you name any contact points for groups, Web pages, or mailing lists that they can become involved in? JC: A good starting point is the Pattern home page, hillside.net/patterns/patterns.html that has pointers to most everything else you'll need. My favorite Introduction-to-Patterns page is Brad Appleton's at www.enteract.com/~bradapp/docs/patterns-intro.html . For OpenL patterns, they can contact you. OMO: I'll be waiting ;-) What is the future of patterns? JC: I hope that patterns kind of fade into the woodwork the way that objects have become second nature in mature development shops. I hope it gets to the point where the pattern form becomes a common tool for documenting architectures and other system-level concerns. Maybe, if it truly succeeds, patterns will cease to be called patterns and will be called "documentation." That would be the true sign of success. A true sign of failure will be that there
is an endless and ever-increasing stream of books with Pattern in their title. OMO: Peter Coad wrote book on object patterns9 (now in second edition), claiming patterns and strategies should be utilized right from the start when designing and coding. JC: I think that the right things to use right from the start when designing and coding are solid design principles. Many of these are timeless: coupling and cohesion, abstraction, separating policy from mechanism, etc. Object-oriented design has its own principles that build on these. Most commmonly used patterns capture exceptions to the design rules. Some times, the design rules break down. One thing that separates expert programmers from inexpert programmers is that the experts know how to handle these special cases. For example, in C++, inheritance and subtyping usually go together. So if you have class ComplexNumber, and you want class RealNumber, shouldn't you derive the latter from the former? The problem is that RealNumber inherits the representation of ComplexNumber, so it takes up more memory than you want it to. Advanced programmers know to use the handle/body idiom (or as we'd say today, expert programmers know how to use the Bridge pattern). I'm seeing a more and more common sign of inexpert programmers: they bypass the principles and jump into using the patterns, because they think that the patterns are the key to good design. So, today, there's a big problem with using patterns from the start. OMO: What do you think of the book? JC: I like Peter's idea of strategies as
a design element complementary to patterns. Peter was one of the earliest people
to bring patterns into software. But the relationship of his work to mainstream software
patterns in the vein of Alexander's work is unclear. See Stephen Berczuk's review
of the first edition of Peter's book in
Object-Oriented Systems10
-- that's about the first edition. I haven't seen the second edition. JC: I think software will become, by and large, a commodity business. Right now, competition isn't much of a factor because of vendor distributions, the breadth of software applicability, and the immaturity of the industry. That may change over the next couple of decades. For the time being, and for some time to come, there will still be areas in which deep expertise is crucial to success: large-system development, aerospace, medical computing. But those, too, will become increasingly commoditified. In telecom, we're seeing a lot of the telecom intelligence moving from the central network into local networks and smart periphery, and that may be where the telecom software business goes. That takes it out of the realm of large system development. OMO: How do you think it should go? JC: My wish is that software would sit
back and develop an identity for itself in each of its incarnations in each of the
domains it serves, and establish how it will serve the human needs of its constituency.
Software has too long been technologically focused; it's time that it refocuses on
issues of human service, human comfort, and quality of life. I mean that it should
do this in a way that infiltrates the market relationship of software-intensive endeavors,
in a way that such concerns become part of the daily dialogue of software developers.
JC: I am currently doing research in organizational structure and architecture. The most interesting organizational work I'm doing right now is looking for relationships between group makeup and group structure. We've been jump-starting a few architecture pattern mining efforts in development organizations, with one major research goal being to abstract the results into domain principles and core competencies. Last, and perhaps most interesting, we're working on a high-risk, high-payoff project that builds on Alexander's recent theory in his forthcoming book, Nature of Order. OMO: Are there plans for any new books, talks, or the like? JC: I am constantly developing new lecture material for presentation at conferences and seminars both inside Lucent and around the world. I have been giving small seminars on Alexander's Nature of Order work for the past few months. For the past four years, I've been giving talks on domain engineering techniques and what they imply for C++ implementations. Those ideas will culminate in a book from Addison-Wesley sometime near mid-1998. I've also started framing out a book on the History of Patterns, but that's a couple years down the road yet.
|