Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!bony1!richieb From: richieb@bony1.bony.com (Richard Bielak) Newsgroups: comp.object Subject: Re: The Emperor Strikes Lethe Summary: Everybody is a critic! Message-ID: <1991Apr9.175328.1288@bony1.bony.com> Date: 9 Apr 91 17:53:28 GMT References: <43.UUL1.3#913@acw.UUCP> Reply-To: richieb@bony1.UUCP (Richard Bielak) Organization: Bank of New York Lines: 178 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. |