Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site rochester.UUCP Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!hao!seismo!rochester!blenko From: blenko@rochester.UUCP (Tom Blenko) Newsgroups: net.lang Subject: Re: Object oriented languages (saga contines: Tom Replies) Message-ID: <7542@rochester.UUCP> Date: Fri, 22-Jun-84 18:29:37 EDT Article-I.D.: rocheste.7542 Posted: Fri Jun 22 18:29:37 1984 Date-Received: Wed, 27-Jun-84 09:27:00 EDT References: <1979@mit-eddie.UUCP>, <268@harvard.UUCP>, <281@harvard.UUCP>, <283@harvard.ARPA> Organization: U. of Rochester, CS Dept. Lines: 390 My apologies, first, to any who feel this inappropriate. My initial response was sent by mail, published without consulting me, and I just can't conTROL THIS INFERNAL URGE TO REPLY :-) 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.))" You seem to be confusing the syntax of the language with the semantics. Is the syntax of C really qualitatively different than the syntax of PASCAL (or FORTRAN, or ADA)? I think not. FORTH has simple syntax (which some would argue makes it more difficult to use). An issue with regard to C is that the semantics are more complicated than for a language such as PASCAL. That is, the programmer has to have a more complicated semantic model, and the semantics are not so clearly seperated from the structure of the underlying machine. This is certainly an advantage for some programmers, and a disadvantage for others. LISP 1.5 has simple syntax. Throw in reader macros and other macros and the syntax remains simple, while the semantics become considerably more complicated. Any reasonable implementation of LISP supports macros, and any sizeable code written in LISP uses them. LISP does not buy semantic simplicity, and I claim syntactic simplicity isn't necessarily a win. 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. Sure. LISP and COMMON LISP (I'm not absolutely sure about SCHEME, and by the way, you probably ought to be mentioning which version of SCHEME you are advocating) have a very primitive notion of data structures. Certainly you can, using the macros mentioned above, define things corresonding to data structures, but they are not part of the language, per se, and they require user-sophistication to implement correctly. The point is not that C is ">" any higher level languages, just that languages have special characteristics designed in for specific purposes. C has its own and SCHEME has its own, and they aren't the same. Space and time efficiency may be less emphasized than they used to be, relative to programmer productivity for example, but they are important concerns, and ones which are reflected in the design of languages such as C. 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. I don't think there is a fine line, I think it is all in the head of the observer. 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. Some people. Others use PASCAL, MODULA-II, LISP, PROLOG, ADA, and even FORTRAN and BASIC. And then there are hordes of other languages. I'm not sure what this has to do with choosing between X and Y for teaching introductory programming. 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). Yes, I would be interested in your reference. Functional and logic programming people, among others, have been looking at this for some time. "including features of non-procedural programming" isn't a very strong claim. LISP has proved to be a good base for embedded languages, but then C and PASCAL can also be used, so that's not too relevant. LISP can be made to look like a non-procedural language, but so can C and PASCAL. I don't understand your claim here. 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?) Yes, it has been shown that is is possible to exploit parallelism in functional languages. Which doesn't mean that T is a functional language, or that programs can't be (innocently) written for which this cannot be so readily done. I entirely believe that C less readily lends itself to such exploitation. I don't see what you would have us conclude from this. 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. That depends a whole lot what you mean by "do". You seem to have a pretty confused idea of what you mean. Actually, I think I did hear of a scheme for doing computed goto's in C :-). Probably not what the designers intended though! 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? It's a statement about a particular implementation of SCHEME in a particular computing environment being used for particular purposes. 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'm not going to argue that. I would prefer LISP, or a LISP-like language. 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. Well, citing a little introspective experience (Pat Hayes, are you listening?), I suppose students are going to use whatever is easiest. Depending on the programming environment, the programmer's experience, the resources available, and lots of other subjective factors, the student is simply going to minimize the time and effort required to complete the assignment. Lots of LISP programming environments are not very good (Franz on Unix, for example), some LISP implementations are notable hogs (INTERLISP, for example), and some are just not very efficient (T comes to mind). Those are just arguments against LISP- like languages. There are a lots more, pro and con. Besides, most students will reliably fail to make the correct (optimal) choice :-). 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. Oh, boy. Good thing I'm not religious (I'd be feeling lots of conflicting emotions here). First, I don't think you have a very good understanding of WHAT the industry is. Consider, for example, how many readers on this network know ANYTHING AT ALL about AI. Second, AI is defined by what Newsweek says (or even Ed Feigenbaum). Third, I'm currently employed by the Artificial Intelligence Center at SRI, and I don't think I (or anyone else) needs your instruction on AI or where it is going. Fourth, users of LISP did not invent or develop AI. AI people invented LISP (and lots of other languages, incidentally). Fifth, ideas for ADA came from lots of different languages, and I think it would be lunacy to pick out LISP as somehow being the intellectual parent of the all. Sixth, I have written an "expert system" in use in industry, and it certainly wasn't written in LISP. It would have been easier is LISP, but we'll just leave it as an exercise to the reader to figure it out (it was written in C, incidentally :-)). 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]. I'll skip the obvious slur on your own your own notions of loftiness. My (liberal arts) undergraduate institution didn't have ANY courses (for credit) in programming. They also haven't had any trouble getting people into (good quality) graduate schools in CS. All the people from Harvard in AI that I have ever met came out of other departments than CS (which also has to do with Harvard's reticence in getting into the field). Once again, I don't think you know the slightest thing about who does what in industry, and you demonstrate that better than I can. So I'd say that 1) Harvard CS has very little to boast about thus far, and 2) there are lots of people from other programs who are as good or better than what you claim you are producing. Incidentally, I first learned of your public reply to (and publication of) my personal mail to you via a letter from one of your fellows (at Harvard, former TA of the course, and all that), who seems to be in considerable disagreement with your comments here. [My opinions are my own, regardless of what you may read into the above paragraph.] So I gather. 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? (-; You'll also be unemployed. Yes, companies have failed, and lots more have survived by sticking to the same old ideas. Ever heard of IBM? Speaking about knowing anything, do you have any idea what ICOT's budget is for this year? 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). 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. Since I don't think you know anything (to speak of) about programmers in this country, I'm certainly not going to argue with you. "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"))) Really, I don't pick the wings off of flies, Tom