Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site harvard.ARPA Path: utzoo!watmath!clyde!floyd!whuxle!mit-eddie!genrad!wjh12!harvard!munyer From: munyer@harvard.ARPA (Robert Munyer) Newsgroups: net.lang Subject: Re: Object oriented languages Message-ID: <283@harvard.ARPA> Date: Thu, 21-Jun-84 20:33:55 EDT Article-I.D.: harvard.283 Posted: Thu Jun 21 20:33:55 1984 Date-Received: Fri, 22-Jun-84 07:36:28 EDT References: <1979@mit-eddie.UUCP>, <268@harvard.UUCP>, <281@harvard.UUCP> Organization: Aiken Computation Lab, Harvard Lines: 242 () Tom Blenko mailed me a response to my response to Kevin Crowston's article. I am posting it (and my response-cubed) to the net because I believe that except for some (very mild, by net standards) personal attacks, the issues discussed are of general interest to net.lang readers. Paragraphs indented 0 and 16 spaces are mine, those indented 8 are Tom's, those indented 24 are Kevin's. The entire text of Tom's letter has been included, since it has not appeared before on the net. From seismo!rochester!blenko Thu Jun 21 18:23:46 1984 Date: 21 Jun 84 16:29:29 EDT (Thu) From: Tom BlenkoSubject: Re: Object oriented languages To: harvard!munyer All of the time that the C student spends learning the bizarre and complicated syntax of C (and even worse, trying to debug his C programs) is time that he CANNOT spend understanding such concepts as object oriented programming and procedural abstraction. Complicated compared to what? If it's complicated, it probably isn't because of the syntax. I'm not sure I understand what you mean here. If you'd ever written a C program (like the one in front of me now) in which you needed to declare a part of a union to be a pointer to a function which returns a pointer to that kind of union, you'd agree with me that C's syntax is bizarre and complicated. You shouldn't have to look at the source to a compiler to figure out how to declare something. My other complaints about the syntax include a large number of extremely un-mnemonic operators, and such bizarre rules as "statements must be terminated by semicolons (exception: unless they are compound statements; braces need not be followed by semicolons (exception: unless they are used in initialization, in which case they DO need to be followed by semicolons.))" Moreover, many of these concepts are easy to illustrate in SCHEME and difficult or impossible in C, simply because C was not designed with them in mind. There ARE other programming language concepts to be taught besides those you cite! PLEASE name some of them for me, and I will be glad to show you how SCHEME and other higher-level languages are >= C for demonstrating nearly all of them. Students in the SCHEME course learned how to program; students in previous years learned how to hack. Don't you think that might be a bit of an over-generalization? Well, maybe a little bit. But there is a fine line between programming an hacking, and I still believe that the two courses were on opposite sides of it. The lifetime of C as a language (at least at the forefront of computer science) is very limited. I didn't realize it was at the forefront of CS. What it is at the forefront of, it will probably remain at the forefront of for lots of reasons you are apparently unaware of. Sorry I was a bit unclear. I didn't mean to say that C IS at the FF of CS, but that it is USED by people who are at the FF of CS. And I do wish you would refrain from darkly hinting about things I might be unaware of, and tell me instead what at least a few of these reasons are. T and other higher-level, object-oriented languages can take advantage of new and important advances (object-oriented programming, logic programming, parallel computation, non-Von-Neumann(sp?) architectures) in a way that is simply impossible for C and other "procedural languages". I think you mean imperative languages. There are very few non-procedural languages in existence. Mea culpa, mea maxima culpa. You have caught me in an error of terminology. I DID mean imperative languages. Although, of course, T (unlike C) can be elegantly extended to include features for non-procedural programming. (Reference available on request). A lot of people would be delighted for you to tell them how to use T, or anything else, on parallel and other non-Von Neumann machines. Or how they could build such machines to efficiently run T (or anything else). I must admit that I am certainly not able to explain to people how to design any sort of non-Von Neumann machine. BUT I do know that it is possible to make programs written in a functional language like T take advantage of parallel processing, WITHOUT changing their code, and that this is impossible with C. (Again, references available on request. I don't want to bother looking up the references unless you really want to read them. Most of them would be by people like Carl Hewitt, Guy Steele, Gerry Sussman and Henry Lieberman. Have you ever read anything by any of these people?) You also seem to have the malformed idea that C is somehow "unable" to do the things that T, say, can. I think you are poorly informed about programming languages! Yes, I have this idea. It is not malformed, and I am not poorly informed about programming languages. Do you question that I could design (and write a compiler for) a programming language in which the programmer would be UNABLE to do certain things that he could have done in assembly language? Here is one important example: In assembly language on almost all computers, there is a "computed goto" or "indirect jump" instruction. C does not have this. Therefore, some programs which I could write (and have written) in T or assembly language cannot be written in C (unless of course you are willing to provide potentially infinite stack space). I also want to address your statement on another level -- not of WHAT can be done, but HOW it can be done. In a non-extensible language like C, many facilities that the programmer might like to add (a generic comparison operator, support for concurrent processes, ...) cannot be done without great difficulty, by either modifying the compiler or forcing future users of the facility to use inconvenient syntax. I believe that this question -- HOW something can be done -- is even more important than WHETHER it can be done in a given language. Think where we would be now if all programming were done on Turing machines. Kevin's discussion seemed to contain three distinct points, with which I would like to deal separately: 1) SCHEME puts too much demand on system resources. 2) The other courses here use "more traditional languages (like C)". 3) The jobs the students want use "more traditional languages (like C)". First: "SCHEME is too demanding of resources." Well, I'm not sure this is much of a statement about SCHEME either. I'm not sure I understand this comment either. Care to clarify? Second: "The other courses here use more traditional languages (like C)." Again I bring up the example of CS180. AI, even more than other courses, simply cannot reasonably be taught without a higher level language. That's sheer nonsense. Lisp, Prolog, or a similar (high-level) language might be the language of choice, but ruling out C or Pascal is just senseless. All right, let me change my wording. Replace "cannot reasonably be taught" with "should not be taught". I believe that now that we have these languages available here, more courses will take advantage of them and the use of C as a teaching language here will begin to decrease. Possibly. I doubt it. You haven't gotten around to the real reasons students would choose one or the other, I think. Then please tell us these real reasons. Third: "The jobs the students want use more traditional languages (like C)." Granted, in 1984, bottom-level programming jobs (students' summer jobs, for example), often use C. But in 10 years, or 5, or even when they are graduated in 3 years, this may no longer be true, at least in the more advanced (and therefore more interesting) jobs. Think of how much the field has changed in just the last 5 years. I think that the language- independent computer science concepts I mentioned before will be much more useful to students in the long run than a familiarity with the current fad language would be. Utter nonsense. You obviously haven't spent much time in industry. It took Pascal 5-7 years to get into industry (and it may now have peaked). C is just on the upswing. If you knew anything about software life-cycles, you would happily go get your training in one or the other. Or consider Ada, which is much closer in style to C and Pascal than to T or SCHEME. You obviously haven't spent much time keeping up with the news in the industry. Artificial Intelligence is on the upswing, and virtually >>ALL<< of the important ideas in AI have been developed by users of Lisp or similar languages. [Note the word *developed*. Users of other languages may use these ideas, but users of Lisp *invented* them.] In fact, some of the important "advances" which Ada attempts to provide came originally from Lisp or similar languages. Another point, if you'll forgive a bit of snobbery: Here at Harvard, we like to think that our CS department turns out *computer scientists*, not coders. We do not give students "training", but *instruction*. I suspect that the "jobs in industry" of which you speak are mostly those of coders. A two year trade school would do well to consider which languages are currently in most demand in this sort of job; a University, however, should have loftier goals. [For an extension of this idea, see recent article by M. Kenig to net.lang]. [My opinions are my own, regardless of what you may read into the above paragraph.] You walk in with a background in Lisp and they'll laugh. If they laugh at me, I'll feel sorry for them. Giant industries have failed before because of the same avoidance of new ideas. Anybody know of a good correspondence course in Japanese? (-; I'll bet not 1/2 of 1% of the programmers in the country ever use Lisp, and I wouldn't expect any dramatic increases (for reasons you haven't come close to considering, and I haven't time to list). Tom Maybe not Lisp per se, but let me counter with this: I'll bet that eventually 99.5% of the programmers in this country will eventually use Lisp (or Prolog or Smalltalk or LogLisp), or at any rate something that resembles these languages much more closely than any of the imperative languages you seem to prefer. "It is difficult to convey to a reader in the late seventies the strength of the skepticism about "automatic programming" in general and about its ability to produce efficient programs in particular, as it existed in 1954." -- John Backus, in SIGPLAN Notices 13.8, August 1978 Fighting fire with fire, ((name "Robert Munyer") (address (uucp "...allegra!harvard!munyer") (arpa "munyer@harvard") (Snail "15 Waldo Ave #1, Somerville MA 02143") (phone "(617)628-3718")))