RE: Is OO a deliberate fraud?

[tjoccam@xxxxxxxxxxx]

> Larry,
>
>> > The side-effect free stuff is all very well, but it can
>> > lead to very cluttered code and also, potentially, very
>> > inefficient code.
>> Cluttered, maybe, but I don't see why it has to be
>> inefficient --- the channel just gets copied into a local
>> variable, surely... And I really don't even see cluttered.
>> The HOSTIO and STREAMIO code in the occam toolset never
>> impressed me as cluttered, but it used a global channel
>> of just the sort I'm thinking of.
>
> It's ineffecient because for every call you make you've got
> to fetch the parameters from the global/local location and
> put it in the appropriate place for the calling convention
> being used - typically a register, sometimes a stack; in
> the array and variable-checked occam style you might
> also have to do one or more array accesses and also range
> check array references.
>
> So for a two parameter (in & out) channel bundle we've got between 2
> (two globals to register) and 8 (checked array access using
> a variable index) independent memory accesses per call in
> overhead. Now, in graphics code where you're interested
> in good performance, that is a significant issue.
>
> If you postulate that the API call you're making actually
> uses those channels inside internal routines that do the
> drawing, you're multiplying
> that cost up; probably 2 or 3 accesses per call.
>
> In academia raw performance might not matter; in industry
> it most certainly does.

What you are forgetting, Ruth, is that in industry one does not code every
single microscopic action by a call. Often one uses inline "calls" but
they aren't really calls (and they use local variables not the heavy stuff
you described). Even loops get unfolded. We did this in occam (and C and
assembly) all the time. Thus your 2 to 8 accesses only happen once in
(say) a panel refresh, which would require thousands of writes to graphics
memory. Therefore the 2 to 8 accesses fade into insignificance (less than
1%), ESPECIALLY compared to the problems on the other side:
unresponsiveness due to incapability of reliable unbuffered channel
communication (requiring timeout delays to ensure completeness of the job
--- these get nested and hidden in real code, resulting in delays of whole
seconds); clumsy failsafes due to unreliability of the code; real
microscopic calls forced by the OO method structure, etc. All this clears
up when code gets transparent, and only then.

>
>> > In can make it hard to maintain.
>> Were HOSTIO and STREAMIO hard to maintain?
>
> IME, Yes.

There I have to disagree completely. We must not compare HOSTIO and
STREAMIO with some ideal standard, but with the real world as it exists
today: thousands of incompatible drivers, dozens of languages and OSs each
of which can't even be fit into a doorstop-sized manual anymore, but
requires half a bookshelf to describe. And all of them so laden with side
effects that you dare not code anything except by modifying someone else's
"path through the minefield" very carefully.

Nobody with a bank account smaller than Microsoft's can support this kind
of interfacing. I contend, very strongly, that a path back to HOSTIO and
STREAMIO would be worth literally billions of dollars, not to mention the
sanity of thousands of programmers who are now burning out.

What do the rest of you think?

Larry Dickson

>
> Regards,
>
> Ruth
>
>
>