Re: if oo programming is the roman numerals of computing why add it?

["Randy Brukardt" <randy@rrsoftware.com>]

"Adam Beneschan" <adam@irvine.com> wrote in message 
news:a27b527a-1bbc-4b20-a22c-035cdf152fdd@googlegroups.com...
On Tuesday, July 9, 2013 12:14:05 PM UTC-7, Georg Bauhaus wrote:

>> Luca Cardelli's article, featured on the page, has many comments
>> in favor of O-O, provided a language gets it right. If you read the
>> article, you will notice that Ada's style of O-O is very much like
>> Cardelli suggests it should be.

>I read "Pitfalls of Object-Oriented Programming" (linked on the page) 
>yesterday,
>and it seems his argument delves into details like memory cacheing and 
>branch
>prediction.  This was a big yawner for me.  My feeling has always been that 
>if
>you take all the extra nanoseconds that good programming techniques 
>sometimes
>cause, you can add up all the wasted time that occurs every time the 
>program has
>been run, anywhere in the world, maybe millions of times, and it still 
>won't nearly
>add up to the time that would be wasted trying to track down one difficult 
>bug
>caused by bad programming practice.

>Then again, the author was from Sony Entertainment, so I can understand why 
>perhaps
>every nanosecond might be important.  Still, a good compilation system 
>could, in
>theory, make up for the time wastage that O-O or other good programming
>techniques could cause.  The need to break programs up into smaller 
>subroutines
>and modules has been recognized for 30 or 40 years, but this can lead to 
>small
>inefficiencies when code has to contain CALL instructions instead of 
>executing
>the subroutine inline.  I suspect that people back then objected to this 
>important
>technique for that reason.  But compilers are now able to rearrange the 
>code to
>eliminate the inefficiency.  I think similar optimizations can be done for 
>O-O
>techniques.  If you have an abstract type A, but the compiler can determine 
>that
>the only objects in A'Class (using Ada terminology, but I mean this to 
>apply to
>any language) used in the entire program all have type B, then a compiler 
>could,
>in theory, rearrange the code to avoid the overhead that a dispatching call 
>on one
>of A's operations would entail.  That's just one possibility; there should 
>be others.
> Don't know if any existing compiler (for any language) goes this far.

Janus/Ada uses a similar technique to eliminate the extra space overhead 
caused by OOP. We track down which routines are never called in a 
dispatching call and remove those from the tags, so that the dead subprogram 
eliminator that's built-into our binder can remove the subprograms. (It 
reduced the size of typical Claw programs by about 800K.)

Since we concentrated on space rather than time issues, we never made any 
attempt to improve the call overhead, but clearly a similar technique could 
be used for that. (It's a bit harder, as flow analysis would be needed.)

                                        Randy.