Maynard Handley said:
The computer languages field seems to have no Dawkins, no Gould, no
popularizers and not even any very good text books. Every one of the
books I have tried has come across as boring, poorly structured, making
no obvious attempt to justify things and completely unwilling to stand by
itself.
I would suggest "The Structure and Interpretation of Computer Programs" by
Abelson and Sussman as a textbook counterexample. Elegant, clear and
useful. Anyone who has studied it will understand how to write good code;
among many others, a generation of MIT undergraduates has been trained with
it.
Larry
--
Lawrence Hunter, PhD.
National Library of Medicine phone: +1 (301) 496-9303
Bldg. 38A, 9th fl, MS-54 fax: +1 (301) 496-0673
Bethesda. MD 20894 USA email: ······@nlm.nih.gov
>Maynard Handley said:
> The computer languages field seems to have no Dawkins, no Gould, no
> popularizers and not even any very good text books. Every one of the
> books I have tried has come across as boring, poorly structured, making
> no obvious attempt to justify things and completely unwilling to stand by
> itself.
That's largely because Dawkins and Gould are making observations.
They are not attempting to construct things which have never existed before.
I say that after reading Gould's text book (O&P, very good)
not his popular books (like Mismeasure of Man) which are enjoyable.
Wirth and Ishbiah (sp) are pretty bright guys, but they are not above
making mistakes (Niklaus himself wrote a letter/article when he forgot
an important piece of syntax in Pascal (catch-all exception to the multiway
branch: aka as "OTHERWISE" in some compilers, "ELSE" in other compilers,
and a slew of other keywords having identical semnatics). It was almost
impossible to get this simple (ha!) fix added to the language.
Ritchie is pretty bright, too.
I recommend The History of Programming Languages II (HOPL-II) published
by ACM Press/Addison-Wesley. I can tell you there are no Silicon Valley
copies at Comp Lit Bookshop as I cleaned them all out for friends (you
might find a copy at Stacey's in Palo Alto, the Sunnyvale library has a
copy (I was impressed).
Backus is also bright. Bill Wulf in conversation to me suggested that
the Griswolds are also bright. Oh, a LISP cross post: I occasionally
see John McCarthy at Stanford and Printers Inc. John is also quite bright.
I signed his petition against Computing the Future.
All bright guys, and they all learned (made mistakes along the way).
The brightest most inspired language designers I can think of might be
Alan Kay and Adele Goldberg and their world on Smalltalk-80. If you are
using a windowing system, you are most likely using a system inspired by
them. A very impressive chapter in HOPL-II about them (see the
paragraphs refering to "management").
In article <··············@work.nlm.nih.gov>,
Larry Hunter <······@work.nlm.nih.gov> wrote:
>I would suggest "The Structure and Interpretation of Computer Programs" by
>Abelson and Sussman as a textbook counterexample. Elegant, clear and
>useful. Anyone who has studied it will understand how to write good code;
>among many others, a generation of MIT undergraduates has been trained with
I do not believe it is sufficient.
I can suggest a shorter reference:
IEEE Computer Dec. 1990.
You merely need a decent library or a 6 year IEEE member to get the gist.
Two articles stand out (one comes from the MIT AI Lab [and Stanford]).
The two articles stand as an interesting contrast: one is a perfect example
of the problems cited by the other:
The order which you read these articles might highly influence your
perception, so I will cite them in page order. Fair enough?
[The annotations are NOT all mine (collected over time).
In particular see the last sentence of the first annotation
to the first article.]
%A Cherri M. Pancake
%A Donna Bergmark
%T Do Parallel Languages Respond to the Needs of Scientific Programmers?
%J Computer
%I IEEE
%V 23
%N 12
%D December 1990
%P 13-23
%K fortran, shared memory, concurrency,
%X This article is a must read about the problems of designing, programming,
and "marketing" parallel programming languages.
It does not present definitive solutions but is a descriptive
"state-of-the-art" survey of the semantic problem. The paper reads like
the "war of the sexes." Computer scientist versus computational scientist,
some subtle topics (like shared memory models) are mentioned. An
excellent table summarizes the article, but I think there is one format error.
[e.g. of barriers versus subroutines.]
It is ironically followed for an article by computer scientists typifying
the author's thesis.
%X Points out the hierarchical model of "model-making (4-level)
very similar to Rodrigue's (LLNL) parallelism model (real world ->
math theory -> numerical algorithms -> code).
%X Table 1:
Category For scientific researcher For computer scientist
*
Convenience
Fortran 77 syntax Structured syntax and abstract
data types
Minimal number of new Extensible constructs
constructs to learn
Structures that provide Less need for fine-grain
low-overhead parallelism parallelism
Reliability
Minimal number of changes to Changes that provide
familiar constructs clarification
No conflict with Fortran models Support for nested scoping
of data storage and use and packages
Provision of deterministic Provision of non-deterministic
high-level constructs high-level constructs
(like critical sections, (like parallel sections,
barriers) subroutine invocations)
Syntax that clearly Syntax distinctions less
distinguishes parallel from critical
serial constructs
Expressiveness
Conceptual models that support Conceptual models adaptable to
common scientific programming wide range of programming
strategies strategies
High-level features for High-level features for
distributing data across distributing work across
processors processors
Parallel operators for array/ Parallel operators for abstract
vector operands data types
Operators for regular patterns Operators for irregular
of process interaction patterns of process
interaction
Compatibility
Portability across range of Vendor specificity or
vendors, product lines portability to related
machine models
Conversion/upgrading of Conversion less important
existing Fortran code (formal maintenance
procedures available)
Reasonable efficiency on most Tailorability to a variety of
machine models machine models
Interfacing with visualization Minimal visualization
support routines support
Compatibility with parallel Little need for "canned"
subroutine libraries routines
%A Andrew Berlin
%A Daniel Weise
%T Compiling Scientific Code Using Partial Evaluation
%J Computer
%I IEEE
%V 23
%N 12
%D December 1990
%P 25-37
%r AIM 1145
%i MIT
%d July 1989
%O pages 21 $3.25
%Z Computer Systems Lab, Stanford, University, Stanford, CA
%d March 1990
%O 31 pages......$5.20
%K partial evaluation, scientific computation, parallel architectures,
parallelizing compilers,
%K scheme, LISP,
%X Scientists are faced with a dilemma: Either they can write abstract
programs that express their understanding of a problem, but which do
not execute efficiently; or they can write programs that computers can
execute efficiently, but which are difficult to write and difficult to
understand. We have developed a compiler that uses partial evaluation
and scheduling techniques to provide a solution to this dilemma.
%X Partial evaluation converts a high-level program into a low-level program
that is specialized for a particular application. We describe a compiler that
uses partial evaluation to dramatically speed up programs. We have measured
speedups over conventionally compiled code that range from seven times faster
to ninety one times faster. Further experiments have also shown that by
eliminating inherently sequential data structure references and their
associated conditional branches, partial evaluation exposes the
low-level parallelism inherent in a computation. By coupling partial evaluation
with parallel scheduling techniques, this parallelism can be exploited for
use on heavily pipelined or parallel architectures. We have demonstrated this
approach by applying a parallel scheduler to a partially evaluated
program that simulates the motion of a nine body solar system.
While I am cutting and pasting....
42. You can measure a programmer's perspective by noting his
attitude on the continuing vitality of FORTRAN.
--Alan Perlis (Epigrams)
55. A LISP programmer knows the value of everything, but the
cost of nothing.
68. If we believe in data structures, we must believe in
independent (hence simultaneous) processing.
For why else would we collect items within a structure?
Why do we tolerate languages that give us the one without the other?
--Alan Perlis (Epigrams)
Alan Perlis in his Epigrams did:
"Just think with VLSI we can have 100 Eniacs on a chip.")
Have I covered enough ground on this one?
In article <··········@darkstar.ucsc.edu>
······@cse.ucsc.edu "Eugene Miya" writes:
[stuff deleted to cut to the interest bits ;-)]
> The brightest most inspired language designers I can think of might be
> Alan Kay and Adele Goldberg and their world on Smalltalk-80. If you are
> using a windowing system, you are most likely using a system inspired by
> them. A very impressive chapter in HOPL-II about them (see the
> paragraphs refering to "management").
Before I began to learn _anything_ significant about computer, and
the people in computing, these two became my "heroes". It's tempting
to say "the rest is history", but it's not over yet! Smalltalk hasn't
changed much since leaving the ivory tower, but it _has_ changed,
and fortunately, it hasn't stopped yet.
As for windowing systems, well. Most people feel very strongely about
these things, which is a good way of saying that they've arrived and
won't be going away. Everything else we might say is just an opinion,
and we can be sure that somebody will disagree. ;-)
> In article <··············@work.nlm.nih.gov>,
> Larry Hunter <······@work.nlm.nih.gov> wrote:
> >I would suggest "The Structure and Interpretation of Computer Programs" by
> >Abelson and Sussman as a textbook counterexample. Elegant, clear and
> >useful. Anyone who has studied it will understand how to write good code;
> >among many others, a generation of MIT undergraduates has been trained with
>
> I do not believe it is sufficient.
I'd say it's a little too much! ;-) The intro warns you that there's
enough material to cover several programming courses. Somebody new
to Lisp might think that they're expected to digest the whole book
as a single learning experience. I wouldn't recommend that!
[references cut to save space]
I've yet to read The Little Schemer, but it sounds like a more gentle
intro to Lisp. Your own recommendations look good, too.
> While I am cutting and pasting....
>
>
> 42. You can measure a programmer's perspective by noting his
> attitude on the continuing vitality of FORTRAN.
> --Alan Perlis (Epigrams)
<grin>
> 55. A LISP programmer knows the value of everything, but the
> cost of nothing.
I sometimes wonder if we could say something similar about C/C++,
perhaps: A C++ programmer knows the cost of everything and the
value of nothing.
Still, I think that we're quoting Alan Perlis out of context...
> 68. If we believe in data structures, we must believe in
> independent (hence simultaneous) processing.
> For why else would we collect items within a structure?
> Why do we tolerate languages that give us the one without the other?
> --Alan Perlis (Epigrams)
A damn good question.
> Alan Perlis in his Epigrams did:
> "Just think with VLSI we can have 100 Eniacs on a chip.")
Aha.
> Have I covered enough ground on this one?
Very probably. ;-)
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
We are getting away from architecture.....
In article <············@wildcard.demon.co.uk>,
Cyber Surfer <············@wildcard.demon.co.uk> wrote:
>> Alan Kay and Adele Goldberg and their world on Smalltalk-80.
>
>Before I began to learn _anything_ significant about computer, and
>the people in computing, these two became my "heroes". It's tempting
>to say "the rest is history", but it's not over yet! Smalltalk hasn't
>changed much since leaving the ivory tower, but it _has_ changed,
>and fortunately, it hasn't stopped yet.
I didn't finish the story fortunately. I spun a nice sounding but
incomplete yarn, deliberately. I went to Comp.Lit shortly after that
plane flight returning from Redmond. There were all these books on
Smalltalk for IBM systems. Now, not to dump too much on IBM, these
books were all completely uninspiring.
>As for windowing systems, well. Most people feel very strongely about
>these things, which is a good way of saying that they've arrived and
>won't be going away. Everything else we might say is just an opinion,
>and we can be sure that somebody will disagree. ;-)
Ah, if you only get a chance to work with Cedar (which I've seen)........
Or maybe Xanadu (which I've not seen, but monthly see the principals).....
>> 55. A LISP programmer knows the value of everything, but the
>> cost of nothing.
--Alan Perlis
>I sometimes wonder if we could say something similar about C/C++,
>perhaps: A C++ programmer knows the cost of everything and the
>value of nothing.
>
>Still, I think that we're quoting Alan Perlis out of context...
The Epigrams were supposed to be self-contained.
So don't feel too bad about it.
>> 68. If we believe in data structures, we must believe in
>> independent (hence simultaneous) processing.
>> For why else would we collect items within a structure?
>> Why do we tolerate languages that give us the one without the other?
>> --Alan Perlis (Epigrams)
>
>A damn good question.
The reason, I believe, that that we did not know better.
We thought too much of the general and not enough about the special
cases like exception handling, processing conditionals (IF statements),
etc. We were lulled into a false sense of knowing because we mistook
the problem for a geometric one (parallel lines) when the reality was
that we needed costly marginally scalable synchronizations.
Dave Kuck in one of his ICPP (or could have been Sagamore) addresses
did a nice summary of the problems. You could not limit generality well
enough (I really should go back and find that paper for the FAQ).
>> Have I covered enough ground on this one?
>
>Very probably. ;-)
Good! Then we should progress!
"Beware the Turing tarpit."
--AP
In article <··········@darkstar.ucsc.edu>
······@cse.ucsc.edu "Eugene Miya" writes:
> I didn't finish the story fortunately. I spun a nice sounding but
> incomplete yarn, deliberately. I went to Comp.Lit shortly after that
> plane flight returning from Redmond. There were all these books on
> Smalltalk for IBM systems. Now, not to dump too much on IBM, these
> books were all completely uninspiring.
My one IBM book is their "SAA CUA Advanced Interface Design Guide".
which I keep at one end of my shelf of programming language books.
Next to it are the "green", "red", and "blue" books, and on the
other side of those mighty tomes are the two P4 books. Most of the
other books are about Lisp. I hardly ever touch the IBM book.
So, I agree with you. ;-)
> >As for windowing systems, well. Most people feel very strongely about
> >these things, which is a good way of saying that they've arrived and
> >won't be going away. Everything else we might say is just an opinion,
> >and we can be sure that somebody will disagree. ;-)
>
> Ah, if you only get a chance to work with Cedar (which I've seen)........
> Or maybe Xanadu (which I've not seen, but monthly see the principals).....
Stop! You're making me envious. ;)
> The Epigrams were supposed to be self-contained.
That's what I guessed.
> So don't feel too bad about it.
I don't. ;)
> The reason, I believe, that that we did not know better.
> We thought too much of the general and not enough about the special
> cases like exception handling, processing conditionals (IF statements),
> etc. We were lulled into a false sense of knowing because we mistook
> the problem for a geometric one (parallel lines) when the reality was
> that we needed costly marginally scalable synchronizations.
Special cases have a bad habit of jumping up and bitting your bum.
> Dave Kuck in one of his ICPP (or could have been Sagamore) addresses
> did a nice summary of the problems. You could not limit generality well
> enough (I really should go back and find that paper for the FAQ).
That would be most welcome!
> Good! Then we should progress!
>
> "Beware the Turing tarpit."
> --AP
"What Turing tarpit - oh, _that_ one..."
We could all use some big rubber boots.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
Future generations are relying on us
It's a world we've made - Incubus
We're living on a knife edge, looking for the ground -- Hawkwind
(Followups to comp.lang.misc, which I don't read, but it seems
appropriate.)
Larry Hunter (······@work.nlm.nih.gov) wrote:
: Maynard Handley said:
: The computer languages field seems to have no Dawkins, no Gould, no
: popularizers and not even any very good text books. Every one of the
: books I have tried has come across as boring, poorly structured, making
: no obvious attempt to justify things and completely unwilling to stand by
: itself.
: I would suggest "The Structure and Interpretation of Computer Programs" by
: Abelson and Sussman as a textbook counterexample. Elegant, clear and
: useful. Anyone who has studied it will understand how to write good code;
: among many others, a generation of MIT undergraduates has been trained with
: it.
It is certainly the first book that came to my mind when I read Maynard's
post. However I wouldn't claim it will automatically produce great
programmers...
There are many other programming language texts which I found compelling
reads. From when I was in high school, the SNOBOL IV book by Griswold et
al, LISP by Horn and Klaus (???), and an ancient PDP-10 macro assembler
manual the local DEC sales office was gracious enough to send to me. One
that really stands out is "The C Programming Language" by Ritchie and
Kernighan, though that was a few years after the others. This book was
clearly written and did a pretty good job of selling the C lanugage to lots
of programmers. C instantly made sense to me as a much more useful tool
that Pascal and other alternatives. It perhaps wasn't as totally cool as
LISP, but it was much more practical for writing the kinds of programs I
was interested in. (And the only other language design that has struck me
as better than C in that regard is Modula 3.)
The PERL Camel book is another good example of a book that has done much to
popularize a language.
If you are looking for an overview of all programming languages, you're
going to be left unsatisfied. This is like asking for a summary of many
spoken languages. Yeah, you can enumerate the syntax and grammar and
perhaps even some of the semantics. But without elemnts of the "culture"
behind these languages, they aren't going to make much sense. What is a
language without its idioms, its historical references, and its literature?
I suppose one could ask for a book introducing one to programming language
design. This supposes that such a discipline is evolved enough to have set
rules and principles. I don't think this is really true. And in fact, any
significant language is the product of eveolution and owes a great debt to
its predecessors. So to design a great language, you will probably have to
have a good bit of experience with many existing languages.
If you are going to design a general purpose programming language, its a
good idea to know what a language specification should be as well. Two of
my favorite examples are the Modula-3 spec (from DEC SRC and Olivetti) and
the ANSI-C specification. The Common LISP spec is pretty good too, though
it boggles the mind to understand how that much complexity is
necessary. (As opposed to Dylan where some really big names in the LISP
world totally failed to specify a language at all in the necessary level of
detail.) Note that for both ANSI C and Modula 3, one should be able to
write useful portable programs according to the specification.
Of course the ANSI C++ standard will make the Common LISP standard look
like light bedtime reading. And probably still won't tell you what many
programs should do. If you want proof that language design is not a hard
and fast science, look no further than C++.
-Z-