betz (01/03/83)
Does anyone out there know of any so-called "object oriented" languages that are available in source form (preferably written in C) and also in the public domain? I'd like to experiment with object oriented programming, but don't have access to a language that supports it. Also, I have been working on an experimental language that is a combination of lisp and an object language. It isn't practical for serious work, but I have managed to put it up on VAX/VMS, RT-11, and UNIX. I'm in the process of bringing it up on CPM. It is written in C (or should it be "c") and I believe that I could make it available if anyone was interested. (FREE) There must be more people that are interested in trying object oriented programming and don't want to wait for Smalltalk-80 to find its way out of Xerox. Thanks, David Betz
heliotis (01/07/83)
I notice in the December SIGPLAN issue that Adele Goldberg still is claiming tat her Smalltalk book will be out this year (83). We shall see...
lee (01/07/83)
If you would like to play with an object oriented language, Clu is availible for VAX/Unix and Tops-20 from MIT. I think it is (nearly) free to Universities.
wm (01/18/83)
Publication date for the BIG book on Smalltalk is set for March. Cost is mid 30's. Get in line now. I saw a preliminary copy of it, looks good. Wm Leler - UNC Chapel Hill
kevin@harvard.UUCP (Kevin Crowston) (06/12/84)
Here at Harvard we tried teaching the introductory programming course (AM110) in a higher level language: SCHEME. (I was a teaching assistant for the course.) Unfortunately, the implementation we had (which was written in T) was so slow and the machine so crowded that most students spent about 50% (or more) of their time waiting for the computer to do anything. This year, the course went back to a little assembly language, a lot of C and some LISP, with better results. I do not believe that the advantages of teaching SCHEME outweigh the need for more resources or the fact that the other courses here (and the jobs that the students want the experience for) use more traditional languages (like C). I think the couple of weeks exposure the students now get is enough to at least let them see that there are other ways of programming; the details can wait for a higher level course. I should probablly point out that the opinions above are my own and in no way reflect the opinions or policies of Harvard University or any of its faculty. Kevin Crowston harvard!kevin
nessus@mit-eddie.UUCP (Doug Alan) (06/14/84)
> From genrad!wjh12!harvard!kevin Tue Jun 12 14:24:17 1984 > I do not believe that the advantages of teaching SCHEME outweigh > the need for more resources or the fact that the other courses > here (and the jobs that the students want the experience for) > use more traditional languages (like C). I think the couple of > weeks exposure the students now get is enough to at least let > them see that there are other ways of programming; the details > can wait for a higher level course. I have taken both the Harvard and the MIT introductory computer science courses. After the Harvard course (which I took while in high school -- it taught Macro-11 assembly language, Lisp, and C), I felt that I had learned how to engineer small programs. Sort of interesting, but I still wanted to be a physicist. After I took the MIT course, I felt that I had learned a great deal of beautiful, clean, and powerful concepts. It was a joy taking the class, and every assignment was bliss to work on, even if the computer was overloaded and I had to do my work at 3 am. It converted me from physics to computer science. You'd think that Harvard, the liberal arts school, would go for the beautiful concepts, while MIT, the technology school, would go for the down-to-earth engineering. But life is strange. One of the things that makes MIT such a great school is that there are many people here who realize that beautiful concepts and engineering can complement one another. -- -Doug Alan mit-eddie!nessus Nessus@MIT-MC "What does 'I' mean"?
nessus@mit-eddie.UUCP (Doug Alan) (06/14/84)
I guess I didn't make my point very clear in my previous message, but a point I was trying to say is that a language like Scheme is a perfect medium for teaching an introductory computer science course, because it is so conducive to teaching incredible concepts. It is a clean, simple, powerful, and beautiful language (interpretive, no 2nd class objects, procedures are 1st class, lexically scoped and complete with working funvals, great for demonstrating message passing, computation streams, data abstraction, control abstraction, delayed evaluation, recursion, etc.) -- much more so than assembly, C, Pascal, or any such language. And unless you want to write production programs, you don't have to worry about I/O, compilers, linkers, and all the other cruft that other languages require that you understand before you can even use them. Someone taking an introductory computer science course shouldn't have to deal with all that cruft. Harvard used MIT's course with Scheme and all its neat concepts for a semester, but seems to have reverted back to its old course (which by the way is based on MIT's course from about 10 years ago) due to lack of computer resources and a desire to make the course more practical once again. And this I think is a shame. -- -Doug Alan mit-eddie!nessus Nessus@MIT-MC "What does 'I' mean"?
brownell@harvard.UUCP (Dave Brownell) (06/16/84)
[MIT attacks Harvard ... a counterattack !!! a left!!! ... a CDR ???] >> From kevin@harvard.ARPA >> Date: Tue, 12-Jun-84 14:24:17 EDT >> I do not believe that the advantages of teaching SCHEME outweigh >> the need for more resources or the fact that the other courses >> here (and the jobs that the students want the experience for) >> use more traditional languages (like C). > From: nessus@mit-eddie.ARPA > Date: Wed, 13-Jun-84 21:33:37 EDT > ... You'd think > that Harvard, the liberal arts school, would go for the beautiful > concepts, while MIT, the technology school, would go for the > down-to-earth engineering. But life is strange. One of the things that > makes MIT such a great school is that there are many people here who > realize that beautiful concepts and engineering can complement one > another. It may not have come across in Kevin's original letter, but the course in question came from MIT. As Kevin said, machine resources were the big bottleneck. I was also a TF for the course; I know. The reason there was a machine bottleneck was an implementation of SCHEME that used too much virtual memory. (A better implementation foundered on political sand and lack of support.) Ruminations about trade schools versus liberal arts schools (bring on the flames !!!! :-) are interesting, but frankly, "you had to be there". Doug did not take any Harvard version of the course in question. Summer school didn't count. I agree that beautiful concepts can complement engineering, but this time the concepts lost. Beautiful concepts, as anyone who has worked in the computer industry can testify, may lose to the reality of implementation. On many machines now in existence, object oriented languages are implemented inefficiently; unless you have money to burn, they aren't a real option for very large introductory courses. Dave Brownell Sequoia Systems Inc. Maker of Fine Fault Tolerant Systems since 1984 (whee!) {cmcl2,floyd,ihnp4,genrad,research,seismo} !harvard!sequoia!brownell
nessus@mit-eddie.UUCP (Doug Alan) (06/16/84)
> From: brownell@harvard.UUCP (Dave Brownell) > [MIT attacks Harvard ... a counterattack !!! a left!!! ... a > CDR ???] Well, I dunno if I'd call it an attack. (Maybe a call-by-name argument.) I just think that MIT does a much better job at teaching introductory computer science, and I think it's important to understand why. Also, I had realized that I had not made my point very well and I posted very shortly after posting the article you are talking about a new article that more closely said what I meant. It addressed most of what you are talking about before you even said it. I think it is a pretty good idea in general to read through the whole news group before responding to an individual letter. I will quote from that newer letter here where appropriate. > It may not have come across in Kevin's original letter, but the > course in question came from MIT. As Kevin said, machine > resources were the big bottleneck. I was also a TF for the > course; I know. The reason there was a machine bottleneck was > an implementation of SCHEME that used too much virtual memory. > (A better implementation foundered on political sand and lack of > support.) Me: "Harvard used MIT's course with Scheme and all its neat concepts for a semester, but seems to have reverted back to its old course (which by the way is based on MIT's course from about 10 years ago) due to lack of computer resources and a desire to make the course more practical once again. And this I think is a shame." Actually, the real reason they changed back to the old course is probably because the implementation of Scheme came from Yale. :-) > Ruminations about trade schools versus liberal arts schools > (bring on the flames !!!! :-) are interesting, but frankly, "you > had to be there". Hmmph. I wouldn't call MIT a "trade school". Many people (like me) are here for science, philosophy, math, linguistics, art, etc. -- not engineering. > Doug did not take any Harvard version of the course in question. > Summer school didn't count. I suppose you should tell this to Henry Leitner, the instructor of the course, who told us that we were going to be doing everything the normal semsester class did, and since it was crammed into seven weeks we were going to have to work really hard. It only took 48 hours a day. And I suppose you should also tell this to the all the people I talked to who had taken the normal semster course and told me that we were indeed doing everything they did. And I suppose you should also tell Harvard, who gave me the same credit. > I agree that beautiful concepts can complement engineering, but > this time the concepts lost. Beautiful concepts, as anyone who > has worked in the computer industry can testify, may lose to the > reality of implementation. On many machines now in existence, > object oriented languages are implemented inefficiently; unless > you have money to burn, they aren't a real option for very large > introductory courses. MIT seems to do a good job at it. Of course they have money to burn. But this is an important point. Sometimes in order to provide a good education, you have to spend money. Like providing a large library with millions of books. Or providing enough computer resources to adequately teach object-oriented programming. (Two Vax 750s for several hundred people just doesn't cut it.) -- -Doug Alan mit-eddie!nessus Nessus@MIT-MC "What does 'I' mean"?
brownell@harvard.UUCP (Dave Brownell) (06/20/84)
<<<Flames about an object oriented programming course>>>
Doug Alan (nessus@mit-eddie) recently flamed me in this public
place for not reading the rest of a newsgroup before replying
to his posting. Sorry to disillusion you Doug, I did. I
never saw the correction you claim to have posted. It *might*
have gotten lost.
About the rest of the flame ... just HOW do you claim to know
more about the course than the people who taught it? And I don't
see why the CPU-intensive nature of object oriented programming
systems shouldn't enter into the planning for the next edition
of an experimental course.
Re "neat concepts": quantum physics is neat too, but don't you
teach mechanics first?
Dave Brownell
{allegra,floyd,ihnp4,seismo}!harvard!brownellbarmar@mit-eddie.UUCP (Barry Margolin) (06/21/84)
The difference between the introductory programming courses at MIT and Hahvahd probably has very little to do with the languages they use. It is more probably related to the philosophy of the curriculum, which Nessus implied. It is really wrong to call 6.001 ((born of 6.031 and 6.912) an "introductory programming course." Unless it has changed radically in the 3 or 4 years since I took it, it probably should not be taken by students with no prior computer programming experience. In fact, it was very helpful to already know Lisp (I took it the year before they switched to Scheme). The name of this course is "Structure and Interpretation of Computer Programs", and in it you are taught programming *ideas*, not programming languages. The course notes included a reference manual on the Lisp dialect we used, and the professors briefly went over Lisp programming for the first week or two, but from then on you were expected to be able to program anything you had to. This philosophy pervaded the entire MIT Computer Science curriculum, and it is the reason that I am so happy I went there. -- Barry Margolin ARPA: barmar@MIT-Multics UUCP: ..!genrad!mit-eddie!barmar
munyer@harvard.UUCP (Robert Munyer) (06/21/84)
() Regarding Kevin Crowston's article to to net.lang: I was also involved in Harvard's attempt to teach its intro programming course in SCHEME, and would like to give my own interpretation of the same experience. I question his assertion that the newer (and older) version of the course had "better results". I believe that the students who took the course when it used SCHEME came away with a better understanding of many important computer science concepts than those who used C or assembly language. 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. 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. Students in the SCHEME course learned how to program; students in previous years learned how to hack. The lifetime of C as a language (at least at the forefront of computer science) is very limited. 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". 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." Sure, it was easier on the system staff when the course used a small, fast, let-the-programmer-do-all-the-work-and-don't-waste-a-microsecond-to-help-him programming environment. We could have gotten by with even less computing power if we had been content to let the students use TECO instead of a screen-oriented editor. But here as elsewhere, memory size and processor power are increasing, and it seems counterproductive to worry too much about last year's limitations on cycles and kilobytes when debating future educational policy. Moreover, I don't believe that the system problems we had were a necessary result of using the higher level language. For one thing, we were initially using a very early pre-release version of T, which didn't have a working garbage collector or compiler (I'm serious!). With later releases of T, we got a working garbage collector and compiler and a considerably faster interpreter, and the system load decreased significantly. In fact, I know of at least one higher-level computer science course here (CS180, our AI course) which used T this year, with good results and no serious system problems. 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. 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. 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. Disclaimer: of course my opinions are only my own! ((name "Robert Munyer") (address (uucp "...allegra!harvard!munyer") (arpa "munyer@harvard") (Snail "15 Waldo Ave #1, Somerville MA 02143") (phone "(617)628-3718")))
munyer@harvard.ARPA (Robert Munyer) (06/22/84)
()
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 Blenko <seismo!rochester!blenko>
Subject: 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")))nessus@mit-eddie.UUCP (Doug Alan) (06/22/84)
> From: brownell@harvard.UUCP (Dave Brownell) > About the rest of the flame ... just HOW do you claim to know > more about the course than the people who taught it? Were you there five years ago when I took AMS11? How do you know? I know several people who have taken AM110. Their description of what they did in the course matches very closely with the material covered in the course I took. Were they lying? Their problem sets were very similar. Were they forged? If there is a significant difference between the courses that makes my argument invalid, please tell me what it is, instead of just making an unsupported assertion. > And I don't see why the CPU-intensive nature of object oriented > programming systems shouldn't enter into the planning for the > next edition of an experimental course. I never said it shouldn't. You should make sure that you have enough computer resources to provide a decent education. If this requires acquiring a more powerful computer or moving to a workstation environment, then this is what should be done. Harvard shouldn't have any problems finding enough money to do this: the students are paying ten grand a year to get a good education. > Re "neat concepts": quantum physics is neat too, but don't you > teach mechanics first? To understand quantum mechanics you have to understand a lot of background material. To understand many important fundamental computer science concepts, you don't. To understand Special Relativity, you don't need to understand a lot of background material, and learning it introduces many important concepts and can and should be used as an example of how to think about problems in physics. In fact, in the mechanics course I took here, the first thing covered was indeed Special Relativity. -- -Doug Alan mit-eddie!nessus Nessus@MIT-MC "What does 'I' mean"?
blenko@rochester.UUCP (Tom Blenko) (06/23/84)
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