Subject: Re: is CLOS reall OO? From: Erik Naggum <clerik@naggum.no> Date: 1998/05/05 Newsgroups: comp.lang.lisp Message-ID: <3103356827666810@naggum.no> * 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! #:Erik -- Support organized crime: use Microsoft products!