Subject: Re: is CLOS reall OO?
From: Erik Naggum <>
Date: 1998/05/05
Newsgroups: comp.lang.lisp
Message-ID: <>

* 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!