Prof David West wrote: > If pressed into a corner, I would say that C++ is not an OO language at > all - because the philosophy behind its creation is antithetical in > important ways to the IDEA of objects. Computer architecture people (mostly the people that work on mainstream compilers) tend to work from the hardware up, understanding the subtle and important details of code generation on hardware utilization, whereas computer scientists tend to create languages that only occasionally can be optimized effectively on existing architectures, but have other appealing attributes besides performance.
Ironically, C++ implementors are faced with language constructs that hurt performance as much as they help. Without pointers, it's easier to identify objects that are untouched in a call hierarchy and prove they are constant and thereby factor those calculations outside of loops. This is not to say that languages like Smalltalk don't introduce their own problems. Dynamic message dispatch, besides involving a non-zero computation, can do a fine job of confusing branch prediction, and stalling the CPU's pipeline of instructions. In contrast, C++ member functions can be inlined to their caller. The main problem I have with languages that are more concerned with ideas than performance, is that they never seem to manage provide the programmer with an transparent model of how the language will map to hardware. Without that, it means either 1) the compiler can generate excellent code in a completely automatic way 2) putting the burden on the programmer to have a full model of the implementation and the architecture, in which case of course the programmer can make fast code. It also assumes that the programmer is basically a language implementor, which is a pretty big demand 3) forcing the programmer to drop down to a lower level language for performance (which taints the beauty of the main code and also assumes the programmer knows how to use the lower level language) 4) tolerating up to an order of magnitude performance penalty In the Lisp community, the approach was mostly #2. Nowadays, say with Java, #3 and #4 are the main approaches (#4 just because computers are so fast now). I don't think anyone has really succeeded in #1 yet, except in specialized domains. Marcus ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
