Slashdot Mirror
A New Bible For Programmers?
KZigurs writes "The wonders of online publishing... If you are ready to take on a heroic task and read thru all 976 pages of Concepts, Techniques, and Models
of Computer Programming (draft) (pdf file, 3MB, intro here) written by Peter Van Roy and Seif Haridi you won't regret it. Just finished reading it and I feel like I have read the Bible. And who knows? It has the potential, and since current de facto books about programming are aging with increasing speed it very well may become one. (Please read the intro to get more detailed outlook at topics covered)
Anyone before heard about Oz?"
Anyone before heard about Oz?"
I think (hope) you're just pretending to be sarcasm-challenged when taking the parent post seriously.
But, now that I'm on the subject...
Once you've gotten your first non-reproducible bug, you'll see what the parent poster was talking about with reproducible results. An awry pointer can cause all sorts of havoc that's incredibly difficult to track down, and, even worse, it often won't break the same way twice.
As for your example of algorithms: "better" is rather subjective, especially in regards to sorting algoriths. Although quicksort might be faster for general purpose use, there are plenty of algorithms that can beat it in certain conditions. And, programming being what it is, you can never be sure that your program will be running under those certain conditions or not.
Yep, we had to use Oz in a Programming Languages & Semantics course I took in grad school. All I really remember is that it used "constraints" rather than "values" for variables. For example, a variable doesn't necessary contain a single value, but it might contain the constraint "greater than 100, less than 2000". And you can do all kinds of stuff with intersection and union of constraints, and... ahh, that's all I can coerce out of my brain. I thought I had repressed it forever. :-)
Use Ctrl-C instead of ESC in Vim!
Well, I was actually making an ironic joke, but since you ask, I can certainly give it another shove closer to the edge of the cliff, so to speak.
First, let me say that I was actually serious when I said that programming (just like mathematics and logic) is not science.
This opinion was not formed without a fair amount of consideration (BS in math, MA in physics). We could argue semantics for many moons, but my definition of a "science" goes something like "A course of inquiry which employs the proper scientific method: only ask questions you can actually answer, employ direct empirical observation with proper control groups, verify the results independently (one trial does not a conclusion make), and reserve nature as the authority - you must maintain a complete willingness to be proven wrong."
Mathematics, Programming and Logic work this way because they conform to a different kind of rigor for validation -- namely, constructive or analytical "proof", which is not, by its nature, empirical. I'm not trying to refute, denounce or demean non-scientific studies, I just want to point out that "scientific" means something specific, and it does not apply to those other areas I mentioned.
BTW, one pet peeve of mine is when in sci-fi movies, the dude says "There has to be some kind of scientific explanation for this." Well, no: METHODS are scientific, not explanations.
Also, please note that many areas of study: Psychology, Sociology and Political Science (as well as certain areas of Biology and Chemistry -- needle, needle, jab, jab, ha-ha!) *could* be scientific in some cases, but typically aren't because they are populated by dumb researchers employing horribly poor experminental and analytical techniques.
So, having said that, I will conclude with the "on-topic" tongue-in-cheek gags:
Reproducibility: (In WRITING programs, not running them)
Since all developers on a project typically work from the same source tree, no programming results have ever been independently verified except the programming assignments in textbooks.
Control Groups:
Well, maybe you have a point on this one. I suppose a NOP loop would qualify as an effective control, but how do you halt the experiment?
"Lawyers are for sucks."
- Doug McKenzie
Is this book really as authoratitive as it tries to appear?
There are two kinds of transistors, bipolar junction transistors and field-effect transistors. Bipolar junction transistors are sandwiches made from two layers of N-type silicon separated by a layer of P-type silicon. A bipolar junction transistor has three terminals: an emitter, a base, and a collector. The emitter and collector are connected to the N-type silicon (on opposite sides of the sandwich) and the base terminal is connected to the P-type silicon. When a small voltage is put on the base terminal, current is allowed to flow from the emitter to the collector. (This is for an NPN-type transistor. There is also a PNP type which is the opposite and works with negative voltages instead of positive.)
A field-effect transistor has three terminals, too, but they are called the source, the gate, and the drain. The source and the drain are connected by a channel made of N-type silicon, but the channel is somewhat narrowed by P-type silicon in the middle which is connected to the gate terminal. When you put a voltage on the gate, it creates an electric field which chokes off the current flow from the source to the drain. There is also a type of field-effect transistor with a channel made of P-type silicon, and the voltages are negative.
I have done better than implementing a sort algorithm; I implemented keyless 2-3 trees in a functional style and thus speeded up my LR(1) parser generator from 27 minutes to 4 minutes.
The work of people like us makes the work of people like you possible. So: nyah nyah na-nyah nyah.
Sunlit World Scheme. Weird and different.
Based on reading the Preface and a brief scan of the table of contents, this book is interesting for what the authors do not cover, by design. Nothing on static typing, nothing on algorithms, AI, databases, or numerical techniques.
To some, leaving these topics out of a "bible" would amount to extreme heresy. The content of this book owes more of its lineage to The Structure and Interpretation of Computer Programs than The Art of Computer Programming.
- 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.