Re: Why would anyone want opacity?

[Jeff Dalton <jeff@aiai.ed.ac.uk>]

> > ...Or to protect programmers working on
> > the same project from each other somehow?
> 
> I think this is the most important thing.  Imagine a two-person
> software project in which one person is not terribly experienced.
> For concreteness, imagine a term project in a compiler construction
> course [...]
>
> It also provides an opportunity for them to see what is wrong with
> their implementation language (usually C, C++, or Scheme).  These
> languages just don't provide enough of an abstraction barrier to
> prevent representation-dependent code from being written by accident.
> That's the fault of the language, not the fault of the programmer.
> [...]

I'm not quite sure, BTW, what sort of accident you have in mind.
Is the programmer going to write "car" instead of the right
accessor, or is it something a bit more subtle, such as calling
"length" on something that isn't supposed to be treated as a
list?  Wouldn't a fairly minimal degree of opacity confine
the "language doesn't care" accidents to those of the 1st sort?
And are many programmers really going to type "car" or "vector-ref"
(or whatever the "concrete" operation is) by accident, rather than
out of some kind of misunderstanding?

> This is not just an academic concern.  In the real world, most
> programmers are less than outstanding, and many are a great deal
> less than outstanding.  In the real world, these imperfect
> programmers work on much larger systems that evolve over much
> longer periods of time than the systems we construct in academia.
> 
> We can rationalize Scheme's shortcomings by telling ourselves that
> Scheme is a language for winners, not losers, and take pride in the
> fact that so few programmers use Scheme, but I think that's a cop-out.

I understand and share such concerns, to a large extent.  But I do not
entirely agree with some of the reasoning or with what seem to be the
conclusions.

For on thing, in the real world, ensuring that good practices
are followed is not the job of the programming language.  It's
the job of quality procedures, project management, and so forth.
The programming language plays a part, and some language designers
may want their language to take on as much of the task as
possible.  But this is something language designers can take
on, by choice, as a goal.  It's not something required by the
nature of things.

Moreover, I don't know of any widely-used language that _does_
try to take on as much of the job as possible.  Do they try
to ensure that variable names are meaningful, for instance?
Typically not, and complaints on that score are few.

Instead, people say "that's the fault of the language, not the fault
of the programmer" about some things but not others.  Now, do we all
have to agree about which things are which?  Do all good languages
have to be alike in this area, on pain of no longer counting as
good?  I don't see why.

If we can have abstraction barriers at nearly no cost, then fine.
Then there's no need to disagree.  But that doesn't seem to be the
case.  After all, a number of smart, well-informed people have been
disagreeing about this for years, when it comes to Scheme.

Moreover, if the people who are worried about abstraction barriers 
are wrong -- if the barriers can be at no cost that the worriers 
would worry about -- then the way to convince them is to show
them that the costs really are that low.

I don't think anyone is rationalizing Scheme's shortcomings or
taking pride in the fact that so few programmers use Scheme
(which, so far as we know, may have little to do with the lack 
of abstraction barriers).

But some people would like there to be, in the world, some
languages of a certain kind, a kind that happens to include
Scheme.  They would there to be languages that don't _enforce_
certain good practices, because some things these programmers
find good and useful would (it seems) be prohibited as well.
And language diversity is, I would say, also good.

-- jeff