Bad Engineering Properties Of Oo Languages
Bad Engineering Properties Of Oo LanguagesAn investigation by LucaCardelli into how well ProgrammingLanguages of today that support/enforce/encourage ObjectOrientedProgramming serve as tools for SoftwareEngineering.
http://research.microsoft.com/Users/luca/Papers/BadPropertiesOfOO.html (this URL no longer works. Perhaps http://doc.cat-v.org/programming/bad_properties_of_OO is a good substitute).
This page might serve as a reference and an index for a referential framework on various controversial topics on OO systems and languages. The paper was written in 1996 and hasn't been updated. Either it doesn't need updating just yet... or it is very much outdated. Read this page and decide for yourself.
The following properties are discussed:
That's because CPUs and brains work differently. The closer the language is to the CPU, the harder it is to use for humans, but the faster it runs/compiles. It should be possible to work up a compromise. For example, have your team work primarily in a high-level language, profile the executable and have one person who really knows something like C rewrite the bottlenecks.
I would discount the first two "metrics." It really doesn't matter how fast the program executes or compiles, what matters is how fast it needs to execute and compile. The truth is improvements in hardware have made these two issues immaterial. I think it is extremely rare that language selection makes a noticeable difference in either execution or compilation speed.
This idea comes up again and again, but this is the first time I've seen someone (correctly) observe that what matters is how fast your code has to compile and/or execute. While it may be true that in most fields the improvement in raw hardware speeds has made the argument/issue moot, but in others the simple truth is that it hasn't. In my field I want to run calculations that will currently take (optimistically) about 10000 years on existing hardware, so I run small cases, profile, optimise, choose good languages, and in essence do everything I can to get the results soonest. This sometimes means writing in assembler, sometimes writing in high-level language, and mixing systems for best effect. The first two "metrics" are very important to my work. For me, both EconomyOfExecution and EconomyOfCompilation? border on critical.
Some talk about "real-time software" or "large scale numerical simulations" to claim that speed is important, but of themselves these don't imply the need for raw speed. It's combinations of factors, and although they are rare they really do exist. Those who suffer from lack of speed need to realise just how small their minority is, and those who don't need to realise they just because they are the majority, others do exist.
I've seen these same arguments applied to software vs. hardware, microcode vs. assembly, C vs. assembly, and lately C++ vs. C. The point is that increases in processing capability have made these arguments moot, usually we are only arguing over how many idle loops the machine runs in a day.
Claiming that the arguments are moot, but then qualifying your reply with "usually we are ..." is a little misleading, although I'm sure you didn't intend it that way. Large-scale weather simulations, for example, are an important case where idle loops rarely get a look in, and there are enough cycles in a day.
Some people seem to think that OO is actually a good fit to numerical simulations. See http://oonumerics.org/.
I think the point was that EconomyOfExecution does matter.
Exactly. My code often has runtimes of weeks-to-months. Even a factor of 2 can hurt a lot!
If I had code like that, I'd be concerned about performance too. Have you profiled it to find out where the real bottlenecks are? (There's a nice story about performance and profiling in one of the pages that recount C3 history. Anyone remember where that was?)
Even in long running CPU bound programs, only a small portion of each program is performance-critical. In most applications, ease of maintenance trumps local optimization by orders of magnitude because it's more feasible to switch to better algorithms in the more maintainable program. However, there are still some rare cases that test the limits of what current technology can do. In those rare cases, the tradeoffs are pushed to unusual extremes. -- jtg
Using object representation and object identity for a large number of data items is, of course, very expensive in allocation times and memory usage.
A "manager" or "data block" object, however, can provide an efficient and elegant way to store and operate on its data items, by maintaining an internal array.
This means data items are not first class objects within the system; they must be addressed or identified by additional address specifiers within the manager.
Most advantages of OO remain available, including subclassing and interfacing of storage implementations and operation algorithms. These are applied to the "manager" or operations using the manager, rather than to a "data item" class.
Bitmap.setPixel(int x, int y, int aValue) and String.setChar(int index, char aChar) would be common examples of the approach.
''In my field I want to run calculations that will currently take (optimistically) about 10000 years on existing hardware ...''
Then why are you choosing to try and solve this problem with software? If the above is a true statement, changing languages or development methods would not help. You should consider going to dedicated hardware to solve your problem. If you are not doing so, I would say that "Development Cost" is your overriding constraint and not "EconomyOfExecution."
I think the only "bad" priniciple I have seen is the push for absolute encapsulation. I have seen too many instances where one class needs to dump out all of its member variables and pass them to another class. Ideally, the two classes should be merged to maintain encapsulation, but the pragmatics of sharing data between modules, programs, and systems often preclude this. -- WayneMack
You said it. My own problems are when someone decided that this property may not be set for some subclass. The following does not work:
form1.add(form2)or
form2.parent = form1I've taken to calling the underlying API myself.
The "BadEngineeringPropertiesOfOoLanguages" page name implies a far more generic statement than the body of the page. Perhaps we're talking about OoIssuesInLargeComputeBoundApps??
The title of the page is the name of an article (see above).
See Also: ArgumentsAgainstOop
EditText of this page
(last edited October 18, 2011)
or FindPage with title or text search