An investigation by LucaCardelli
into how well ProgrammingLanguage
s of today that support/enforce/encourage ObjectOrientedProgramming
serve as tools for SoftwareEngineering
(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:
- EconomyOfExecution. How fast does a program run?
- EconomyOfCompilation?. How long does it take to go from sources to executables?
- EconomyOfSmallScaleDevelopment?. How hard must an individual programmer work?
- EconomyOfLargeScaleDevelopment?. How hard must a team of programmers work?
- EconomyOfLanguageFeatures?. How hard is it to learn or use a programming language?
When considering current languages, it is hard to find one that has all of these desirable properties.
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
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
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
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:
form2.parent = form1
I've taken to calling the underlying API myself.
" 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