All explorations and investigations of the universe are consistent with the fact of it being infinitely rich and deep. The simplest hypothesis is therefore to accept that the universe is actually infinitely rich and deep. But neither atheists nor traditionally religious people accept this: the latter box in the universe with religious dogma, and the former box in the universe with science (which is always a finite approximation of an infinite universe). Perhaps it is because human beings much prefer to live in comfortable walled gardens and keep out the scary monsters of infinity? The following poem explains this attitude (with respect to the book Gödel, Escher, Bach, but it also applies to many other books):
Douglas Hofstadter, pudding and pie,
Kissed the integers and made them cry.
But when the infinities came out to play,
Douglas Hofstadter ran away.
In this respect, aren't you just as scared of infinity as traditionally religious people?
PS, more examples of this attitude are on the page The Glib Reductionists.
It is clear, from study of philosophy, that we have no proof that the world exists. So even the most fervent atheist, if he/she assumes that the world exists, must take this on *faith*. This atheist can go further, and assume that fellow humans exist, assume that physical laws exist, and assume that there is some order in the universe. Most do so. What this means, is that *almost all* human beings have a strong faith. This seems to not be different from the faith of religion in quality or strength, only in details. The question of whether or not there is a personal God is a straw man; the real question is whether our faith in existence is justified. So my question is, doesn't this mean that almost all humans are religious? Even you are religious in this sense, right?
Like Douglas Hofstadter and John Searle, Raymond Kurzweil and his buddies are just a bit too glib in jumping over infinities in their breathless thought experiments.
Tufte has come a long way from being a pure
scientist: you have to pay $7 to get his 28 page
essay on PowerPoint. Isn't scientific information
usually published in journals or conference
proceedings, for a nominal fee? Aren't papers
usually put on the Web for free?
Usually, science advances best when information
can be exchanged freely. Tufte seems to have
forgotten this.
As Gandalf once said: "The wise speak only of
what they know". Your comment shows that you
have not even given the briefest glance to
Oz and the Mozart system.
The object-oriented programming chapter just
explores the consequences of inheritance.
The OOP chapter should not be read in isolation,
since the notion of encapsulated data type
permeates the whole book.
It is first used in Chapter 3.
(Perhaps the OOP chapter should be renamed
"Programming with Inheritance".)
We are confused by your message and its
strong claims. Can you
give explicit and precise reasons why you think
the OOP chapter is "wrong and confused"?
We still have time to correct errors in the book,
so we would very much appreciate learning about
any that you can point out to us.
Erlang is an excellent example of
a language with a programming model that is
designed for building reliable applications.
It uses asynchronous message passing between
components (called 'processes' in Erlang)
that are otherwise completely independent,
and that are internally defined in a
functional way.
But it is not correct to imply that the book's
handling of concurrency, distribution, and
functional programming are 'like Erlang'.
E.g., Erlang's concurrency (message passing) is
but one of three practical paradigms that
we present in the book.
"It certainly won't be the bible of the programers who think java is a good language".
Isn't that a pretty harsh judgement on Java
programmers? In any case, the book is not judgemental about
programming languages, and certainly not about
Java, which is one of the four languages we
chose to illustrate programming paradigms.
We appreciate your thoughtful reply and in fact
we agree with it and your suggestions on improving the
AccountWithFee example. We will see if we can
rewrite this section to take your suggestions
into account.
If you send us your name privately, we can
acknowledge your suggestions in the book.
The interface/implementation separation.
It is
explained starting in Chapter 3 (Section 3.7) and
continues in Chapter 6. The OO Chapter follows
on this long discussion.
The LSP. It is mentioned prominently and
usefully in the Account example and in several
other places. It is called the "substitution
property". This is a perfectly acceptable name
in our view; Bertrand Meyer also uses it.
Polymorphism. It is completely natural in a
dynamically typed language. Perhaps we have
underemphasized it as a concept, but we use it
freely.
Invariant conditions. These are explained in
Chapter 6, when we talk about reasoning with
state. This reasoning naturally applies to
classes as well. (There is also a discussion
on invariants in Chapter 3, when we talk about
accumulators.)
"Cute syntax".
In fact, we introduce two important
concepts, namely first-class messages and
name values, in the early part of the OO chapter.
These are important, e.g., name values allow us
to *program* any kind of visibility constructs (like private, public, etc.) instead of accepting them as hard-wired.
The example of Section 7.4.1.
The AccountWithFee class
violates an algebraic property of sequences of
method calls. Where is encapsulation being
violated here?
"Overweight theory". All concepts in the
book are defined formally, in as lightweight
a way as we could devise. We find this essential
for getting a deep understanding.
However, we never do
theory for theory's sake. Furthermore, the
theory is clearly separated from the rest
and can be ignored if desired.
"Underpowered practice". The book distills
more than a hundred man-years of system-building
expertise. We have tried to extract the essential ideas from this experience.
Finally, remember that we cover a
wide territory in the book. We introduce reasoning
with invariants a few times, but we do not have
the space to develop it everywhere in the book.
The same goes for many other concepts. We rely
on the alert reader to make these connections.
As a final comment,
I am sorry that you have such a harsh opinion
of our work.
I think you have misconstrued what you have
read by taking it out of context.
You have hit on it exactly!
Our single-minded purpose is to talk about programming
and programming concepts. We do *touch* all the topics you mention (and many others), but only briefly. And
already the book is more than 900 pages. It's not that big
because we're paid by the page (actually, it is more like
inversely proportional to the number of pages).
It's that big because it is the natural size of what
we wanted to say. We never intended it to be so big.
We wrote the book because we had something to say
and we wanted to say it. That's all.
Message-passing concurrency is *not* CSP.
The former is asynchronous whereas the
latter is synchronous. However, the book
does mention CSP. See the index to find
out where (hint: it is in the 'language' item).
We do know CSP. I teach it in my semantics
course and give its full semantics. But the
book tries carefully to give a balanced view
of a very big field. We have tried hard to put
only the most practical and useful concepts
in there, the ones that will last. If your favorite
concept seems mistreated, we will likely have
a good reason for it! Just send me mail to ask.
Peter
Why, the LSP is known by many different names. The 'substitution property' for example. Why not try actually *reading* the OO chapter before giving such a sweeping judgement:-).
Ok, I looked at the Joy page. Joy seems to be 'Forth done right', with nice semantics. But, other than being implementable in just a few kilobytes, what's the advantage of the Joy approach? It seems to be a rather tortuous way to write functional programs.
Don't get me wrong. I enjoyed immensely writing Forth programs, especially since my machine only had 4 kilobytes of memory (it was an Elf II from 1976). But if you have the memory, why program in Forth (or Joy) nowadays (except to have a little fun)?
The book has a lot on dataflow programming
(both data-driven and demand-driven).
In our view,
dataflow is a basic concept that deserves
to be there from the beginning.
Dataflow concurrency has all the good
properties of functional programming
and yet is concurrent.
This seems not to be widely known, but
it deserves to be
since it is a much easier form of
concurrency than the usual stateful concurrency
(as used in all mainstream languages).
I have programmed in both Forth and PostScript;
they are incrementally
compiled languages with a postfix syntax
and no static typing.
I never heard of the term
"concatenative languages",
can you give a good reference?
I'm one of the authors and of course I'm enthusiastic
about the book, so don't take my word for it.
My coauthor and I have been working on it for two years and we've taught courses from it.
It distills ten years experience building the
Mozart system.
I'm one of the authors, so don't take my word for it. We've been working on it for two years and we've taught from it.
It distills ten years experience building the
Mozart system.
Slashdot Mirror
In this respect, aren't you just as scared of infinity as traditionally religious people? PS, more examples of this attitude are on the page The Glib Reductionists.
It is clear, from study of philosophy, that we have no proof that the world exists. So even the most fervent atheist, if he/she assumes that the world exists, must take this on *faith*. This atheist can go further, and assume that fellow humans exist, assume that physical laws exist, and assume that there is some order in the universe. Most do so. What this means, is that *almost all* human beings have a strong faith. This seems to not be different from the faith of religion in quality or strength, only in details. The question of whether or not there is a personal God is a straw man; the real question is whether our faith in existence is justified. So my question is, doesn't this mean that almost all humans are religious? Even you are religious in this sense, right?
Like Douglas Hofstadter and John Searle, Raymond Kurzweil and his buddies are just a bit too glib in jumping over infinities in their breathless thought experiments.
Usually, science advances best when information can be exchanged freely. Tufte seems to have forgotten this.
As Gandalf once said: "The wise speak only of what they know". Your comment shows that you have not even given the briefest glance to Oz and the Mozart system.
- The object-oriented programming chapter just
explores the consequences of inheritance.
The OOP chapter should not be read in isolation,
since the notion of encapsulated data type
permeates the whole book.
It is first used in Chapter 3.
(Perhaps the OOP chapter should be renamed
"Programming with Inheritance".)
- We are confused by your message and its
strong claims. Can you
give explicit and precise reasons why you think
the OOP chapter is "wrong and confused"?
We still have time to correct errors in the book, so we would very much appreciate learning about any that you can point out to us.But it is not correct to imply that the book's handling of concurrency, distribution, and functional programming are 'like Erlang'. E.g., Erlang's concurrency (message passing) is but one of three practical paradigms that we present in the book.
"It certainly won't be the bible of the programers who think java is a good language". Isn't that a pretty harsh judgement on Java programmers? In any case, the book is not judgemental about programming languages, and certainly not about Java, which is one of the four languages we chose to illustrate programming paradigms.
If you send us your name privately, we can acknowledge your suggestions in the book.
- The interface/implementation separation.
It is
explained starting in Chapter 3 (Section 3.7) and
continues in Chapter 6. The OO Chapter follows
on this long discussion.
- The LSP. It is mentioned prominently and
usefully in the Account example and in several
other places. It is called the "substitution
property". This is a perfectly acceptable name
in our view; Bertrand Meyer also uses it.
- Polymorphism. It is completely natural in a
dynamically typed language. Perhaps we have
underemphasized it as a concept, but we use it
freely.
- Invariant conditions. These are explained in
Chapter 6, when we talk about reasoning with
state. This reasoning naturally applies to
classes as well. (There is also a discussion
on invariants in Chapter 3, when we talk about
accumulators.)
- "Cute syntax".
In fact, we introduce two important
concepts, namely first-class messages and
name values, in the early part of the OO chapter.
These are important, e.g., name values allow us
to *program* any kind of visibility constructs (like private, public, etc.) instead of accepting them as hard-wired.
- The example of Section 7.4.1.
The AccountWithFee class
violates an algebraic property of sequences of
method calls. Where is encapsulation being
violated here?
- "Overweight theory". All concepts in the
book are defined formally, in as lightweight
a way as we could devise. We find this essential
for getting a deep understanding.
However, we never do
theory for theory's sake. Furthermore, the
theory is clearly separated from the rest
and can be ignored if desired.
- "Underpowered practice". The book distills
more than a hundred man-years of system-building
expertise. We have tried to extract the essential ideas from this experience.
- Finally, remember that we cover a
wide territory in the book. We introduce reasoning
with invariants a few times, but we do not have
the space to develop it everywhere in the book.
The same goes for many other concepts. We rely
on the alert reader to make these connections.
As a final comment, I am sorry that you have such a harsh opinion of our work. I think you have misconstrued what you have read by taking it out of context.You have hit on it exactly! Our single-minded purpose is to talk about programming and programming concepts. We do *touch* all the topics you mention (and many others), but only briefly. And already the book is more than 900 pages. It's not that big because we're paid by the page (actually, it is more like inversely proportional to the number of pages). It's that big because it is the natural size of what we wanted to say. We never intended it to be so big. We wrote the book because we had something to say and we wanted to say it. That's all.
Message-passing concurrency is *not* CSP. The former is asynchronous whereas the latter is synchronous. However, the book does mention CSP. See the index to find out where (hint: it is in the 'language' item). We do know CSP. I teach it in my semantics course and give its full semantics. But the book tries carefully to give a balanced view of a very big field. We have tried hard to put only the most practical and useful concepts in there, the ones that will last. If your favorite concept seems mistreated, we will likely have a good reason for it! Just send me mail to ask. Peter
Why, the LSP is known by many different names. :-).
The 'substitution property' for example.
Why not try actually *reading* the OO chapter
before giving such a sweeping judgement
Peter
'Forth done right', with nice semantics. But,
other than being implementable in just a few
kilobytes, what's the advantage of the Joy
approach? It seems to be a rather tortuous way
to write functional programs.
Don't get me wrong. I enjoyed immensely writing
Forth programs, especially since my machine only
had 4 kilobytes of memory
(it was an Elf II from 1976).
But if you have the
memory, why program in Forth (or Joy) nowadays
(except to have a little fun)?
I have programmed in both Forth and PostScript; they are incrementally compiled languages with a postfix syntax and no static typing. I never heard of the term "concatenative languages", can you give a good reference?
Peter
I'm one of the authors and of course I'm enthusiastic about the book, so don't take my word for it. My coauthor and I have been working on it for two years and we've taught courses from it. It distills ten years experience building the Mozart system.
Peter
I'm one of the authors, so don't take my word for it. We've been working on it for two years and we've taught from it. It distills ten years experience building the Mozart system.