guthery@acw.UUCP (Scott Guthery) (04/07/91)
It's been about a year since I published "Are the Emperor's New Clothes
Object Oriented?" in Dr. Dobbs Journal. In that article I posed nine
questions that I felt had to be answered in the process of determining if OOP
was ready to be used in an engineering or product-development setting.
Here's my assessment of the current answers to these questions based on a
light reading of the OOP literature since then together with following the
various newsgroups on the subject.
1) Where's the evidence?
Some is starting to come in. OOP seems to make writing code a little easier.
It certainly gives us the opportunity once again to rewrite everything and
this means job security for programmers. About every 10 years in programming
we have to change syntax and OOP is the change for the 90's. OOP does seem
to be harder to debug, harder to test, and harder to maintain when the
maintainers are not the developers.
2) What is an object?
There seems to be general agreement on what object classes and instances
ought to be in theory but practice is something else as witness the debate
over my definition of an object. There are still a lot of new words being
invented for old ideas. An object class is a coding form or an 029 keypunch
control card and an object instance is a tab card. And, yes Virginia, tab
cards did inheritance. (What? You don't remember the 029?)
3) What's the cost of OOP code reuse?
We still don't know mainly because we're seeing about the same style and
level of reuse of OOP code as we do with non-OOP code. Everybody and his dog
has done a C++ string class. After 10 years of Objective-C there are still
just two Objective-C IC Packs. We still mostly copy source code, hack and
go. Unfortunately, there is still enough slop in the definition of the most
widely used OO language, C++, that getting one C++ compiler to accept what
another will pass is a large problem so even classical reuse is harder in OOP
land.
4) How does one combine object heirarchies?
One big hierarchy is still the only way to get objects to communicate within
the rules of the game since the whole point of hidden internal structure is
to make communication with "outsiders" impossible. On the other hand, there
are a growing number of practical work-arounds ... friend objects, neighbor
objects, significant other objects, passing acquaintance objects, etc.
5) How does one tune an OO program?
Well, the way you tune any other program. The program structure itself has
to absorb information about how it is being used. Since OO programs are
bigger and slower because so much of the development scaffolding is left in
the runtime image more of this usage information has to be put into the
program. Thus, the complexity of the program increases due to programmer
laziness. Of course, since increased complexity means more programmers and
job security for existing programmers the reward for this laziness is
continued employment. Nice scam.
6) How does one manage an OOP development team?
Very carefully and very closely. Since adding new code to an OO system can
change the behavior of (i.e. break) old code every programmer essentially
needs to know the whole system in order to add code to it. This is
particularly the case if polymorphism is used since each programmer has to
understand and build on the puns being perpetrated by all the others.
7) Do OO programs coexist?
Nope ... C++ objects can't inherit from Eiffel objects; Loops objects can't
inherit from Smalltalk objects. Each OO technology is a programing bunker
world unto itself. This is true in practice only, of course. In theory the
world is always exactly as we wish it to be.
8) What are the consequences of persistent state?
Mostly it makes testing a lot harder and a lot more unreliable since every
possible combination of retained state must be checked. But then, heck, an
object-oriented program is so clean and clear that we don't really need to
test it so who cares how hard it is, right? Have you heard of the Parnas
test?
9) Can you get the development system out of the production system?
Nope. The uniform response of the OO community to the runtime overhead
problem is "buy a bigger machine" or, in translation, "the hardware guys will
have to save our butts again". It seems to come as a shock to OO programmers
that the folks buying these machines expect to be the beneficiaries of the
hardware curve not the programmers ... afterall it's their money. People who
buy cmoputer to solve their problems don't expect the curve to be eaten up
(and then some!) by having to constantly slog through leftover
development-time scaffolding. (Do you know what happens to surgeons who
leave the tools of their trade inside their patients?) OOP imposes a runtime
tax that end-users aren't interested in paying even with weak excuse that the
tax pays for more frequent updates since it makes maintenance easier.
End-users don't want more frequent updates; they want it right in the first
place.
The OO community will be forced to discover that software consumers won't pay
development-time taxes at runtime the same way the Lisp community did. If
you write your product in some OO language, I'll come out with a competing
product in written C or maybe even assembler, give all those cycles back to
the customer, and whip you in the marketplace. I might thank you for
defining the product and opening the market which I understand you did by
using OO technology. But a thank you and a cloud of dust is all you'll get.
In closing, I note that a non-upward compatible version of the most popular
OO language, C++, is due out "real soon now". After 11 years of trying C++
still doesn't have a stable semantics. This, more than anything else,
convinces me that OOP still isn't ready for production use ... unless, of
course, your boss still thinks paying her programmers for constantly changing
the syntax of her code is progress.
There is very little really new in OOP. As I indicated above, classes,
instances, and inheritance go back to tab card decks of the 1940's. Lexical
scoping was used in Algol in the 1950's. Polymorphism is found in Fortran 0.
Even decomposition by type, which Piercarlo Grandi says is the basic idea of
OO, can be found in the programming language, database, and graphics
literature of the 1960's.
The question we really have to ask ourselves is why are we constantly
reinventing the wheel? Why do we imagine that making up new names for old
problems is progress? Why don't we get tired of reading the same dreary
articles and going to the same windy conferences? Why is the collective
memory of applied computer science so short? Only when we can answer this
question will programming start to make some real progress.
Cheers, Scott
+*+*+*+*+*+*+*+*+*+*+*+*+ Austin Code Works +*+*+*+*+*+*+*+*+*+*+*+*+*+*+**+*+
NET Domain: guthery@uunet.uu.net Post: 11100 Leafwood Lane
COM Domain: guthery@acw.com Austin, Texas 78750-3464 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 Fidonet: 1:382/12
Packet: N5MDE @ KB5PM Prodigy: BCDG83A
+*+*+*+*+*+*+*+*+*+*+*+*+* The Source of C +*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+*+aew@eosvcr.wimsey.bc.ca (Alan Walford) (04/08/91)
>From: guthery@acw.UUCP (Scott Guthery) writes many obviously flaming things ... [stuff deleted] > 5) How does one tune an OO program? > >Well, the way you tune any other program. The program structure itself has >to absorb information about how it is being used. Since OO programs are >bigger and slower because so much of the development scaffolding is left in >the runtime image more of this usage information has to be put into the >program. Thus, the complexity of the program increases due to programmer >laziness. Of course, since increased complexity means more programmers and >job security for existing programmers the reward for this laziness is >continued employment. Nice scam. [stuff deleted] >9) Can you get the development system out of the production system? > >Nope. The uniform response of the OO community to the runtime overhead >problem is "buy a bigger machine" or, in translation, "the hardware guys will >have to save our butts again". It seems to come as a shock to OO programmers >that the folks buying these machines expect to be the beneficiaries of the >hardware curve not the programmers ... afterall it's their money. People who >buy cmoputer to solve their problems don't expect the curve to be eaten up >(and then some!) by having to constantly slog through leftover >development-time scaffolding. (Do you know what happens to surgeons who >leave the tools of their trade inside their patients?) OOP imposes a runtime >tax that end-users aren't interested in paying even with weak excuse that the >tax pays for more frequent updates since it makes maintenance easier. >End-users don't want more frequent updates; they want it right in the first >place. >The OO community will be forced to discover that software consumers won't pay >development-time taxes at runtime the same way the Lisp community did. If >you write your product in some OO language, I'll come out with a competing >product in written C or maybe even assembler, give all those cycles back to >the customer, and whip you in the marketplace. I might thank you for >defining the product and opening the market which I understand you did by >using OO technology. But a thank you and a cloud of dust is all you'll get. For my $0.02 worth. I just finished a major rewrite of a complex piece of code that was written in C. The program is called a bundle adjustment and is used in survey engineering. I rewrote in C++ using many OO concepts and virtual functions etc. I fully expected it to be much slower than the previous version but I was willing to put up with the slow down knowing I would have a better structured and more understandable program. Well, what do you know, it was over TWICE AS FAST. Yes, faster not slower. Goes to show you that if you write good code in any language whether OO or not it can be efficient. > Cheers, Scott Cheers to you to, Alan -------- Alan Walford aew@eosvcr.wimsey.bc.ca Eos Systems Inc.
tatem@csc.ti.com (Joe Tatem) (04/09/91)
In article <43.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes: >OOP does seem >to be harder to debug, harder to test, and harder to maintain when the >maintainers are not the developers. I would like to go on record saying that this statement, in my experience, is simply not true. Having spent a large part of my professional life working on other people's code, I have found my life to be much easier since I began working on object-oriented systems. Things are not perfect. Programmer discipline still goes a long way. But I at least have a better idea of where to look for things. Joe Tatem --
hsrender@happy.colorado.edu (04/09/91)
In article <43.UUL1.3#913@acw.UUCP>, guthery@acw.UUCP (Scott Guthery) writes: > It's been about a year since I published "Are the Emperor's New Clothes > Object Oriented?" in Dr. Dobbs Journal. In that article I posed nine > questions that I felt had to be answered in the process of determining if OOP > was ready to be used in an engineering or product-development setting. > Here's my assessment of the current answers to these questions based on a > light reading of the OOP literature since then together with following the > various newsgroups on the subject. First off, let me say that although I think skepticism is a good thing, you seem to be predisposed to reject OO ideas. The only way to determine whether something is really useful in any setting is to use it in that setting. One of the problems with making any advances in software development in our country seems to be the overwhelming opposition to any new (or even recycled) idea or technique. Your article is an example of this. Anyway, a couple of observations on your questions: > 1) Where's the evidence? > > Some is starting to come in. OOP seems to make writing code a little easier. > It certainly gives us the opportunity once again to rewrite everything and > this means job security for programmers. About every 10 years in programming > we have to change syntax and OOP is the change for the 90's. OOP does seem > to be harder to debug, harder to test, and harder to maintain when the > maintainers are not the developers. OOP is not just a change in syntax, it is an attempt to incorporate support for things that people do anyway: reuse code, encapsulate implementation, build concept hierarchies, etc. Whether it is done well depends on the subject and the language/method being considered. Speaking of evidence, where's the evidence that OO programs are harder to debug and test? In my own limited experience, I've found Smalltalk code to be easier to test, debug, and maintain than C code. > 2) What is an object? > > There seems to be general agreement on what object classes and instances > ought to be in theory but practice is something else as witness the debate > over my definition of an object. There are still a lot of new words being > invented for old ideas. An object class is a coding form or an 029 keypunch > control card and an object instance is a tab card. And, yes Virginia, tab > cards did inheritance. (What? You don't remember the 029?) Maybe it's because I'm a relative youngster (I've only been programming for 10 years) but I don't know what a coding form is, or a 029 control card, or a tab card. I started programming on punch cards but left them behind back in '82. Regardless, the fact that there is ongoing debate on the definition of object and other terms does nothing to belittle the value of OO thinking. When all is said and done, any computation can be encoded in machine language (or for the theoretically minded, on a Turing machine), but the development of new abstractions is a result of attempting to come up with more comprehensible explanations of things people already do/talk about. In short, if "class" is more intuitive term than "coding template" for the same thing, then I think we ought to use "class". > 3) What's the cost of OOP code reuse? > > We still don't know mainly because we're seeing about the same style and > level of reuse of OOP code as we do with non-OOP code. Everybody and his dog > has done a C++ string class. After 10 years of Objective-C there are still > just two Objective-C IC Packs. We still mostly copy source code, hack and > go. Unfortunately, there is still enough slop in the definition of the most > widely used OO language, C++, that getting one C++ compiler to accept what > another will pass is a large problem so even classical reuse is harder in OOP > land. This is a shuck. Every language I've ever programmed in (and I quit counting after 12) has been subject to the whims of compiler vendors. Even Ada, with it's much heralded standard, was subsetted extensively back when I was checking out Ada compilers in '85. As for the levels of reuse currently employed, just because we haven't been monstrously successful doesn't mean it's not easier to do in an OOPL. I know that the NIH C++ library is widely used, and I hear that the GNU C++ libraries have been used by many who aren't worried about the copyleft. Whether it is easier to do than in a "conventional" PL depends mostly on the packaging constructs available in the language. I find modules and classes easier to reuse than subroutines. Is this subjective? Yes. > 4) How does one combine object heirarchies? > > One big hierarchy is still the only way to get objects to communicate within > the rules of the game since the whole point of hidden internal structure is > to make communication with "outsiders" impossible. On the other hand, there > are a growing number of practical work-arounds ... friend objects, neighbor > objects, significant other objects, passing acquaintance objects, etc. Either you're not expressing yourself well, or you don't know what you're talking about. One puts things into a class hierarchy to share definition and implementation details (the coder's point of view) and to denote conceptual relationships between kinds of objects (the designer's point of view). No OO language that I know of forces you to put things in the same hierarchy just so that they can interact (unless you are thinking of languages like Smalltalk where every class is descended from class Object--this is not a limitation in any way that I know). BTW, the whole point of hidden internal structure is not the make communication impossible, just to restrict to a set of monitored paths. This is the same principle of putting an interface on a module. Are you saying that I can't use a module unless I have knowledge of it's interior? If so, I'd go look at the early papers on modular programming. You seem to be unclear on the concept. > 5) How does one tune an OO program? > > Well, the way you tune any other program. The program structure itself has > to absorb information about how it is being used. Since OO programs are > bigger and slower because so much of the development scaffolding is left in > the runtime image more of this usage information has to be put into the > program. Thus, the complexity of the program increases due to programmer > laziness. Of course, since increased complexity means more programmers and > job security for existing programmers the reward for this laziness is > continued employment. Nice scam. The way you tune a program is by figuring out what it has to do and figuring out the most efficient way of doing that in the language you are using. You are right that this is the same for an OOPL as for a conventional PL. You are also right that OO programs may be slower due to the additional stuff that the translator leaves in the load image. However, this is true of any language where the compiler does more than that of a conventional language. Take a look at the runtime support required of LISP, PROLOG, SNOBOL, Icon and a few other unconventional languages. Each one of these is easier to program in than, say, FORTRAN, because each has features designed to make the programmer's job easier by making the translator do more. Does this make the load image bigger? You betcha. Does it make the program more complex? Not from the programmer's viewpoint. Does it make it harder to tune? You betcha, for the same reason that it is easier to tune assembler than it is to tune FORTRAN code. > 6) How does one manage an OOP development team? > > Very carefully and very closely. Since adding new code to an OO system can > change the behavior of (i.e. break) old code every programmer essentially > needs to know the whole system in order to add code to it. This is > particularly the case if polymorphism is used since each programmer has to > understand and build on the puns being perpetrated by all the others. Another shuck. A programmer is only likely to "break" an OO system if s/he redefines existing code. This is true for conventional systems as well. Changing an instance method (or member function) is just as likely to break a system as changing a subroutine in a FORTRAN library. The only major difference is that the method may be inherited by other classes, so the change may be automatically propagated to other parts of the system. This is a problem, but it is also the reason people are investigating ways to track/restrict inheritance paths. In general, the configuration management problems are the same. As for polymorphism being particularly nasty, this is only true insofar as polymorphic code is likely to be widely used, and any error introduced into that code is thus like to be widely propagated. However, because the error need only be corrected in only one place, the fix can also be widely propagated. So is this bad? > 7) Do OO programs coexist? > > Nope ... C++ objects can't inherit from Eiffel objects; Loops objects can't > inherit from Smalltalk objects. Each OO technology is a programing bunker > world unto itself. This is true in practice only, of course. In theory the > world is always exactly as we wish it to be. Since when is this a unique problem of OO code? Linking code written in different languages has always been troublesome. Because of the greater runtime support of most OOPLs the problem may become greater, but I don't think of it as inherent to the OO paradigm. > 8) What are the consequences of persistent state? > > Mostly it makes testing a lot harder and a lot more unreliable since every > possible combination of retained state must be checked. But then, heck, an > object-oriented program is so clean and clear that we don't really need to > test it so who cares how hard it is, right? Have you heard of the Parnas > test? Wrong. Given that the methods of an object control access to the variables, one need only test methods to determine if there is an invalid combination. Although this is difficult, this is no more difficult than testing a FORTRAN program that has several global variables and subroutines for manipulating their values. In fact, it is considerably less difficult (in my opinion) in an OO because access is limited absolutely to the methods associated with the containing class. (Actually, this depends on the language and the program, since some languages allow instance variables to be accessed like regular record fields). > 9) Can you get the development system out of the production system? > > Nope. The uniform response of the OO community to the runtime overhead > problem is "buy a bigger machine" or, in translation, "the hardware guys will > have to save our butts again". It seems to come as a shock to OO programmers > that the folks buying these machines expect to be the beneficiaries of the > hardware curve not the programmers ... afterall it's their money. People who > buy cmoputer to solve their problems don't expect the curve to be eaten up > (and then some!) by having to constantly slog through leftover > development-time scaffolding. (Do you know what happens to surgeons who > leave the tools of their trade inside their patients?) OOP imposes a runtime > tax that end-users aren't interested in paying even with weak excuse that the > tax pays for more frequent updates since it makes maintenance easier. > End-users don't want more frequent updates; they want it right in the first > place. This is a semi-valid point. OO langs do require greater runtime support. For this reason it makes more sense to use them during prototyping when ease of coding outweighs performance. People are trying to reduce the runtime overhead of OOPLs like Smalltalk, but I have doubts that they will make a Smalltalk program as fast as an equivalent program in C (although I have had people tell me otherwise). Still, if the performance loss is small enough, coding ease (and associated decreases in the program under- standing phase of maintenance) may make it more cost effective to use a OOPL rather than a language like C or FORTRAN. > The OO community will be forced to discover that software consumers won't pay > development-time taxes at runtime the same way the Lisp community did. If > you write your product in some OO language, I'll come out with a competing > product in written C or maybe even assembler, give all those cycles back to > the customer, and whip you in the marketplace. I might thank you for > defining the product and opening the market which I understand you did by > using OO technology. But a thank you and a cloud of dust is all you'll get. Again, the use of OOPLs for production code will depend on the improvement in runtime performance. This is nothing new, as the same thing has been true of LISP. However, LISP is still around (after 30-odd years), so if you think this shortcoming of OOPLs will doom them then you are misleading yourself. > > In closing, I note that a non-upward compatible version of the most popular > OO language, C++, is due out "real soon now". After 11 years of trying C++ > still doesn't have a stable semantics. This, more than anything else, > convinces me that OOP still isn't ready for production use ... unless, of > course, your boss still thinks paying her programmers for constantly changing > the syntax of her code is progress. It may have been 11 years since C++ first began to be developed, but its only been 5-6 years since it began to be used much outside of Bell Labs (at least that I know). This is a fairly short period of time, much shorter than the span of time it normally takes for a language to become widely used in industry. The fact that it is still evolving is nothing new, since FORTRAN is still evolving. Does this mean it will not be used? Unlikely, for the same reason FORTRAN and other evolving languages have continued to be used despite variant implementations and changing standards. > There is very little really new in OOP. As I indicated above, classes, > instances, and inheritance go back to tab card decks of the 1940's. Lexical > scoping was used in Algol in the 1950's. Polymorphism is found in Fortran 0. > Even decomposition by type, which Piercarlo Grandi says is the basic idea of > OO, can be found in the programming language, database, and graphics > literature of the 1960's. > > The question we really have to ask ourselves is why are we constantly > reinventing the wheel? Why do we imagine that making up new names for old > problems is progress? Why don't we get tired of reading the same dreary > articles and going to the same windy conferences? Why is the collective > memory of applied computer science so short? Only when we can answer this > question will programming start to make some real progress. Although nothing in OOPLs is radically new, the combination of these features in a coherent fashion is. I've programmed in a number of languages, and all of them are unique in some way, even if it is merely syntactic. Yes, there are common constructs and ideas, and yes, there is a lot of reinventing going on, but it is all due to a quest for the "perfect" programming language. Most "new" things are merely new arrangements or combinations of existing ideas, expressed in a better (one hopes) fashion. Programming languages, like natural languages, evolve due to changes in their user groups. To believe that this is a problem is to say that, at any time, what we have is good enough. Although this may be true, it is not something I think you will ever demonstrate to many people. hal. univ. of colorado at colorado springs render@zeppo.colorado.edu
ram+@cs.cmu.edu (Rob MacLachlan) (04/09/91)
>From: guthery@acw.UUCP (Scott Guthery) >Newsgroups: comp.object >Subject: The Emperor Strikes Lethe >Date: 7 Apr 91 16:56:40 GMT > >The OO community will be forced to discover that software consumers won't pay >development-time taxes at runtime the same way the Lisp community did. Hmmn, being a Lisp system developer, refresh my memory of what we discovered? Although some Lisp hackers may have dreamed of displacing all other programming languages, it has always been the case that what Lisp systems excelled at was research and prototyping. >If >you write your product in some OO language, I'll come out with a competing >product in written C or maybe even assembler, give all those cycles back to >the customer, and whip you in the marketplace. I might thank you for >defining the product and opening the market which I understand you did by >using OO technology. But a thank you and a cloud of dust is all you'll get. > Well, I guess I can't expect too much gratitude. But you seem to be half-acknowledging that resource-intensive programming systems may have a productive role in research and development. Mass market programs will always be written at a lower level (and with more hand-tuning) than limited market programs or prototypes. This is because the mass market justifies spending more effort in programming. Rob
paj@mrcu (Paul Johnson) (04/09/91)
In article <43.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes: [Brief summary of events wrt his `Doctor Dobbs' article] >1) Where's the evidence? > >Some is starting to come in. OOP seems to make writing code a little easier. >It certainly gives us the opportunity once again to rewrite everything and >this means job security for programmers. About every 10 years in programming >we have to change syntax and OOP is the change for the 90's. OOP does seem >to be harder to debug, harder to test, and harder to maintain when the >maintainers are not the developers. Umm. Can you provide references? How was complexity measured? One of the points made earlier on this group is that SLOC seems to stay constant across languages. The difference is that a given problem seems to need fewer SLOC in an OOPL than in conventional code and that changes in the OOP version are easier. You say we have to "change syntax" about once every 10 years. I assume the previous changes were HLLs and structured programming. Do you write everything in assembler? Fortran? Do you feel that HLLs and structured programming have not been useful? Maybe this change will be useful as well. >2) What is an object? > >There seems to be general agreement on what object classes and instances >ought to be in theory but practice is something else as witness the debate >over my definition of an object. There are still a lot of new words being >invented for old ideas. An object class is a coding form or an 029 keypunch >control card and an object instance is a tab card. And, yes Virginia, tab >cards did inheritance. (What? You don't remember the 029?) I think the argument was more on what your term `lexical closure' meant (don't you know what it means? Down the pub, we talk about nothing else...) In the OO paradigm, classes inherit, not instances, so I cannot see that your tab card analogy is meaningful. Anyway, we are talking about describing behaviour here. All you are saying is that objects are partly data structures and data structures are not new, which we know. >3) What's the cost of OOP code reuse? > >We still don't know mainly because we're seeing about the same style and >level of reuse of OOP code as we do with non-OOP code. Everybody and his dog >has done a C++ string class. After 10 years of Objective-C there are still >just two Objective-C IC Packs. We still mostly copy source code, hack and >go. Unfortunately, there is still enough slop in the definition of the most >widely used OO language, C++, that getting one C++ compiler to accept what >another will pass is a large problem so even classical reuse is harder in OOP >land. This is because C++ is a brain damaged language. Go look at Eiffel or Smalltalk. Objective-C I do not know about. Its used a lot less than C++, so there is probably not much call for new IC packs. I expect that companies using Objective-C have reused their own code though. You may case-and-paste source code, I do not. I gave that up when I started OOP. >4) How does one combine object heirarchies? > >One big hierarchy is still the only way to get objects to communicate within >the rules of the game since the whole point of hidden internal structure is >to make communication with "outsiders" impossible. On the other hand, there >are a growing number of practical work-arounds ... friend objects, neighbor >objects, significant other objects, passing acquaintance objects, etc. How do you mean "combine object heirarchies"? Are you complaining that OOP languages do not let you break encapsulation? Sure, thats the idea and it is a Good Thing because it reduces complexity. If that is not what you are complaining about, then what is it? What do you want to do? If you want generics and multiple inheritance then go look at Eiffel (yes, I am an Eiffel partisan) >5) How does one tune an OO program? > >Well, the way you tune any other program. The program structure itself has >to absorb information about how it is being used. Since OO programs are >bigger and slower because so much of the development scaffolding is left in >the runtime image more of this usage information has to be put into the >program. Thus, the complexity of the program increases due to programmer >laziness. Of course, since increased complexity means more programmers and >job security for existing programmers the reward for this laziness is >continued employment. Nice scam. Hang on a minute, what "increased complexity"? Where did that come from? You seem to be saying that because OOPLs "keep development scaffolding" in place (and hence provide flexibility and avoid complicating the program itself with details), tuning requires more hard-coded details in the source of the program. Surely not. A structured language program would have those details hard-coded into the program in the first place (rather than in the `scaffolding'). Fine if the designer has guessed right when specifying performance enhancing details, but bad if s/he guessed wrong. >6) How does one manage an OOP development team? > >Very carefully and very closely. Since adding new code to an OO system can >change the behavior of (i.e. break) old code every programmer essentially >needs to know the whole system in order to add code to it. This is >particularly the case if polymorphism is used since each programmer has to >understand and build on the puns being perpetrated by all the others. "Very carefully and very closely" i.e. the same as ever (see the TOOLS 91 on Hewlett-Packards experiences with OOP). "...every programmer essentially needs to know the whole system..." WRONG. That is what we are getting away from. When using a class, one only needs to know its interface (can you say "encapsulation is a good thing"?). When creating a new class by inheritance one only needs to know about its ancestors. As long as the new class honours the old classes interfaces, polymorphism is safe (Meyer's concept of Software Contracting). >7) Do OO programs coexist? > >Nope ... C++ objects can't inherit from Eiffel objects; Loops objects can't >inherit from Smalltalk objects. Each OO technology is a programing bunker >world unto itself. This is true in practice only, of course. In theory the >world is always exactly as we wish it to be. No, not even in theory. We knew that. So what? Most languages (interpreted ones such as Smalltalk mostly excepted) have C language interfaces). If you REALLY need to do it, you can build wrappers around the modules in the other language and carry on from there. If you have a class library in a given language and want to enhance it, it is better to do it in that language. Of course, you can always use the existing libraries in other languages via C language interfaces, although it is certainly not easy or clean. How is this worse that existing systems? Ever tried using X from Pascal? >8) What are the consequences of persistent state? > >Mostly it makes testing a lot harder and a lot more unreliable since every >possible combination of retained state must be checked. But then, heck, an >object-oriented program is so clean and clear that we don't really need to >test it so who cares how hard it is, right? Have you heard of the Parnas >test? No, I have not heard of the Parnas test. Why is this a problem? All non-trivial computer programs have state, and it is necessary to work through a large number of state transitions to test them properly (it would be nice to test every possible combination of existing state, but I want to finish before the heat death of the Universe). Persistent state does not change any of this, it just means that the programmer does not have to design, write, test and debug code which saves and restores data structures. >9) Can you get the development system out of the production system? > >Nope. The uniform response of the OO community to the runtime overhead >problem is "buy a bigger machine" or, in translation, "the hardware guys will >have to save our butts again". It seems to come as a shock to OO programmers >that the folks buying these machines expect to be the beneficiaries of the >hardware curve not the programmers ... afterall it's their money. People who >buy cmoputer to solve their problems don't expect the curve to be eaten up >(and then some!) by having to constantly slog through leftover >development-time scaffolding. (Do you know what happens to surgeons who >leave the tools of their trade inside their patients?) OOP imposes a runtime >tax that end-users aren't interested in paying even with weak excuse that the >tax pays for more frequent updates since it makes maintenance easier. >End-users don't want more frequent updates; they want it right in the first >place. Actually, it depends on the language. C++ has no development system overhead apart from virtual functions which are not optimised out of the run-time system. Smalltalk is an interpreted language for prototyping, so this is not a problem. Eiffel is currently in between but improving. Note that while with C++ the language is improving, in Eiffel the implementation is improving. There is no reason why one day Eiffel-generated C code should not be as tense as hand-coded C. >The OO community will be forced to discover that software consumers won't pay >development-time taxes at runtime the same way the Lisp community did. If >you write your product in some OO language, I'll come out with a competing >product in written C or maybe even assembler, give all those cycles back to >the customer, and whip you in the marketplace. I might thank you for >defining the product and opening the market which I understand you did by >using OO technology. But a thank you and a cloud of dust is all you'll get. It depends on the application. For large volume apps on PCs you have a point. Hand-coded C can be made more efficient than Eiffel-generated C at present. That will change. For small volume stuff, the extra cost of coding in C or assembler makes it cheaper to buy more computer. If your high speed assembler product costs 10-100 times as much as my Eiffel product but runs only twice as fast, people might well buy mine, especially if they only run it a couple of times a day. >In closing, I note that a non-upward compatible version of the most popular >OO language, C++, is due out "real soon now". After 11 years of trying C++ >still doesn't have a stable semantics. This, more than anything else, >convinces me that OOP still isn't ready for production use ... unless, of >course, your boss still thinks paying her programmers for constantly changing >the syntax of her code is progress. Like I said earlier, C++ is brain-damaged. Do not tar all OOPLs with the same brush. An improved version of Eiffel is also due out "real soon now". Most of the changes will be syntactic improvements and a script will be provided to convert from Eiffel 2 to Eiffel 3. >There is very little really new in OOP. As I indicated above, classes, >instances, and inheritance go back to tab card decks of the 1940's. Lexical >scoping was used in Algol in the 1950's. Polymorphism is found in Fortran 0. >Even decomposition by type, which Piercarlo Grandi says is the basic idea of >OO, can be found in the programming language, database, and graphics >literature of the 1960's. Simula 67 was the first generally available OOPL (I think). Sure, we know its not new. The recognition that these techniques are of general use is new. See the interview with Meyer in one of the back issues of JOOP. I will ignore that bit about card decks, since I already pointed out the fallacy. OOP is a paradigm shift. As such it subsumes existing paradigms (such as structured programming and functional decomposition). It does not replace them. We still need programmers, but OOP will make those programmers more productive. [Final paragraph of rhetorical questions deleted]. Paul. -- Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj --------------------------------!-------------------------|------------------- GEC-Marconi Research is not | Telex: 995016 GECRES G | Tel: +44 245 73331 responsible for my opinions. | Inet: paj@gec-mrc.co.uk | Fax: +44 245 75244
richieb@bony1.bony.com (Richard Bielak) (04/10/91)
In article <43.UUL1.3#913@acw.UUCP> guthery@acw.UUCP (Scott Guthery) writes: [...] >1) Where's the evidence? > >OOP does seem to be harder to debug, harder to test, and harder to >maintain when the maintainers are not the developers. I've been doing some programming in Eiffel, and I find OOP programs a lot easier to test, maintain and debug. Have you got any statistics supporting your claim? >2) What is an object? [...] We can argue about definitions until we're both blue in the face. How about defining a "program" or a "module"? You'll find just as much controversy discussing these terms as you would with "object". Eg: Is "module" a runtime or a compile object (pun intended). In practice, I prefer the Eiffel approach, where an "object" is the runtime thing that holds data and code, and a "class" is a compile time thing. Lack of definition doesn't stop me from coding. > >3) What's the cost of OOP code reuse? > >We still don't know mainly because we're seeing about the same style and >level of reuse of OOP code as we do with non-OOP code. Everybody and his dog >has done a C++ string class. [...] The class libraries provided with Eiffel relieve me from writing a lot of code that I would normally have to do in conventional languages. For example, I will never write a STRING class in Eiffel, or a class to handle linked lists, and many other data structures. Isn't this code re-use? > >4) How does one combine object hierarchies? > >One big hierarchy is still the only way to get objects to communicate within >the rules of the game since the whole point of hidden internal structure is >to make communication with "outsiders" impossible. Not impossible! Just controlled. Objects can ask politely to see each other's private parts :-). >On the other hand, there >are a growing number of practical work-arounds ... friend objects, neighbor >objects, significant other objects, passing acquaintance objects, ^^^^^^^^^^^^^^^^^^^^^^^^^ That's really cute :-). >5) How does one tune an OO program? > >Well, the way you tune any other program. The program structure itself has >to absorb information about how it is being used. Since OO programs are >bigger and slower because so much of the development scaffolding is left in >the runtime image more of this usage information has to be put into the >program. What "development scaffolding"? What are you talking about? Examples, please! >6) How does one manage an OOP development team? > >Very carefully and very closely. Since adding new code to an OO system can >change the behavior of (i.e. break) old code every programmer essentially >needs to know the whole system in order to add code to it. [...] As though adding new code to a system written in C does not change the behavior (i.e. break) the old code. Come on! > >7) Do OO programs coexist? > >Nope ... C++ objects can't inherit from Eiffel objects; Loops objects can't >inherit from Smalltalk objects. Can "C" include COBOL includes? How about PASCAL or ADA? Eiffel and C++ objects can "send message" to each other. > >8) What are the consequences of persistent state? > >Mostly it makes testing a lot harder and a lot more unreliable since every >possible combination of retained state must be checked. Most programs that perform useful task must retain some "persistant state" - i.e. some global data. With OOP at least this data is localized to a class (or module if you prefer). Modular programming (such as in Ada or Modula-2) "suffers" from the same problem. > >9) Can you get the development system out of the production system? > [...] >development-time scaffolding. I still don't know what you mean by "develoment-time scaffolding". >OOP imposes a runtime >tax that end-users aren't interested in paying even with weak excuse that the >tax pays for more frequent updates since it makes maintenance easier. >End-users don't want more frequent updates; they want it right in the first >place. Some users are also interested in software that is reliable. I think that reliability and correctness should come first. What use is speed if the results are wrong! I think OOP allows programmers to write more reliable software. [...] >I'll come out with a competing >product in written C or maybe even assembler, give all those cycles back to >the customer, and whip you in the marketplace. I might thank you for >defining the product and opening the market which I understand you did by >using OO technology. But a thank you and a cloud of dust is all you'll get. > Perhaps your C/assembler package will be 10 times as fast as my OOP program. However, you'll spent 10 times as much time developing it, while I can move ahead to new products. Also, my package will cost 1/10th of yours. So the user can buy my package and with the extra money he can buy more memory and a faster CPUs. >In closing, I note that a non-upward compatible version of the most popular >OO language, C++, is due out "real soon now". After 11 years of trying C++ [...] I don't like C++ either, But please don't condemn the field based on one yucky language. >There is very little really new in OOP. As I indicated above, classes, >instances, and inheritance go back to tab card decks of the 1940's. Lexical >scoping was used in Algol in the 1950's. Polymorphism is found in Fortran 0. >Even decomposition by type, which Piercarlo Grandi says is the basic idea of >OO, can be found in the programming language, database, and graphics >literature of the 1960's. It's the combination of these ideas that is important. You can probably argue that Charles Babbagge (sp?) was writing object-oriented programs :-). [...] > Cheers, Scott IMHO object-oriented programming is an important idea. The existing approaches to OOP may not be perfect, but they show promise. Your arguments remind me of those who cried "I will never stop using GOTO! I can write more effient programs using GOTOs! PASCAL? Never!" ...richie -- *-----------------------------------------------------------------------------* | Richie Bielak (212)-815-3072 | Programs are like baby squirrels. Once | | Internet: richieb@bony.com | you pick one up and handle it, you can't | | Bang: uunet!bony1!richieb | put it back. The mother won't feed it. |
cjeffery@cs.arizona.edu (Clinton Jeffery) (04/11/91)
OK, OK, we've had enough mature, adult responses to Scott Guthery's striking dismissal of the entire OO kingdom! Now let's hear a medley of responses at the same same intellectual level as the original post! << Playground-Rap version >> OO programming suits me fine (but Scott doesn't get it)! Nyeah, Nyeah, Nyeah Nyeah, Nyeah! My Inheritance is better than thine (but Scott, you don't get it!) Nyeah, Nyeah, Nyeah Nyeah, Nyeah! << Country version >> Looking for OO in all da wrong places, you're just looking for OO... << Pop Insect version >> Lose C in the sky with Emeralds... << Classical version >> Dum, dum dum, dum dum dum dum dum dum... <<OK, so there was only so far I could push this idea. Wanna make a video?>> At any rate, Scott, there are too many strikingly different OO languages out there for you to get us to dismiss them so easily. I get the impression you only know the boring garden-variety ones like C++ and SmallTalk. Give them (and all the others) the 30 YEARS that FORTRAN and LISP have had to get the implementations tuned beyond belief, and those of us who live that long will see how it turns out. Oh yeah, and in response to your "Cheers"---Twin Peaks to you, babe! -- | Clint Jeffery, U. of Arizona Dept. of Computer Science | cjeffery@cs.arizona.edu -or- {noao allegra}!arizona!cjeffery --
rick@cua.cary.ibm.com (Rick DeNatale) (04/12/91)
In article <890@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: > >No, not even in theory. We knew that. So what? Most languages >(interpreted ones such as Smalltalk mostly excepted) have C language >interfaces). If you REALLY need to do it, you can build wrappers >around the modules in the other language and carry on from there. If >you have a class library in a given language and want to enhance it, >it is better to do it in that language. > >Of course, you can always use the existing libraries in other >languages via C language interfaces, although it is certainly not easy >or clean. How is this worse that existing systems? Ever tried using >X from Pascal? ... >... Smalltalk is an interpreted language for >prototyping, so this is not a problem. Remember, there aren't such things as interpreted languages, or compiled languages. There are implementations of most languages (Smalltalk included) using both techniques. Digitalk's Smalltalk/V PM for example, is a fully compiled (yes Virginia, it does generate machine code directly from your source) implementation. Smalltalk/V for windows compiles to byte codes which are interpreted (as do the other flavors of Digitalk Smalltalk). ParcPlace uses a hybrid dynamic compilation technique which caches dynamically compiled machine code to trade off a little speed for space. As far as C language interfaces, Digitalk provides a very nice and easy to use C interface in both Smalltalk/V PM and Smalltalk/V Windows. So even this isn't an issue of compilers vs. interpreters. Finally, yes, conventional wisdom is that Smalltalk is for prototyping, but as Scott Knaster so nicely pointed out "conventional wisdom is often wrong." Smalltalk has been used for production and commercial software. If you ever get a chance to hear someone like Dave Thomas of Object Technology Inc., or Reed Phillips of Knowledge Systems Corporation speak about their experiences with using Smalltalk in the real world, I'd recommend it. Dave gives a good talk that is often titled "You can't do that with Smalltalk". Reed has had several experiences where "prototypes" went into production after a KSC client had mistaken beliefs about performance, robustness, or something else that goes bump in the night corrected. Smalltalk has certainly had to overcome as much mythology based on its early implementations as Eiffel has. Rick DeNatale Of course my opinions are my own, who else would want them?
klimas@iccgcc.decnet.ab.com (04/13/91)
In article <43.UUL1.3#913@acw.UUCP>, guthery@acw.UUCP (Scott Guthery) writes:
a lot of misinformed opinion about oops. I just returned from
the International Programmable Controls Conference in Detroit
where I saw several OOPS based products (including at least
two Smalltalk based) on display, ready for sale. These applications
were running on general purpose comodity PC's and are intended for
high reliability applications. Market forces also dictate that
these products run faster and more reliably than their existing
counterparts to be successful. I would suggest that there is a
disturbing disconnect between market reality and many of the points
Mr Guthery has made. klimas@iccgcc.decnet.ab.com (04/19/91)
In article <1991Apr12.144951.13507@cua.cary.ibm.com>, rick@cua.cary.ibm.com (Rick DeNatale) writes: > In article <890@puck.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: >> > Finally, yes, conventional wisdom is that Smalltalk is for prototyping, but > as Scott Knaster so nicely pointed out "conventional wisdom is often wrong." > Smalltalk has been used for production and commercial software. If you ever > get a chance to hear someone like Dave Thomas of Object Technology Inc., or > Reed Phillips of Knowledge Systems Corporation speak about their experiences > with using Smalltalk in the real world, I'd recommend it. Dave gives a good > talk that is often titled "You can't do that with Smalltalk". Reed has had > several experiences where "prototypes" went into production after a KSC > client had mistaken beliefs about performance, robustness, or something else > that goes bump in the night corrected. > > Smalltalk has certainly had to overcome as much mythology based on its early > implementations as Eiffel has. > > Rick DeNatale > Of course my opinions are my own, who else would want them? Some commercial products for mass market consumption have been very successfully developed under Smalltalk (Digitalk's) db Publisher Anderson Foundation Case Tools Wycash portfolio analyzer Nevisis? banking package HP's Network Analyzer Also there have been previous postings on comp.lang.smalltalk that people have seen Smalltalk/V-PM walk back windows during early demos of IBM's Office Vision.