[FRIAM] O'Reilly -- The History of Programming Languages

[Marcus G. Daniels]

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