Re: Why would anyone want opacity?

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

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

i am not sure what to do with all this.

my anecdote meant to loosely support but one notion: we often need
more help out there from languages than most people realise. in the
case of the system i mentioned, something like C++ is that help, but the
management has to bite to bullet and convert. [yep, programmers tend to use
real language facilities more than plastered-on "optional" ones like the
exception system i mentioned. class libraries are harder to ignore than
a pile of library entries, and so on.] i doubt i have suggested many of the
things you seem to have derived from my post. there are more details to be
sure, but i doubt it is worthwhile to talk about them here.

[btw, if you have not read stroustrup's book on the design of C++, you
may want to. it is an interesting lesson in trying to build a language
to help programmers cope with the real world complexity and build better
programs while trying to give them the freedoms they need.]

also, my example does not imply scheme proper has to do anything. it has
basically been irrelevant to my day-to-day work for the last five years.

[which is why i will not be able to attend to this topic any further.]

bye.

oz