[net.lang] Object oriented languages

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!brownell

barmar@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