* Aaron Gross
| I think you're giving C++ a bum rap here. The class definitions are
| conventionally put in .h files which the user has access to. Thus a user
| can easily change private data to public.
well, yeah, at the cost of a system recompile, and you have be _very_
careful not to change the order of the members as C++ is so ill-designed
as to require memory layout to follow specification order. technically,
you can use the access specifier in front of every individual member, but
people tend to sort the members based on access rights. in particular, I
have never seen code in any textbook on C++ where the access specifier is
repeated or applied specifically to an individual member -- they are
always used only once, as sort of "headers", and the message is clear
from other sources, as well: don't _do_ that. so I'd say that a whole
culture is speaking against your "just change it" policy.
| Stroustrup emphasized in _The C++ Language_ that the "private" keyword is
| meant to protect against *unintentional* trespassing, and that it doesn't
| do anything to stop a programmer from knowingly modifying private data.
I don't think this can be true. I would, however, have believed it if
access violations were specified to be warnings, not the errors they are.
I have helped salvage a project where people "knew" the layout of C++
classes and were afraid to change the .h files because that would mean
many a lost day due to recompiling, so "knowingly modify private data"
through the wonders of pointer arithmetic and casting is such as horribly
bad "solution" to the problem that I would consider asking the police to
put a detail on programmers who do it -- they're likely to break the law
through blatant disregard in real life, too.
| So the correct analogy would be a fence around the house with a gate that
| was closed, but not locked.
really? this sounds more like you're on Bjarne's defense team than an
honest argument. how do you open the gate and get at something inside?
your analogy strongly implies that there is a mechanism to open gates,
but what you actually have to do is go away elsewhere and declare the
object to outside your gate, then rebuild the world so it is. when your
gate doesn't have an "open" method, who cares whether it's locked or not
as long as you have to tear the whole fence down to pass through it?
| Regarding your claim that CLOS's policy of trust is OK, it seems the most
| obvious and convincing argument for a new CLOS programmer would be
| empirical: "In my experience developing and maintaining x amount of CLOS
| code, I've never seen a problem caused by this policy."
this is a good point. I must have designed and implemented 20 times as
many classes in CLOS as I have in C++, but I have always had some sort of
problems with the access rights in C++ as uses and designs change over
time, and I have _never_ had any desire to control access in CLOS. now,
I don't claim to be typical. for more than a year after first exposed to
C++ in a six-month project, I was actively considering another career
because C++ was becoming the required language and I couldn't stomach the
monumental waste of human resources that this language requires of its
users and projects. the problem is not just one of pragmatics, however.
C++ is philosophically and cognitively unsound as it forces a violation
of all known epistemological processes on the programmer. as a language,
it requires you to specify in great detail what you do not know in order
to obtain the experience necessary to learn it. C++ has taken premature
optimization to the level of divine edict since it _cannot_ be vague in
the way the state of the system necessarily is. (I'm not talking about
totally vague, but about the kind of vague details that programmers are
supposed to figure out even after a good design has been drawn up.) in
other words, a C++ programmer is _required_ by language design to express
certainty where there _cannot_ be any. a C++ programmer who cares about
correctness is a contradiction in terms: correctness is a function of
acquired certainty, not random guesswork. I'm discounting the ability to
experiment with something through educated guesses, because the number of
issues that must be experimented with in this fashion is gargantuan in
any non-trivial piece of code. C++ is a language strongly optimized for
liars and people who go by guesswork and ignorance. I cannot live with
this. I especially cannot live with it when I cannot even ask for help
in maintaining the uncertainty I have. e.g., if I do not have enough
foreknowledge to know _exactly_ which type I need for a variable (and
there is no type hierarchy, so I cannot be vague), I must _guess_, which
is bad enough, but I have to _repeat_ the guess all over! I cannot say
"this thing here has the _same_ type as that thing over there, and I'd
rather you go look there because I just want to put down my guesses once"
-- there is no `typeof' operator and it certainlycannot be used in those
anal-retentive declarations to afford a limited form of type propagation.
I actually think C++ is ideal only for programmers without any ethics.
you must lie, you are encouraged to declare your private stuff and keep
the cards very closely to your breast, but if you need access, you just
go ahead and change other people's class definitions. the "improved"
strong typing is designed to cause errors if you make simple mistakes,
forcing you to use a lot more of your brain on remembering silly stuff,
but then you get to templates and all hell breaks loose because suddenly
you have _no_control_at_all_ over where things fly. when I wrote that
C++ and CLOS is a question of what kind of people you wish to live with
in your community, I was not _just_ making an analogy. one can only
imagine what having to lie to your compiler _every_ day and to make
unwarranted guesses that your colleagues will depend on the same way they
depend on your hard-earned knowledge _does_ to a human brain -- I know I
couldn't handle even the prospect of it.
and, no, the solution is _not_ to design everything on paper first, then
implement, although this is the way that C++ would actually have worked
out well -- if it were _possible_ to design like that in our world. all
experience has taught us that solving a complex problem uncovers hidden
assumptions and ever more knowledge, trade-offs that we didn't anticipate
but which can make the difference between meeting a deadline and going
into research mode for a year, etc. if C++ were used only to solve
_known_ problems with _known_ solutions, it would be a perfectly OK
language. smart people would design classes "once and for all" and sell
them like nuts and bolts, companies could pre-fabricate parts that fit
together because of industry consensus on standards and specifications,
and this age-old "dream" of some software engineers. I believe this is a
completely insane view of programming, but C++ cannot have any other --
it is _designed_ to be an "ex post facto language" -- most bad languages
are, because the desire to make things solid and predictable, especially
if they can never be, is so deeply ingrained in people they have to work
hard with the concept of dynamism. so people are now arguing in terms of
"patterns", _new_ code that conforms to "general design principles", and
which consequently doesn't fit with the other parts unless specially
designed to. more and more, people see that solving _any_ problem is a
question of acquiring knowledge and having respect for the cognitive and
epistemological processes involved in the human brain: use what you know,
learn what you can, and if you have to guess, be _aware_ that you do so
you can go back and update your guesses when you (hopefully) learn more.
do I give C++ a bum rap? I may well do, but I hope I can illuminate what
choice of language does to the human cognitive process: people who come
from the C++ camp are positively obsessed with protecting their data --
even to the point of being scared when they can't. are they paranoid? I
think have _become_ paranoid because C++ makes you go nuts if you don't
-- it's a natural, psychological defense mechanism against criminally bad
language design: the flip side of having to feign certainty about your
guesses is that you lose confidence in your real certainty, too. when
anything you decided in the past can be overturned without warning just
because some other random guesswork somewhere turnes out to be false, you
learn to be defensive. C++ _needs_ encapsulation and all this privacy
stuff because the whole language is _systematically_ and _fundamentally_
sloppy, and thus attract programmers (and managers) who don't care one
way or the other about it. but, hey, the very _existence_ of Microsoft
would have been _impossible_ without systematic and pervasive sloppiness,
carelessness and outright lies, so it's kinda hard to argue against those
vices with people who _only_ want a quick buck (which is a vice on its
own, if you ask me).
perhaps I care too much, but I found that I needed to get out of the C++
world _permanently_, and I only turn back to look and study to know mine
enemy. in order to think about difficult and interesting problems, I had
to find languages (and write tools) that allowed me _not_ to think about
all the idiotic problems that C++ forces on everybody, _swamping_ their
cognitive processes and creativity with meaningless minutiae that they
have to lie about to boot. I have succeeded because I knew _exactly_
what I needed to get away from, but that knowledge didn't come for free:
for a few years I was sustaining myself mostly as a writer instead of a
programmer simply because I couldn't do anything worthwhile until I had
figured out why C++ is so rotten, and just _how_ (initially unfathomably)
rotten it really is: C++ turns otherwise good people into paranoid,
insecure prostitutes, and it comes from creating such horrible living
environments for themselves and compounded by trying to explain to
themselves that "it's OK, really". (of course, if you don't think about
such things and never need to explain anything to yourself, if you are of
the kind who "just follow orders", C++ is probably OK for you, which
leads to another label for C++: assembly-line object-oriented language.)
end of rant. happy Lisp hacking!
Support organized crime: use Microsoft products!