Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Books Media

A New Bible For Programmers? 117

Posted by timothy from the squinty-little-eyes dept.
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?"
This discussion has been archived. No new comments can be posted.

A New Bible For Programmers? More

A New Bible For Programmers?

Comments Filter:

  • Newer Copy Available (Score:5, Informative)

    by erasmus_ ( 119185 ) on Wednesday June 18, 2003 @08:02AM (#6232262)
    I'm not sure why the article links to the April 26th draft version of the book, when the intro page itself has the link to the much newer June 5th version.

    http://www.info.ucl.ac.be/people/PVR/booksingle.pd f [ucl.ac.be]

    I look forward to reading it from the intro, however, might be really worthwhile.

  • So.. (Score:5, Funny)

    by dr ttol ( 674155 ) on Wednesday June 18, 2003 @08:10AM (#6232323)
    Does this bible also make the prediction that something huge will happen at the end of the millennium?

    • Re:So.. (Score:2, Funny)

      by Z0mb1eman ( 629653 )
      +1 Informative?

      *chuckle*

      Bad mods, no donut.
    • Computers will evolve into sentient machines and destroy human civilization as we know it...

      Or was that a movie I saw...

  • Google's Cached HTML Version (Score:3, Informative)

    by IdleMindUI ( 171872 ) <webmaster@nOsPaM.altavista.com> on Wednesday June 18, 2003 @08:16AM (#6232378) Homepage
    It appears that the site is already...umm...slashdotted. Google's cached HTML version can be found here. [216.239.39.100]
  • Anyone have it mirrored? I'd love to read/print it.

  • Very interesting, also for non-programmers (Score:5, Insightful)

    by tsa ( 15680 ) on Wednesday June 18, 2003 @08:27AM (#6232458) Homepage
    I am not a programmer but this seems to me a very interesting book for people who want to have a detailed yet general (hope you understand what I mean) idea of what's going on inside their computers as they are hammering their keyboards. Seriously, popular books on computer programming usually learn you how to use a certain programming language and not the concepts behind writing a computer program so this is a must-read for all people that want to learn to program computers.

    • What's going on in your computer (Score:1, Funny)

      by Anonymous Coward
      1010100001000001111110100110010100100010100010101 0 10101000000100000101001010100001000000000000111111 11111111111111100001000000000000000000000000000000 00000000000000000000111111111100000000110010000000 00111111111111111110000000000000111111100010101000 10000000010000111111111101111111110010100100101111 00100010100100000110010000000011110010001000010000 00001000111111100011101000100001000000000011111111 00100001001111111111100000011100100111011111111100 001111111111100000000000111111111100100
    • Excelent notice!

      Most of books (especially low-level programming, like Java, C, C++ and Perl) teach you how to code within one or another programming paradigm. Few books (especially high-level programming, like Lisp, Haskell, Erlang or Prolog) teach you what to code within functional or logical or constraint paradigm. But this book does teach you why to use one or another programming paradigm.

      Perhaps you are not a programmer, but you can become a real good one if you have noticed that now! Keep learning!

  • Another Bible (Score:5, Informative)

    by Ann Coulter ( 614889 ) on Wednesday June 18, 2003 @09:01AM (#6232813)
    Design Patterns [amazon.com].
    • I've got no mod points at the moment or I'd reverse the idiot who modded this offtopic.

      With luck, someone who does have points will jump in...

      -- MarkusQ

    • "Design Patterns" is something specifically targeted toward object oriented development. If you looked at the documented linked to in the article, you'll see that it covers the the entire wide-spectrum of programming techniques, of which OOP is just one small portion.

  • Already slashdotted? (Score:4, Informative)

    by stienman ( 51024 ) <.adavis. .at. .ubasics.com.> on Wednesday June 18, 2003 @09:02AM (#6232825) Homepage Journal
    The google cache of the pdf (converted to HTML by google) is here. [216.239.39.100]

    -Adam

  • OutDated? (Score:5, Insightful)

    by peripatetic_bum ( 211859 ) on Wednesday June 18, 2003 @09:04AM (#6232849) Homepage Journal
    since current de facto books about programming are aging with increasing speed


    I'm sorry to sound susppicious, but the concepts of programming are not out dated. The problem is tat programming has actaully become (or rather started out) incredible sophisticated and that a lot of programmers now have not been properly trained (be it by self study or a rigour CS program). And that flurry of programming books are more lke cookbooks and dont really *teach* anything anymore.

    I find it rather hard to believe that Knuth's analysis of algorithms of Sorting and Searching have/will become out dated. I think his title the ART of COmputer Programming was always incredible ironic because he has done more than anyone else to turn into a real science, which it is now, and by which I mean that it has hypothesis that can now be tested. His book lay the foundation for it and I doubt any new programming book, short of specilized computer journal articles have done much to advance programming.

    • Re:OutDated? (Score:4, Insightful)

      by Asprin ( 545477 ) <gsarnoldNO@SPAMyahoo.com> on Wednesday June 18, 2003 @09:30AM (#6233154) Homepage Journal

      I think his title the ART of COmputer Programming was always incredible ironic because he has done more than anyone else to turn into a real science, which it is now, and by which I mean that it has hypothesis that can now be tested.

      I disagree.

      Real science has proper control groups and reproducible results. Programming has neither.




      [/me grins, ducks and runs]

      • reproducible? Are you saying results cant be reproduced on computer? Im sure you are not saying that, please explain.

        Proper control groups? hmmm, are you thinking something like a placebo group? perhaps, but what I am thinking of is testing one algorithm against another, or using the say, a standard algorthm for sort (say, bubble sort) and being able to compare to another sort process and get empirical evidence (ie speed) of which one is better.

        I would say you have total control of the control group in

        • Re:OutDated? (Score:5, Interesting)

          by Violet Null ( 452694 ) on Wednesday June 18, 2003 @10:54AM (#6234098)
          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.

        • Re:OutDated? (Score:5, Interesting)

          by Asprin ( 545477 ) <gsarnoldNO@SPAMyahoo.com> on Wednesday June 18, 2003 @11:14AM (#6234289) Homepage Journal

          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?

          • BS in math, MA in physics

            How ironic that the definitions for the acronyms 'BS' (Bachelor of Science) and 'MA' (Master of Arts) are in direct contrast with the definition you give of the respective fields...

      • Real science has proper control groups and reproducible results. Programming has neither.?

        So, physics, chemistry, & astronomy, which don't have control groups, aren't science? Methinks you need to revise your definition of science to be more in line with what other scientists mean when they use the word "science".

        • PC&A all have control groups.
        • They do have a form of control. It is called a null hypothesis and is the assumption that there is no correlation between the variables being compared (hence things like Chi-square test). However, science is not just about hypothesis testing, it is also about observation.
      • Control groups? Reproducible results? It sort of sounds like you think science has to be empirical or it isn't science (and yes, I agree that reproducibility is importent, it just isn't the same issue for theoretical work).

        • Ultimately, yes, it does.

          The theoretical work is a critical component, but if we stop when the theory is finished and do not go into the lab to see if the model we have been working on is correct, we haven't done any science, just math.

      • science aims to understand some phenomenon; software science would try to figure out how to produce/test/maintain effective software. some of that happens in software engineering, but really, that's a bit of a misnomer, since software engineering is purely the application of what software science finds.

        ultimately, software engineering is just technique to a software artisan (programmer). a decent painter will study vision, brush-handling, art history in order to gain technique. but technique does not ma

    • Re:OutDated? (Score:3, Insightful)

      by egomaniac ( 105476 )
      I find it rather hard to believe that Knuth's analysis of algorithms of Sorting and Searching have/will become out dated.

      Really? When's the last time you wrote your own implementation of a search or sort algorithm?

      I haven't done so in a decade. Every language I use has built-in implementations which are more than fast enough for my purposes. Likewise with virtually all such basic algorithms -- they have been implemented, and generally very well, in libraries. Computers are fast enough now that even a

      • I Know How a Transistor Works! (Score:5, Interesting)

        by Sunlighter ( 177996 ) on Wednesday June 18, 2003 @12:58PM (#6235260)

        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.

        • The work of people like us makes the work of people like you possible. So: nyah nyah na-nyah nyah.

          Huh? I never said that I didn't know how a transistor (or parser, for that matter) works. I said that most people around here probably don't, and I'd still bet a hefty sum of money on that.
        • The work of people like us makes the work of people like you possible.

          I hope this was meant to be sarcastic. Everyone makes everyone else's work possible. Otherwise, there would be no such thing as an economy nor such a thing as progress.
        • Its obvious you have only a passing knowledge of transistors, and as such, couldn't truly comprehend what is going on in your computer.
          No talk of valence vs. conduction band, no talk of doping concentrations, no talk of electron current vs. Hole current; good sir, you have given semiconductor physics a slap in the face with your cursory knowledge! You're the type who'd forget body effects ignore adding a contact to the substrate! Phillistine!

          (P.S.- this is a joke. Laugh. Except for forgetting the substr

      • Re:OutDated? (Score:5, Informative)

        by Arandir ( 19206 ) on Thursday June 19, 2003 @01:11AM (#6240385) Homepage Journal
        Just like long division, there are times when you need to write your own search or sort algorithm. Why?

        1) Sometimes it's easier to write your own sort than to write a weird ass adaptor for your weird ass data.

        2) Sometimes "good enough" isn't "good enough" and you need that extra 15% performance increase you get for writing a search/sort customized for your data.

        3) Actually knowing how stuff works is good for the brain. After you learn basic bonehead algorithms, take some time to learn long division as well.

        4) Just to prove that you aren't a code monkey destined for the dustheap of history when you turn thirty.

      • I'm not saying that it is useless to know how sort algorithms work, but suggesting that it's relevant in the day-to-day work of a typical software developer (which is what you seem to be implying) is very misguided, in my opinion.

        On the contrary. In my experience, an awful lot of programmers, mostly those who are self-taught but don't realise what they're missing, frequently choose an incorrect data structure or algorithm even for simple things like sorting and searching. If you're working in a field wh

      • I'd wager that most folks around here don't, any more than they could write an implementation of QuickSort without having to look it up

        The trick is to use a truly high-level language, so the coding is trivial as long as you remember the basic algorithm:

        quicksort [] = []
        quicksort (x:xs) = quicksort [y | y <- xs, y<x] ++ [x] ++ quicksort [y | y <- xs, y>=x]
        • Actually, that (taken from "A gentle introduction to Haskell [haskell.org]"; cite those sources) is how I remember the basic algorithm.

          And I find the four line version found on http://www.haskell.org/tutorial/goodies.html [haskell.org] much more readable myself, but I tend to prefer short lines.
          • Actually, I don't know that that originates with "A gentle introduction to Haskell" - you can find that exact implementation in many other places, including in some Haskell distributions and many talk slides and college notes, and I happened to like it enough to memorize it, a number of years ago.

            The only reason I presented it on two lines was because of Slashdot formatting restrictions - I couldn't get indentation to work.

            Have I addressed all your concerns to your satisfaction?

    • Re:OutDated? (Score:3, Insightful)

      by oni ( 41625 )
      I find it rather hard to believe that Knuth's analysis of algorithms of Sorting and Searching have/will become out dated.

      It's too bad that you mentioned searching and sorting because it seems a lot of the other replies here jumped on that issue and completely missed your point.

      The Art of Programming isn't about either of those topics. It's about algorithms. Knuth uses seaching and sorting as a means to the ends of teaching the programmer to think about his algorithms. As other people have pointed out,

      • Re:OutDated? (Score:3, Insightful)

        by H*(BZ_2)-Module ( 536932 )
        I agree, and I think much of the misinterpretation comes because many are commenting on Knuth without ever having really read it. This comes from the introduction to TOACP.V3 2nd edition(which is from 1998 by the way, not so ancient):

        The title "Sorting and Searching" may sound as if this book is only for those systems programmers who are concerned with the preperation of general-purpose sorting routines or applications to information retrieval. But in fact the area of sorting and searching provides an i

  • ... we must not forget The Tao of Programming [google.com] by Geoffrey James.
  • It looks like it takes the /. crowd some time to go through nearly a thousand pages before they post comments.

    More interestingly, it seems may are actually RTFBing.

    Oh, I just hope no karma whore posts the book here. 8-)

  • Mozart & Oz in the book (Score:5, Informative)

    by joelparker ( 586428 ) <joel@school.net> on Wednesday June 18, 2003 @10:50AM (#6234057) Homepage
    The book uses the Mozart Programming System [mozart-oz.org]

    Mozart & Oz are well-developed and worth a look--
    your programming may improve because of them.

    Cheers, Joel

    p.s. here are quick excerpts:

    The Mozart Programming System is an advanced development platform for intelligent, distributed applications. The system is the result of a decade of research in programming language design and implementation, constraint-based inference, distributed computing, and human-computer interfaces...

    Mozart is based on the Oz language, which supports declarative programming, object-oriented programming, constraint programming, and concurrency as part of a coherent whole...

    We have developed many applications including sophisticated collaborative tools, multi-agent systems, and digital assistants, as well as applications in natural language understanding and knowledge representation, in scheduling and time-tabling, and in placement and configuration.

    • p.s. here are quick excerpts: ...

      Thankfully, modern marketing allows an important optimization to be made for improved code reuse:

      void output_platform_abstract( char* platform_name )
      {
      printf( "The %s Programming System is an advanced development platform for intelligent, distributed applications. The system is the result of...et cetera et cetera", platform_name );
      }

      This function is hereby released into the public domain, so authors everywhere can automatically generate the first chapter of their books.

      • Bet you can't write that in functional, OOP and declarative forms. ;-)

        • Bet you can't write that in functional, OOP and declarative forms. ;-)

          Well, for such a simple operation, it's mostly a trivial matter. In Lisp, I suppose it would be something like (stuff-output "blahblah"), and, in Java, it could be abstractGenerator.blurt("blahblah"). "Declarative" is a buzzword that I'm not intimately familar with, so I can't help you there.
    • I've read quite a number of programming textbooks. The authors of this book seem well-intentioned, and from a quick scan, the material is quite good.

      No, I haven't read it cover-to-cover yet, but I have a few first impressions:

      1. This is not a good introductory book for college freshmen. They're getting far too technical/formal way too fast... Don't get me wrong -- I'm a big fan of formalisms and good notation but for many students, this can interfere with the learning process.

      2. This oz language... I'm s

  • Oz (Score:5, Interesting)

    by thelenm ( 213782 ) <(mthelen) (at) (gmail.com)> on Wednesday June 18, 2003 @10:59AM (#6234154) Homepage Journal
    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. :-)
    • It doesn't just use constraints. It's simply possible to constrain variables over values. However, you don't need to specify a constraining range. The thing that lots of people find strange about variables in Oz is that they are single assignment. Once you've assigned to a variable, it's an error to attempt to reassign it. It's not such a big deal if you're used to working with functional (Lisp, Haskell) or logic languages (Prolog, Godel) but it takes some getting used to if you're from the side-effect side
      • strange about variables in Oz is that they are single assignment

        Then should it really be called a "variable"?
        • At the time you write your code you don't know the actual value of some symbols. It is varying depends on other run-time values. Thus it's called "variable".

          Your question shows that you don't know what is functional programming. To understand that I advise you to read "Why Functional Programming Matters" [nec.com] (HTML short version [auckland.ac.nz]).

          • Shall I say "duh"?

            It was a joke- of course I know about single-assignment variables. Have trouble writing all these compilers if I didn't.

            However, the post I responded to was pedantically incorrect. The claim "Once you've assigned to a variable, it's an error to attempt to reassign it" is false. After assigning a variable, you can assign it again- in a different function call.

            It's possible for a language to be functional even if it allows variable reassignment within a function- there's nothing wrong

    • Re:Oz (Score:1)

      by blate ( 532322 )
      See, this is why OZ is a toy language... and not a very useful one at that.

      Sure, you can do some really nifty things with it. But that's like learning machining on a CNC machine... you feed in a CAD drawing and out comes your part. The problem is, when you go to work at a machine shop where they use lathes, mills, etc., you're going to have to relearn many things before you become a useful worker.

      The argument could be made that, perhaps, modern production languages should include "contstraints" and other
      • 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.

  • Note about the Oz language (Score:5, Insightful)

    by Anm ( 18575 ) on Wednesday June 18, 2003 @11:08AM (#6234242)
    For those curious why this books uses Oz as it's language of choice, it is one of the few, if not the only language, to support the many popular paradigms of programming:
    * procedural, like C & BASIC
    * object-oriented, like Ada & Java
    * functional, like Scheme & Haskel
    * declarative, like Prolog

    It that way, this book is a good way to keep your mind open to different approaches to doing things.

    Anm
    • May I add

      * concurrent like Erlang [erlang.org]
      * distributed like Erlang [erlang.org]
      * functional like Erlang [erlang.org]

      and point to some comments by the Erlang crowd [erlang.org]

      Regards,
      Marc

      • 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 practica

    • Ack! You said "Scheme". I understand that scheme is a great teaching tool (I've taken classes that use it), and that it is extremely well formed for doing things like proving algorithms and such. But when you try to do anything else... I think my girlfriend put it best when she said, "Scheme is like Victoria's Secret. It's supposedly very elegant, but really it's just dirty."

  • hmm (Score:4, Interesting)

    by rpeppe ( 198035 ) on Wednesday June 18, 2003 @11:48AM (#6234555)
    I'm a bit dubious about a book that talks about the "substitution property" of objects without once mentioning Liskov's [mit.edu] substitution principle [objectmentor.com], or that talks about message passing concurrency wthout mentioning Tony Hoare's CSP [usingcsp.com].

    Is this book really as authoratitive as it tries to appear?

    • It is a draft copy, and there is contact info on his site, why not let him know that?

    • Re:hmm (Score:2, Interesting)

      by KZigurs ( 638781 )
      Most probably no. But then - what is? If it would pretend to be JustAnotherBookFromThatLibrary noone would be interested to read it. And as for the contents - anything may miss something, but if it is good writen, easly readable and actually lets you have a look from a different perspective - it very well may be worth reading. :D

    • Is this book really as authoratitive as it tries to appear?

      I had a quick scan over it, and while I'm reluctant to judge on first impressions, I couldn't help feeling that it had a lot of breadth but not much depth. It struck me as somewhat similar in style to the wizard book [mit.edu], though obviously with wider coverage.

      I had the same immediate reservation as you did: the OOP section seemed weak compared to established "classics" in the field. Failure to mention things like LSP is unforgivable in a book aimin

      • 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

        • Why, the LSP is known by many different names. The 'substitution property' for example.

          What they called the "substitution property" is a waffly version of Liskov's clear and concise principle.

          Why not try actually *reading* the OO chapter before giving such a sweeping judgement :-).

          I appreciate the smiley there, but OK, I've now read the first half of the OO chapter in its entirety. Not only does it fail to mention the LSP in any useful way, it also fails to stress the interface/implementation sep

          • ...I'll apologise now for the perhaps overly harsh tone of the parent post. As I noted in my original reply, there seems to be a lot of worthwhile material elsewhere in the book. I'm afraid I really don't like your presentation of OO, though.

            Programming is my full-time job, and I use this stuff (and other programming styles you mention) all day. I also teach it to newbies from time to time. At that level, I've found that it's vital to get across concepts like invariant/pre-/post-conditions, and the focus

          • Ok, let me take the technical points one by one.
            • 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 la

            • Thank you for taking the time to post a calm and informed reply. I probably didn't deserve that after taking your original reply the wrong way and flaming it. To return in kind...

              I understand that you are considering the wider picture throughout the book, and that your chapter on OO is considered within that framework. In fact, I very much like your "kernel language" approach, and the emphasis you place on commonality; I have no disagreement with that principle at all.

              I think my big objection to your pr

              • 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.

          • Hello, I would like to complement Peter's message at a higher level. First we are very happy that a lot of people appreciate the book. Also we are open to all critique and would like very much to improve the material further. About the chapter of object-oriented programming. The whole idea of the book to try to give a deeper understanding of the relationship between different programming models. To make clear how different models augment each other. What is the distinctive feature of each extension. We also
    • 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 mistre
      • See the index to find out where (hint: it is in the 'language' item).

        Aside from the CSP issue, I feel that those index semantics are questionable. If you are going to include an index, please make it a comprehensive one. I have no problem with including "CSP" under "Language" in the index, but it must have its own entry too! I had looked for CSP quite hard - I looked up every mentioned reference to "Hoare"; I checked the bibliography (it was mentioned, but no back reference). To find an item in the index,

        • Re:hmm (Score:1)

          by seif ( 683150 )
          Commenting on the consumer would quickly exhaut memory. You are quite right. This issue is addressed in Chapter 4 of declarative concurrency. --- Seif

  • But don't look for... (Score:5, Interesting)

    by sohp ( 22984 ) <snewton.io@com> on Wednesday June 18, 2003 @07:05PM (#6238417) Homepage
    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.
    • 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 t
  • It certainly won't be the bible of the programers who think java is a good language, and it won't suit the people who trust the people who built Rational Rose to teach them how to make software. I had the chance to work with PVR when he was working for digital (hey peter!), before digital collapsed, and, though i have yet to start reading the boook, I expect some serious coding kung-fu!
    • "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.
  • I just looked at the section on Object-Oriented programming. I haven't read much of it, but just about everything I have read is wrong or confused. They continue this common misconception that objects are a form of ADT (abstract data type) and the inheritance is the only important concept in object-oriented programming. Some examples of their confusion: "We can loosely define object-oriented programming as programming with encapsulation, explicit state, and inheritance." On inheritance: "... stateful abst
    • Ok, we can make two points:
      • 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 t

      • I don't know if the original poster is correct in claiming your text to be wrong on the subject of OOP. However, the idea (not sure whether he claims it to be yours) that inheritance is the most important aspect of OOP is misleading. Without the two other pillars, proper OOP simply cannot stand.

        I haven't read your text. Although, I plan to. I can understand how someone reading something out of context (especially when a subject is only fully explained across several chapters) may make a claim of confus
        • We agree with you completely. But please do not read chapter 7 out of context. The book is a complete story that is being built successively. Encapsulated state and what you call polymorphism are actually covered, but not in this chapter. In fact inheritance creates more complication in the sense that makes necessary the introduction of many other concepts that is being covered in this chapter (Chapter 7). Encapsulated state is all over the book. In particular Chapter 5 already introduces a simple concurren
      • I have skimmed a lot of your book and studied the sections discussed below in some detail. Pages 240-255:

        You are using the term "abstract data type" in a dynamic language, and this doesn't make very much sense. The original idea of a user-defined abstract data type is that one can define a new type that works just like the built-in types "integer", "char" in Pascal. The idea is that the type is abstract in that the implementation is hidden.

        Now I agree that your idea of "secure abstract data type

Slashdot Top Deals

Whoever dies with the most toys wins.

Close