Re: Why would anyone want opacity?

[Guillermo J. Rozas <gjr@martigny.ai.mit.edu>]

|   Cc: wand@ccs.neu.edu, jeff@aiai.ed.ac.uk, will@ccs.neu.edu,
|	   rrrs-authors@martigny.ai.mit.edu
|   Date: Wed, 08 May 96 22:33:38 -0400
|   From: "ozan s. yigit" <oz@nexus.yorku.ca>

|   in the "..." part, he said:
|
|   how did this become a position that implies "such access should be
|   disallowed (rather than strongly discouraged and unlikely to happen
|   accidentally)" all of a sudden?

Perhaps I'm reading him too narrowly, but that's what I read in

|   | 1.  It would be desirable for the language to detect violations of an
|   | abstraction boundary.  

At any rate, since the author of the sentence is still alive, and
furthermore, reading this list, lets not quibble about what he meant
to say (we clearly interpreted it differently), and let him clarify it
if he feels so inclined.

|   is it impossible to build a language which can switch between
|   detecting abstraction violations, warns and allows them [for the
|   purpose of constructing these important "generic" tools] and detecting
|   such violation and disallows them? i think that is what mitch was
|   saying. have i read him too generously? :-|

An implementation yes, a language, I'm not sure.

To me a language is all about expressive power and ability.
Coding conventions, checking compilers, etc. are tools that projects
may or may not decide to use.

The same thing happens with English.  You can say all sorts of things,
but in a legal document you are more constrained, because a subset
with particular constraints and interpretations is expected.

As language designers we could build all sorts of checking into the
language, but they might be ignored (e.g. by Fortran-style programmers
who use arrays/vectors for everything).  In addition all sorts of
coding standards that people use in practice (e.g. the "Hungarian"
variable naming convention) would not be helped in any way.

I view these requirements to mandate checking in the language as no
sillier than mandating such variable naming conventions.  Let those
people who have particular constraints and restrictions tailor their
implementations and tools to fulfill them.  

I guess the real difference is that I do not view at all our job as
making the _task of programming/coding effectively_ easier, but
instead as making the _task of thinking about processes and
algorithms_ easier.  This is a clear corollary of really believeing
that the primary purpose of a programming language is to communicate
between humans precise process development information, and only
incidentally to make computers carry out some actions.

Strong checking of types and abstractions may (I don't believe
it but I won't be as adamant) help train effective coders and keep
them "on the good path".  I am quite certain that it just gets in the
way of _thinking_ about processes and algorithms.  When there is a
conflict, you know which way I will choose.

There are far too many languages that purport to make effective coding
easier and we've all seen where they've taken us.  I'd rather train
thinkers who can learn skills than skilled idiot savants who can't think.