Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site harvard.ARPA
Path: utzoo!watmath!clyde!floyd!whuxle!mit-eddie!genrad!wjh12!harvard!munyer
From: munyer@harvard.ARPA (Robert Munyer)
Newsgroups: net.lang
Subject: Re: Object oriented languages
Message-ID: <283@harvard.ARPA>
Date: Thu, 21-Jun-84 20:33:55 EDT
Article-I.D.: harvard.283
Posted: Thu Jun 21 20:33:55 1984
Date-Received: Fri, 22-Jun-84 07:36:28 EDT
References: <1979@mit-eddie.UUCP>, <268@harvard.UUCP>, <281@harvard.UUCP>
Organization: Aiken Computation Lab, Harvard
Lines: 242

()
Tom Blenko mailed me a response to my response to Kevin Crowston's
article.  I am posting it (and my response-cubed) to the net because I
believe that except for some (very mild, by net standards) personal
attacks, the issues discussed are of general interest to net.lang
readers.  Paragraphs indented 0 and 16 spaces are mine, those indented
8 are Tom's, those indented 24 are Kevin's.  The entire text of Tom's
letter has been included, since it has not appeared before on the net.

	From seismo!rochester!blenko Thu Jun 21 18:23:46 1984
	Date: 21 Jun 84 16:29:29 EDT (Thu)
	From: Tom 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")))