Re: ~"Smalltalk is so confusing it's as bad as HYPERTEXT!~"

[Michael McClary <michael>]

> When I program using standard procedural C, I spend a fair amount of
> time on little performance hacks, shaving every little bit of execution time
> off of my functions, and generally exalting efficiency over structure (but
> not to too much of an extreme).
> 
> Now, however, fresh from "Structure and Interpretation", I find myself in
> the midst of a classification frenzy, freely classing and subclassing away
> all of my old parameters in exchange for a robust set of messages that
> respect good modularity boundaries.

Interesting.  My programming style has been interface-regularity-driven
for a very long time, though I've been using only procedural languages
until recently.

There are some performance things I do, but I only do the ones that "roll
off my fingers", not those that take a lot of attention.  (I do them mainly
because they're ALSO structurally clean.)  If something turns out on testing
to be a time or space hog, or is guaranteed to be significant (like interrupts-
off sections in system guts, which must be checked for violations of latency
requirements) THEN I spend a little time looking at it.  But the combination
of Knuth's law of software time and McClary's rule of CPU speed says time
spent on speed-ups BEFORE instrumenting a running system is wasted, and
experience has not shown me an exception.  And (Gregory's?) law of programmer
effort says anything that doesn't change the O(rder) is probably wasted, too.

> How much overhead gets introduced in all of this classing and subclassing?
> Are there significant differences in the approaches taken by C++ and, say,
> Object C?

While I can't speak to the others, in AT&T C++ an extra level of subclassing
(with the member function inherited) costs zilch.  Doing things in another
member function instead of directly costs a subroutine call (double-indirect),
unless the member function is "inline" (in which case it should be zilch again).
Making a member function "virtual" (i.e. overridable according to the actual
subclass used) prevents using inline code, and thus forces the subroutine-
linkage overhead.

	michael