Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!dcl-cs!aber-cs!odin!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.lang.c++ Subject: Re: Is this legal? Message-ID: Date: 31 Jul 90 12:51:38 GMT References: <10164@odin.corp.sgi.com> <11062@alice.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 181 In-reply-to: bs@alice.UUCP's message of 18 Jul 90 16:12:16 GMT "bs" == Bjarne Stroustrup writes: bs> In article 8852 Piercarlo Grandi @ Coleg Prifysgol Cymru writes: pcg> Let me repeat here my usual tirade about the difference in attitude pcg> between European (algorithmic language) and USA (programming language) pcg> ideas of the role of programs and languages: pcg> Programs for Europeans are there to communicate the pcg> implementation of an algorithm, either to programmatic pcg> (e.g. compilers, pretty printers, verifiers) or human (even pcg> more important!) readers. As such it should be as clear and pcg> unambiguous as possible, and as informative as it can be without pcg> becoming hard to read because of verbosity. pcg> The USA position is that programs are there to drive a pcg> computer to perform a task, and as long as they "work", who pcg> cares... bs> This kind of tirade is somewhere between unhelpful and dangerous. It is bs> a wild generalization that reinforces prejudices and thus allow people bs> (on BOTH sides of the `divide') to feel superior and avoid learning from bs> experience. Hey! Gross generalizations are of course dangerous, but maybe not unhelpful. This one, in particular, is at least of historical relevance; there has been an historical divide and loads of prejudices on both sides of the Atlantic, and this has been most obvious in the diverse fortunes of the languages of the algorithmic family, not to mention in standards committees everywhere. As an aside: we still see that in communications, but there the positions are reversed: European PTTs pressing for the bag of tricks approach, and Americans for the building block one. Too bad the bag (actually truckload) of tricks has prevalied there as well. bs> Had the generalization been made about your favorite `minority bs> group' rather than the unprotected species of `American programmers' and bs> `European programmers' it would have been recognized as utter bad taste bs> and an inditement to further antisocial behaviour (and probably been bs> illegal under the paternalistic laws of the US and UK). This is a very bizarre statement; I know several people that would not find not offensive at all being characterized as giving more importance to "making things work", rather than "communicating algorithms". Maybe *you* have a prejudice in this sense :-). I would quote Hilbert (leave elegance to tailors) or Stallman (on GCC) as people that belong proudly to the "making things work" camp. bs> Back to programming languages: bs> (I deliberately use `programming language' rather than `algorithmic bs> language' here following what I consider common English Academic bs> usage - in my case learned at Cambridge (UK). Maybe. But I understand that people shed blod at Cambridge (and Manchester, and Amsterdam, and elesewhere) twenty years ago in the trenches of the great battle to uphold the "algorithmic language" banner. The battle has been lost, and so the distinction has been buried, but let's honor its heroes by not forgetting what it was fought about. :-) :-). bs> I also feel that bs> `algorithmic languages' places an undue emphasis on the computational bs> aspect of programs at the expense of structural aspects: We are bs> after all considering the general issues in the context of a bs> language that supports object-oriented programming. `Algorithmic bs> languages' is appropriate for Algol and Fortran, but maybe less so bs> for C++ and Smalltalk.) Sorry, but we are totally out of synch here: Fortran is emphatically not an algorithmic language. C++ instead is IMNHO definitely an algorithmic language. The divide is between languages as notations to express algorithms, and languages as collections of convenient linguistic forms and tools. For example, even if strictly "algorithmic language" should be reserved historically for members of the Algol family of languages (to which both Simula 67 and C++ belong by right of birth, even if they are both OO), it could be applied with clean semantics to Smalltalk, Lisp, ML; while programming languages are Fortran, Cobol, PL/1, PERL. Maybe you are swayed by the fact that the ancestor, Algol 60, was procedural decomposition oriented, which is not however essential to being an algorithmic language; its immediate successor, Algol 68, definitely still an "algorithmic language" in any sense of the word (but for formats, let me sadly add), had all structuring facilities you could wish (except for scope barriers), not to mention again Simula 67, which is a strict superset of Algol 60, yet an OO language. bs> I clearly think that Piercarlo's characterization of programming bs> languages is inappropriate. A programming language serves BOTH as a bs> means of communication between programmers and between programmers bs> and machines. We are still out synch here. As long as you describe a language as a means of communication, either with machines or humans, you belong firmly in the "algorithmic language" camp. The "programming language" fans believe that what you want is a collection of suitable linguistic tools or idioms with which to give orders to to accomplish a task, as opposed to describing an algorithm for communication. Incidentally, that is why I am so insistent that a compiler has no business rewriting the logic of a program, at least for a low level algorithmic language; the description should be heeded closely by the compiler. "programming language" people instead think that only the effect matters, not the way the algorithm is expressed, so are very happy with an optimiser that rearranges the logic of their programs, as if they had been expressed in an higher level language. This is also why I recommend putting explicit storage class and scope indicators in C++ programs, even if technically redundant; making the description more precise is, to me, important, even if it does not affect the translator-wise semantics of the program. bs> There is no simple solution, no holy grail, no silver bullet, so let bs> us cut the preaching, posturing and labeling, and get on with the bs> hard work of trying to figure out more reasonable and more bs> manageable ways of designing, constructing, testing, tuning, bs> documenting, and maintaining systems. It is so much harder being bs> constructive than simply to criticize. Yup, truly. :-). But to warn that things are not as luminous as they are purported to be is terribly useful. A false sense of security is the greatest hazard. :-). bs> Further, back to C++ (this is comp.lang.c++ after all): C++ is bs> designed to be both an effective medium for human to computer bs> communication (that is primarily the `C part') and an effective bs> medium for human to human communication (that is primarily the `++ bs> part'). So it is an "algorithmic language" after all. Other symptoms: providing meachanisms to build idioms, instead of providing them directly (relegating IO and tasking to libraries, for example), which is part of the C legacy as much as the attention to simplicity (but what about constructors and destructors then? :-/). bs> Naturally, like every other language, C++ is not perfect, but at bs> least some of the tradeoffs in this particular area have proven bs> successful over a wide range of applications and programming bs> cultures. Here we are back to our discussion: C++ (which I like to read as "C + extensions + classes) as an extension to C is wonderful. It is difficult to find fault with any of the non OO extensions to C, they are orthogonal and highly economical, and give real value at little or no cost (and in areas where Ansi C and C++ overlap and differ, it is apparent that C++ was done The Right Way). The OO extensions (the second +), in particular multiple inheritance, seem (to me at least) somewhat idiomatic and ad hoc, and this is reflected in the forbidding complexity of the rules pertaining to them, and in some ugliness of the implementation. I have this suspicion that they are the "programming language" aspect of C++. A lot of people are happy with them, because they get many jobs done in one way or another, but some others (like me) are not so sure they are as conceptually robust and minimalist as the rest of the language. Note that I do not especially like the technique used by other OO language authors to slide difficulties under the carpet by abuse of references and dynamic binding or polymorphism, or the renounciation by functional language authors of the difficulties linked with statefulness, or other irrelevant details :-). C++ is difficult because easy ways out have been avoided (except for virtual multiple inheritance, that is :-/). Eventually the state of the art will advance, and we all hope that a full fledged OO language will eventually not need a few hundred pages of language legalese to be described, or that it will be conclusively proven wrong our intuition that says that OO is fundamentally simpler than that. In the meantime the wary will remember that C++ is better than most, but not quite finished yet. State of the art, but the state of the art is not that satisfactory. -- Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk