[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why would anyone want opacity?



> > 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 [...]
> 
> 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.

Thanks.  That's a good explanation.  i was reading your woodpecker
remark the wrong way around, or something.

But I guess my views on this are somewhat different.  I don't know
whether I'm still in the "real world" to not, but I've experienced the
same sort of thing, though on a somewhat smaller scale.  For instance,
code, in one part of a system written in Common Lisp, that doesn't
use the condition system.  It just writes a message to standard-
output.  (And I was almost told, at one point, not to use the
condition system, but just print a message, because "what would
you do in C?".)

So, yes, this sort of thing is annoying, expensive, and can even
put lives at risk (if the program's controlling an X-ray machine,
for instance).

But I'm inclined to put much of the blame on poor project management,
insufficient quality control, and the like.  There can be coding
standards, code reviews, and so forth, even in the real world.
And such things will be needed in any case, because the programming
language cannot force programmers to follow all of the good practices
they ought to follow.  Or at least languages don't, and no one is
proposing that they do.

What language forces programmers to use the exception system, use
the library, read the documentation?  None of the languages in
widespread use do such things, so far as I know.  And it's not our
job, as programming language designers and implementors, to
solve all of the problems of poor management, overworked and
ill-trained programmers, programmer stupidity, and so on.

None of this is an argument against having programming languages
do something about some of these problems.  If a programming
language can enforce good practice in some area, perhaps it
should.  But the point of these examples from the real world
seems to be something like this: here's a serious problem in
the real world; Scheme can do something about it; therefore
Scheme should do something about it.

(If that isn't the point, then I think it has to be made clear
that it isn't, for otherwise the misunderstanding will continue.)

But languages don't enforce every good practice that they could
enforce, and that doesn't seem to be a source of much complaint,
except in certain cases.  So evidently the reasoning that goes
from "can" to "should" doesn't always carry the day.  Nor
should it.  So we have to get down to specifics.  What are
the actual proposals for Scheme?  What are their costs and
benefits?  And if making Scheme better for large, real world,
projects in which relatively poor programmers take over
after the brilliant engineers have left makes it worse for
something else, then maybe we should not make Scheme better
in that way.  Or, if it makes it so much better, and so little
worse, maybe we should.

-- jeff