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

[Ravi Pandya <ravi>]

Date: Mon, 12 Mar 90 17:08:54 PST
   From: bobp (Bob Perez)

   .... the
   real problem was that OOP makes it EASY to be sloppy. I suppose a lot of the
   early MacApp users weren't disciplined object programmers (even though I bet
   a lot of them were efficiency junkies in their prior lives). And the result
   was a lot of slow, sloppy programs.

To some extent, OOP does make it easy to be sloppy about time and
space, because the atomic operations can be more expensive (message
send vs. procedure call, for example). More importantly, though, OOP
emphasizes modularity and structure over efficiency. A lot of
efficiency can be had by violating modularity boundaries, by making
assumptions about what lies on the other side of an interface.
Furthermore, relative efficiency is usually not specified in the
interface contract to a module, so that it is often difficult to know
what is efficient use of a module and what isn't. Finally, efficiency
can be modularized in non-obvious ways, like the adaptive splay trees
in the ent.

All this complex information is typically more than one can keep in
mind while writing code, so that it is difficult to design code with
efficiency in mind. On the other hand, OOP systems allow you to do a
lot of post hoc performance tuning without affecting client code, such
as the caches that we plan to build into the FM-Manipulator-Ent
connection.

   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?
   -- bobp 

To the extent that types are known at compile time, you can speed
things up a lot in C++ by using inlines and a good optimizing
compiler. I don't know much about Objective-C, but I think that it is
more runtime oriented, so it can't do that kind of optimization.
	--ravi