Re: Why would anyone want opacity?

["ozan s. yigit" <oz@nexus.yorku.ca>]

> I've thought about that for a while now, and I'm afraid I still
> don't see why the brilliant engineers lose;

because brilliant engineers come and go.

i used to not think about it, until i had to work with a ~1m lines of
C/++/etc code for a [xxxxxxxx] system. the brilliant engineers who did the
foundations were gone; they had left behind an 800-page document for the
libraries, an exception system, a memory subsystem that checked for
consistency, a complete tracing system, a communication subsystem etc.
[i am omitting some details for reasons of confidentiality.]

almost all of the failures of the system were directly tracable to the
twenty-to thirty percent written by people who ignored the exception system, 
the memory manager [which was "fixed" so it no longer complained about
certain violations at runtime] the style, the incredible library, and could
not be bothered to read the documentation to find that they did not have
to write their own stupid little string parsing routines, and timer
routines etc... regression tests? what regression tests?

it was a relevelation to me. real world works with different constraints
altogether. advisory stuff does not work. options are ignored; you can ask
people until you are blue in the face to read the damned warnings from
gcc -Wall, and they will remove -Wall instead!

i could write pages about this. but i'd rather not. it is better experienced
than told. and i certainly do not feel like arguing about it. it is just an
anecdote from the real world.

>			... and it's not quite
> clear what the metaphor is supposed to be.

do not lose sleep over it. it is something to do with the way we engineer
things and the first woodpecker that comes along to destroy civilisation.

oz