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?"

Comments

Newer Copy Available

[erasmus_]

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

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

So..

[dr ttol]

Does this bible also make the prediction that something huge will happen at the end of the millennium?

Re:So..

[Z0mb1eman]

+1 Informative?

*chuckle*

Bad mods, no donut.

Re:So..

[confused one]

Computers will evolve into sentient machines and destroy human civilization as we know it...

Or was that a movie I saw...

Re:So..

[Anonymous Coward]

What Bible are you referring to as making a prediction about "something huge" at the end of the millenium? If you mean the Holy Bible, there is no prediction about the end of the millenium in there. There are lots of prophecies, and events have shown those that have elapsed to be 100% correct.

But far more important that that is the principle message of hope and love which permeates all of scripture. Recognized that God is a Holy God, cannot allow sin in His presence, and that we can only spend eternity with Him by accepting His free gift of grace. For more information see here.

Re:So..

[DrunkEvilPenguin]

It was a joke, not a religious comment. And I seriosly doubt that many bible prophesys have come true. Either the prophesys would be very vague so they could be applied to many, many situations, or people stretch things all out of shape to try and make them fit. Bah, now you've got me going off on a rant :) Although I'm sure my alcohol played it's part :P

Re:So..

[Anonymous Coward]

Prophecies that came true are ones like a person named Cyrus would attack and take over the city of Babylon (universally thought to be impregnable at the time). When showed his name in a scroll at the time, he granted the Jews' request to sponsor rebuilding the temple in Jerusalem.

Or like Daniel's interpretation of Nebuchadnezzar's dream, which described exactly the swift rise and success of Alexander the Great (not by name, but by his country). And the subsequent breakup into four zones run by his generals, and the wars between them for several centuries until Rome appeared and conquered all. The amazing accuracy of Daniel caused many skeptics to disbelieve it could have been written when it claimed it was. Problem with the skeptical point of view is that it was translated into Greek long before Alexander, and that translation has the same prophecy in it.

The Bible has been doubted time and again, check out the story of Sir Walter Scott. He was determined to prove the Bible inaccurate by examining all the minute details Luke gave in his gospel. By the time he was done, he had proven every point he doubted, and he became a believer.

Only the Bible has been proven accurate every time. Many doubted based on mention of a people called the Hittites. Then proof was unearthed showing they existed at the time mentioned.

If you want to check it out yourself, one source book is "Many Infallible Proofs", ISBN is 0890510059 at your favorite source, whatever that is.

Re:So..

[Anonymous Coward]

>> Recognized that God is a Holy God, cannot allow sin in His presence...

If he doesn't like sin, then why the fuck did he *invent* it???

This is not a troll-- I really do want to know!

Re:So..

[Anonymous Coward]

He didn't invent sin. Satan, previously known as Lucifer, was created perfect, but iniquity was found in him. In his case, pride was his sin. From Satan came the temptation and sin of man, and we haven't stopped yet. Who taught you how to lie? Just came naturally didn't it - we have a sin nature.

As to why God created the universe, knowing that sin would result, that's a deep question which has only speculative answers. One that chimes for me is:

God is a being of love. He could create beings that had no choice but to love Him, but that's not love, is it? So He created us with free will and choice as to whether we would love Him. Tragic as it is, many choose not to. But some do, and that love is not forced, but is freely given, and nothing is worth more than love freely given.

There are several things God cannot or will not do. One is learn - He is omniscient, so He can neither learn nor be surprised nor disappointed in us. Another is He will never force us to love Him. He values our freedom too much perhaps, or He values love that comes freely too much.

Frankly, since He is so far beyond our knowledge and comprehension to grasp fully (He is after all outside time, since He created time and space) I think there is a whole lot more to it than that.

Realizing His infinite nature, there are things we just won't grasp. Like how He created everything but is not the author of sin. Or the trinity - as is frequently said, we can apprehend but not comprehend it.

Re:So..

[miu]

Not sure why I'm feeding the trolls, but what the hell, I'm drunk.

There are several things God cannot or will not do. One is learn - He is omniscient, so He can neither learn nor be surprised nor disappointed in us. Another is He will never force us to love Him. He values our freedom too much perhaps, or He values love that comes freely too much.

And Hell would be a reflection of that how? Eternal torment is too extreme a punishment for any sin humankind is capable of committing. How does "love me or be destroyed" fit into the plan of an all knowing god of love? Theocracy and Monarchy are implicit in all the beliefs of Christianity, only God is capable of providing rulership we can live by. So God created us without the ability to rule ourselves and let a vastly superior being (the Devil) lead us into sin. What sort of father would allow something like that to that happen to children he loves? I don't buy it. If God exists I certainly want nothing to do with him.

Re:So..

[Anonymous Coward]

You drew a conclusion:

Eternal torment is too extreme a punishment for any sin humankind is capable of committing

While that may be true from your point of view, the view of a Holy God, even you must admit, would be from a different perspective.

There is an offer of grace freely given; ignoring it and choosing otherwise is the worst mistake you can make.

You further drew a conclusion that Theocracy and Monarchy are inherent in Christianity. That is quite incorrect; read the gospels (Matthew, Mark, Luke, John) and see what Jesus thought of the Pharisees and other members of the Sanhedrin (the theocracy of the time).

You then further assert that we sin because a powerful devil leads us into it. Really? Who taught you to lie, did Satan appear to you and lead you step by step through the process? How powerfully did he tempt you? Or did it just come naturally? We are fully capable and practiced at sinning mightily without need for temptation. Personally I think Satan tries to tempt Christians to weaken their testimony, and that he works on non-believers to keep them thinking like you are - dismissing God and saying things like

I don't buy it. If God exists I certainly want nothing to do with him.

For those readers who are not as closed-minded, please please click here for more information.

Re:So..

[Anonymous Coward]

I'm sure other people are not interested in reading this, so I'll respond AC.

You further drew a conclusion that Theocracy and Monarchy are inherent in Christianity. That is quite incorrect; read the gospels (Matthew, Mark, Luke, John) and see what Jesus thought of the Pharisees and other members of the Sanhedrin (the theocracy of the time).

I've read the gospels a couple times. Jesus did not speak against the Pharisees and Sadducees because they were part of the theocracy, he spoke against them because they added unnecessary things to the Law, gave no comfort to the people, were hypocrites, and did not want to recognize him as the promised messiah. The Law made provision for the priest class and upkeep of the temple, creating the theocracy in the first place.

Read the Lords Prayer for an example of the promised Monarchy. Jesus himself was to be a king (that was the excuse given for executing him) descended of the line of kings established by David. The 'second coming' is the point at which he will come into his kingdom.

I'd go beyond stating Christianity to be merely pro-monarchy, and state that it is anti-democracy as well. The Democracies of the U.S. and U.K. are refered to in Revelations as 'having two horns like a lamb, but spake as a dragon'. All these 'wild beasts' (human governments) are to be destroyed by god.

You then further assert that we sin because a powerful devil leads us into it.

I did not claim we sin (or that Adam and Eve sinned) because 'the Devil made us do it'. I said that a father who allows an older and wiser being to influence his children into bad actions is not a good father.

As to God's view vs. mine on the fitness of Hell as punishment for unrepentant sin, if God has a viewpoint that makes everlasting torment reasonable then I don't want to understand that viewpoint or the being that holds it.

Re:So..

[Anonymous Coward]

Perhaps you missed a couple of points in the gospels. The Sanhedrin was the religious governance body, empowered by the Romans to have a fair bit of civil control. So the Sanhedrin was the theocracy. And the members of the Sanhedrin were the Pharisees and Sadducees. The Levites were the ordained priests, and there were certainly Pharisees who were not of the tribe of Levi. In fact only some of the Levites were eligible to be priests. Compare David, of the tribe of Judah, who was the King. He had a high priest, but that priest was not answerable to him, only to God. That is not a theocracy. Paul for example (Saul at the time) was a Pharisee of the tribe of Benjamin, therefore not eligible to be in the priestly line.

The "Lord's Prayer", as it is commonly called, should more rightly be the "disciples' prayer" as it is the model prayer that Jesus gave the disciples when they asked to be taught how to pray. The Lord's prayer is in John 17, where we see Jesus praying. But enough pedantic points, yes Jesus is going to be the King of Kings in the coming Millennial kingdom. However that is when the earth has been transformed back into a pre-cursed state; the lion will lay down with the lamb, etc. I personally find it a bit hard to see that time as it will be so radically different than the world we currently live in. And after all, Jesus Christ is Lord, so having Him as King ruling with a rod of iron means we will have an incorruptible King, dispensing perfect justice. To say that's different from today's governments is a bit of an understatement.

You make mention of a book of Revelations, the book is the Revelation of Jesus Christ if you mean the last book in the Bible. Your claim that the US and UK are the two horns is not one of the commonly accepted interpretations; if you would really like to get into Revelation there are several commentaries I can suggest that make great sense of it.

It's tragic that you're choosing to be separated from God; I will pray for your reconsideration.

Re:So..

[badman99]

While you are at it go pray for all those who have suffered under the stains of 'organized religion'. Seems to me the only people that truly embrace religion, want to control others or feel they are 'better' simply because they say they believe. Or as I have personally experienced, abuse children within an institution that protects the perpetrator simply because they don't want to disgrace the institution. I honestly believe that the pursuits of religion have caused more harm than good to the human race as a whole. Have a think about our history Tom

Re:So..

[Anonymous Coward]

You may be surprised to know that I absolutely agree with you.

Organized religion, denominations, are some of the things that the Lord Jesus Christ was most stridently opposed to when He walked the earth. His comment on the nicolaitans (nico=rulers, laitans=laity, hence rulers of the laity, hence non-local church governance) in Revelation 2:6 is quite revealing.

One of the largest examples of a so-called church that Jesus hates is the Roman Catholic Church; in Revelation 18:4-5 He says "Come out of her, my people, that ye be not partakers of her sins, and that ye receive not of her plagues. For her sins have reached unto heaven, and God hath remembered her iniquities" in reference to the RCC. Not too surprisingly, the RCC and those churches ecumenically allied with the RCC strongly object to that interpretation, but scripture is pretty clear on that identification. What other church is headquarted in a city of seven hills (as Rome is uniquely called throughout history from the time the Roman Empire existed through now).

And the Catholic church sponsored the Inquisition and the Crusades, in direct opposition to the teachings of the Bible. They aren't (most unfortunately) the only apostate church around, but they are the one most clearly identified in scripture in a hugely negative way.

Google's Cached HTML Version

[IdleMindUI]

It appears that the site is already...umm...slashdotted. Google's cached HTML version can be found here.

Ug, /.ed already.

[Randolpho]

Anyone have it mirrored? I'd love to read/print it.

Very interesting, also for non-programmers

[tsa]

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.

Re:Very interesting, also for non-programmers

[axxackall]

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!

What's going on in your computer

[Anonymous Coward]

10101000010000011111101001100101001000101000101010 10101000000100000101001010100001000000000000111111 11111111111111100001000000000000000000000000000000 00000000000000000000111111111100000000110010000000 00111111111111111110000000000000111111100010101000 10000000010000111111111101111111110010100100101111 00100010100100000110010000000011110010001000010000 00001000111111100011101000100001000000000011111111 00100001001111111111100000011100100111011111111100 001111111111100000000000111111111100100

Re:What's going on in your computer

[bobv-pillars-net]

Why, oh why does the above gets past the lameness filter?

(Especially when a couple of lines of perl typically don't)

Re:What's going on in your computer

[pyman]

I think thats a very interesting statement about the readability of perl!

Another Bible

[Ann Coulter]

Design Patterns.

Re:Another Bible

[Junks Jerzey]

"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?

[stienman]

The google cache of the pdf (converted to HTML by google) is here.

-Adam

OutDated?

[peripatetic_bum]

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?

[Anonymous Coward]

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

Hopefully encapsulated in STL and class libraries by now.

Re:OutDated?

[Asprin]

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]

Re:OutDated?

[peripatetic_bum]

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 your testing. again please explain as I think I missed our point, but am interested in what you trying to say.

G

Re:OutDated?

[Oscaro]

Gnahhhrrrrg I keep hearing this argument over and over. But knowing how to do things right (and why) is the ONLY way to survive to new problems and situations that the STL does not solve.

That's one of the reason I hate Java. Its huge library lets you write programs without having to learn or understand what the hell you are doing.

Thanksfully, when I learned to program, I had to code my own hashtables.

Re:OutDated?

[Tablizer]

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

I don't know about you embedded and systems folks, but we use a database to do that stuff now. Lacking are teaching guides that tell how to use a database properly and effectly within an application. I am not saying that building sorts is useless knowledge, but its priority is dropping IMO.

Re:OutDated?

[Violet Null]

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?

[Asprin]

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?

Re:OutDated?

[Ivan the Terrible]

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

Re:OutDated?

[Tattva]

I don't know about you embedded and systems folks, but we use a database to do that stuff now. Lacking are teaching guides that tell how to use a database properly and effectly within an application. I am not saying that building sorts is useless knowledge, but its priority is dropping IMO.

I understand where you are coming from and if you catch me in the right mood I might agree (almost) without reservation, but I have some doubts. There are certain programming tasks that just can't be solved with a predefined (even configurable, templated) data structure and a set of predefined and configurable algorithms associated with that structure.

Dynamic programming is an example (see "Introduction to Algorithms," Cormen et al, chapter 6.) Dynamic programming is a method of solving problems that have numerous subproblems that can be solved optimally on their own terms, but in the recursive definition of an ideal solution are consulted multiple times, usually leading to exponential behavior based on the number of the smallest subproblems. Dynamic programming is defining a recursive definition of the ideal solution and then finding the optimum subproblems in a bottoms-up manner to avoid the duplication of effort a recursive solution entails. Maybe I'm dumb but I can't imagine a way to encode a general solution to the analysis that is necessary to recursively characterize the optimal solution. The table containing the optimal values can be standard storage type, of course.

But the algorithms not included in helper libraries are used less than those that are. Some concepts, such as just about everything in AI, have a very limited applicability, but I think if you sum up the problem sets that can be addressed by advanced techniques, the teaching of these techniques is still a necessary part of a computer science education.

Like I said, I waver on this, partly because I wonder if my analysis isn't influenced by an emotional prediliction for a deep understanding of the fundamental math of computer programming. I am an intuitive thinker and like to understand the whole forest before I prune a single limb.

Many people successfully maintain and develop websites, databases, and enterprise application software where their only real skills are GUI design, project management and software design process practices, and some factoring ability. These software systems may be brittle and not very scalable, but they satisfy customer needs and they were developed relatively quickly.

Re:OutDated?

[egomaniac]

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 "good enough" general implementation of an algorithm is more than fast enough in virtually every case (and for the other cases, that's when you need to haul out the books).

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. In the same vein, most programmers couldn't explain how a transistor works if their lives depended on it, and I don't see that as such a huge problem, either.

Just out of curiosity, do you know how a transistor works? 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.

Re:OutDated?

[Asprin]

PC&A all have control groups.

Re:OutDated?

[oni]

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, a modern programmer is unlikely to implement either a search algorithm or a sort algorithm. But they use other algorithms to every day. They invent algorithms every day.

The core of programming is ability to examine a problem and create algorithms to solve it. That's what programmers do (unless of course we're talking about VB programmers doing little more than connecting an interface to a control). At any rate, Knuth teaches algorithms - not searching and not sorting.

The bottom line is, Knuth's work is still relevant and quite useful.

Re:OutDated?

[mikiN]

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

Re:OutDated?

[JanneM]

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

Re:OutDated?

[Asprin]

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.

Re:OutDated?

[neuroneck]

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.

Re:OutDated?

[Anonymous Coward]

Yeag, sure you learned to code your own hashtables.

They probably degenerate to lists with the write data.

It all depends on whether you want to learn to program or have good code.

It all depends on how big a project you want to work with or how long you want to spend writing hash tables again, or arguing over whose hash table to use in the next collaboration.

Re:OutDated?

[Tablizer]

There are certain programming tasks that just can't be solved with a predefined (even configurable, templated) data structure and a set of predefined and configurable algorithms associated with that structure.

I never suggested that the database or query language do everything. I often find that I can get it to do the majority of it, with some local filtering and processing to get the rest. Whether it would help with AI stuff, I don't really know. There are many ways to slice a cat. Most people are not (currently) employed in AI anyhow.

I guess what I am really complaining about is that the education often focuses on low-level stuff, when high-level design and tools seem to be ignored. I think relational is one of the best tools ever, but it is often a 3rd-year subject in many schools.

Re:OutDated?

[Arandir]

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.

Re:OutDated?

[H*(BZ_2)-Module]

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 ideal framework for discussing a wide variety of important general issues: How are good algorithms discovered? How can algorithms and programs be improved? How can the efficiency of algorithms be analyzed mathematically? How can a person choose rationally between different algorithms for the same task? In what sense can algorithms be proved "best possible"? How does the theory of computing interact with practical considerations? How can external memories like tapes, drums, or disks be used efficiently with large databases? Indeed, I believe that virtually every important aspect of programming arises somewhere in the context of sorting and searching!

Re:OutDated?

[Anonymous Coward]

Books like this are more suited to people who want to create a DBMS. People who just write queries don't have to learn nearly as much.

Re:OutDated?

[Zeriel]

One can desire to understand how a good hash table algorithm works without coding their own (except as an exercise in understanding, perhaps?)

Re:OutDated?

[Anonymous Coward]

I thought BS was an acronym for bullshit, as in everything you read on slashdot.

And of course...

[tcak]

... we must not forget The Tao of Programming by Geoffrey James.

+1 Ontopic on the MQR standard

[MarkusQ]

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

So few comments...

[Kopretinka]

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

[joelparker]

The book uses the Mozart Programming System

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.

Re:Mozart & Oz in the book

[pmz]

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. Enjoy!

Re:Mozart & Oz in the book

[Anonymous Brave Guy]

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

Re:Mozart & Oz in the book

[pmz]

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.

Re:Mozart & Oz in the book

[blate]

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 sure it has many technical merits, but it's so unlike any other language used in production shops (e.g., C, C++, Java, VB, perl, TCL, etc.) that its pedagogical (sp?) value outweighs its lack of practical value. CS students, IMHO, need to come away with two possibly divergent sets of knowledge.

a. A solid knowledge of constructs, algorithms, engineering techniques, and good programming habits.
b. A solid syntactic and semantic understanding (ability to code well) of at least one major programming language.

My first CS class was taught in Haskell; the second class was taught in Turing. Both are great languages in their own right... but it took me a while to become as clean in C/C++ as I was in Turing, for example. On one hand, I am grateful for the good habits I acquired learning these "toy" languages. On the other hand, I would have been a more useful programmer faster had I learned these things in C/C++/Java.

Aside from that argument, I think oz is just ugly and rather cumbersome in its syntax. In particular, I'm not a big fan of implicit return statements, e.g., foo(x):= if x>0 1 else -1... I like to see explicit returns... I like explicitness whenever possible. It makes the code easier to read and understand.

That's my opionin, at least.

Again, I think this book has great value.. I am going to read it carefully. As a seasoned programmer and a life-long student in the art/craft/science of programming, I'm sure there are a few gems of realization to be found therein.

Oz

[thelenm]

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. :-)

Re:Oz

[ctrimble]

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 of the street. The other strange thing is the representation of strings as lists of characters. Weird.

One of the cool things about Oz is that you can solve the eight queens problem in a declarative fashion in about a dozen lines of code. You simply specify the constraints and let Oz figure it out.

Re:Oz

[Minna Kirai]

strange about variables in Oz is that they are single assignment

Then should it really be called a "variable"?

Re:Oz

[axxackall]

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" (HTML short version).

Re:Oz

[Minna Kirai]

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 with the compiler silently appending _1 _2 _3 as you change the definition of XYZ during a linear sequence of code. This could be said to introduce an unneeded distjunction between what is written and what is meant, though.

However, some functional languages (to be more attractive to mainline programmers?) include iteration operators, even though such things are redundant with recursion. If "forall" or something is present, or if there is a semantic to assign a variable within a function argument, then it's important that programmers not think they can use a variable as an accumulator, which is what reassignment within a loop implies.

Re:Oz

[blate]

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 such formalisms. Well, gang, perhaps you're right. But they don't. It seems like Oz would be great for use in a theory course... but if your goal is to graduate competent, skilled programmers who have a chance of actually getting a job in programming, they need to know at least one, preferably 2 or 3 modern production languages.

End rant...

Re:Oz

[Peter Van Roy]

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

[Anm]

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

Re:Note about the Oz language

[Anonymous Coward]

Mathematica's programming language is like that too... you can code a problem in many ways, and you can code it concisely and tersely or verbosely with lots of LongFunctionNames.

quotes

page from the tour

It's an awesome language but hardly anybody uses it to the full potential (of course since it only comes with $hundreds software package that might have something to do with it....)

Re:Note about the Oz language

[mvw]

May I add

* concurrent like Erlang
* distributed like Erlang
* functional like Erlang

and point to some comments by the Erlang crowd

Regards,
Marc

Re:Note about the Oz language

[Peter Van Roy]

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.

Re:Note about the Oz language

[CrazyWingman]

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

Mirror Here

[Bluetrust25]

It's mirrored here courtesy of SurveyComplete.

Incedentally, I highly recommend the book Code Complete: A Practical Handbook of Software Construction by Steve C McConnell. It tought me more about programming than the rest of my computer book bookshelf!

Another great resource is Safari. It's a web service that for a fee, allows you to view O'reilly, Que, and Sams books online. I find the code search feature to be invaluable. Cheap way to read technical books.

Re:Mirror Here

[Randolpho]

Thank you. :)

hmm

[rpeppe]

I'm a bit dubious about a book that talks about the "substitution property" of objects without once mentioning Liskov's substitution principle, or that talks about message passing concurrency wthout mentioning Tony Hoare's CSP.

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

Re:hmm

[Kevin Stevens]

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

Re:hmm

[KZigurs]

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

Re:hmm

[Peter Van Roy]

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

Re:hmm

[rpeppe]

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, one should not have to know what context to find it in: that's the job of the Contents page!

Out of interest, using your ports paradigm, is it straightforward to have some flow control without making the protocol synchronous? When writing concurrent programs, I've often found pipeline and tree structures to be useful, but presumably if one were using asynchronous ports, a producer that's consistently faster than a consumer would quickly exhaust memory as space for all those unconsumed messages was allocated.

Re:hmm

[seif]

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

I Know How a Transistor Works!

[Sunlighter]

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.

Re:I Know How a Transistor Works!

[egomaniac]

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.

Re:I Know How a Transistor Works!

[Sunlighter]

Well, now they know...

...and please substitute "them" for "you" in my last line.

Re:I Know How a Transistor Works!

[pmz]

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.

Re:I Know How a Transistor Works!

[mekkab]

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 substrate contact- thats no joke, the first mistake every rookie EE makes. Even if you tie it to the drain, you GOTTA have it. )

Re:I Know How a Transistor Works!

[Tumbleweed]

> Everyone makes everyone else's work possible.

Oh yeah? I _guarantee_ you my work doesn't make your work possible. Or your money back!

Re:I Know How a Transistor Works!

[Anonymous Coward]

NERD!

*hug*

Re:I Know How a Transistor Works!

[Zork the Almighty]

Well, they would know, if they bothered to read it.

But don't look for...

[sohp]

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.

Re:But don't look for...

[Peter Van Roy]

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.

Re:But don't look for...

[sohp]

Congratulations to you and your colleague, Mr. Haridi, you've done a fine job.

Re:Kneejerk reaction

[jason_watkins]

all depends what those 1000 pages are full of. If it's 1000 pages of "teach yourself NEW_FAD_TECHNOLOGY in 21 days" then I'd agree. If it's 1000 pages of authoritative, carefully considered and exhaustive thought, then I'd say 1000 pages is to little... I'd like a lifetime supply.

As for this book... so far I've only skimmed, and for being free on the web as a preprint, I'd say it's fantastic. I'm also reading Programing Language Pragamtics right now, and it's a little more complete treatment of the same subject area.

Why understanding the basics still matters

[Anonymous Brave Guy]

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 where performance matters at all, that can be crippling.

I agree that hardly anyone should need to write the usual sorting or searching algorithms from scratch today. It's almost invariably easier and safer to use one from a library, though of course there are a few legitimate exceptions. But you do need to understand the basics of the algorithms you use, their performance characteristics and the limitations they have.

This is particularly important with the growing dependence on library code, because most libraries provide only a few "typically best" algorithms. Sometimes an introsort variation isn't the best, or even close, but only the programmer who knows about his own data and who understands the range of algorithms available is able to judge when an alternative is more appropriate.

Just out of curiosity, do you know how a transistor works? 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.

No, but I could tell you off the top of my head the algorithms for intro sort, quick sort, merge sort, radix sort and several others, and implement them for you in a procedural or functional language without a whole lot of reading. I work with performance-critical applications every day, and you'd expect nothing less from a professional in my position.

Cautious first impressions

[Anonymous Brave Guy]

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, 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 aiming for a theoretical approach. The offhand comment about "whatever that means" in reference to sending messages to everything didn't much help, either; I'm guessing anyone who's used a language like Smalltalk or Ruby would be quite comfortable with the idea.

All of that said, there appears to be a lot of useful and worthwhile material in the book, and I'll certainly be dipping into other parts of it as time allows over the next few days. It's only a preprint, and I only looked at one section in any real detail at all, so I'll give it the benefit of the doubt for now.

Re: Cautious first impressions

[Peter Van Roy]

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

OK, damning indictment time :-(

[Anonymous Brave Guy]

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 separation, the significance of polymorphism and the way inheritance is used in many languages to allow it, the concepts of invariant conditions on a class' state and pre- and post-conditions on its methods, and just about everything else that's actually important about OO. Instead, they seem to spend lots of time going on about the cute syntax in their pet language.

Just to finally convince me that they don't really understand OO, their example (in section 7.4.1) of bad inheritance is dubious at best. They could have used the circle/ellipse or integer/rational "paradoxes" to demonstrate the hazards of using inheritance poorly, but instead they use an example that actually seems entirely reasonable to me. Their claim about what the outside world can expect violates the very principle of encapsulation: the outside world shouldn't know that, because it's an internal proprerty of that class... Unless, of course, it's documented in the interface as a post-condition of the method calls, but in that case, the derived class is breaking LSP. Oh, but they haven't mentioned post-conditions and how they are constrained by LSP, so it's kinda hard to say that.

Sorry, but having read 50 pages of that book, I'm quite convinced that it's not the new bible of programming. On the contrary, I would actually steer anyone interested in learning OO away from it, as I think its overweight theory and underpowered practice would be harmful to a newbie.

Re:OK, damning indictment time :-(

[Peter Van Roy]

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

Re:OK, damning indictment time :-(

[seif]

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 wanted to introduce concepts as early as possible when the programming model is expressive enough to warrent the introduction. In this view the idea of abstract datatypes/interfaces were introduced already in the declarative programming chapter and continued to be important in the message-passing and encapsulated-state/component programming chapter. There of course pholymorphism is important, among other things (invariants/post/preconditions) The chapter of object oriented programming therefore cannot be read out of this context. There we want to address what is distinctive of this model which is basically inheritance. We wanted the reader to understand the consequence of inhertance and the other concepts that has to come with it, like self, visibility of methods, etc. We also wanted to stress on the relationship to other models. For example how usual programming techniques of higher order programming can be modeled in oop, what higher order programming can add to oop, and where oop gives other but equivalent techniques to other models As we said in the beginning of this chapter we scratch the surface of oop. but taken together with other models we get a very rich programming paradigm. Finally I would like to stress that the book covers very well many aspects of concurrent programming which is very important for many industrial systems, e.g. building telecom systems. We cover most of the aspects of concurrent oop, see active objects and shared-state concurrency. ---- Seif Haridi

Re:OK, damning indictment time :-(

[Anonymous Brave Guy]

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 presentation as it stands is that while you've covered a lot of the issues in general, I felt that the specific applications to OO were mostly overlooked. For example, you place a great deal of emphasis on inheritance, where I would argue that inheritance is actually the most overhyped aspect of OO. It usually adds value only when used in conjunction with polymorphism, and actually reduces maintainability when used indiscriminately. I realise that you have the underlying structure to discuss these ideas, I just felt that the "last step" was missing, and that last step is the really important one if you've got relative beginners to OO meeting the general concepts in that context for the first time.

The same goes for things like invariant conditions. I understand that you've covered the concept, but your discussion in the chapter on OO doesn't give any real discussion of the role of initialisation as a means of getting an object's current state to satisfy the invariant conditions required by the class, for example. It would be hard to explain why constructors exist and work as they do in C++ or Java in the absence of that link between invariant state and initialisation of an object when it is first created.

Similarly, I found no discussion of using pre- and post-conditions on the external view of a class' state when defining its interface. Given the natural links between these conditions, inheritance and the substitution principle, I felt this was a serious omission. Perhaps you've again covered the principles elsewhere in the book, but if so, I think this is another case where some specific discussion in the OO chapter definitely has merit.

Finally, regarding your AccountWithFee example, my problem is that nothing you've shown us from your class' interface implies that the condition you give (B+S-@fee=B2) must hold. As I read it, you have a method balance that reports the current balance of the account, and a method transfer that accepts a certain amount of money into the account.

Now, if the latter were called increaseBalance, or had an explicit postcondition in its interface that balance would now be higher than it used to be by exactly the amount transferred, then I would not have an objection. However, in the absence of such conditions, I regard any code outside the class that makes that assumption as being what is broken, because it is relying on implementation details not defined in the interface. As things stand, if code in the outside world wants to know the balance of the account, it should use the balance method to ask, and if it wants to know how much the balance has increased after a transfer, it should look at the difference in the values provided by balance before and after the transfer. This appears to give well-defined results under the interface as we see it in your example, which the other assumption does not.

I feel that the lack of emphasis on separating interface from implementation (what IIRC Meyer describes as "design by contract") and the lack of consideration of invariant conditions (internal to a class) and pre- and post-conditions (both internal and as defining properties of the external interface) really hurt here. If you could show that a derived class method did not satisfy a post-condition of the class interface (whether that condition is stated explicitly or implied by calling the method increaseBalance) then you would have a rock-solid case. As it stands

Re:OK, damning indictment time :-(

[Anonymous Coward]

While I think the reply to this post I am replying now presents some merits towards a better OOP chapter, I still cannot help but feeling there's a view too strong on OO, and I think that's due to the extreme overhype OOP has undergone these last years.

I, for once, am very satisfied with what I've read so far; the style is clean and clear, and the explanations are easy to follow and well constructed. I've downloaded Mozart and I'm following the examples as I read, which is a plus (except for those declare's, but that's my fault :-) and I'm not only reforcing my knowledge in the different paradigms, but also learning new things (aside the Oz language, which I consider pretty solid and powerful) about functional, concurrent, declarative and other programming paradigms. As a regular systems programming in Perl and C, C++ and whatnot; I appreciate OO when it's useful, but not beyond. Perl being extremely multiparadigm (ISO C++ is as well, of course) and flexible, I often find myself using the best of each world in a rather harmonious way, no need to be a zealot about objects: after all, it's all code, and the important reader is the programmer, not the computer.

I appreciate the possibility of reading a draft of the book which is so complete and solid, and want to thank authors and editors for that.

Keep up the great work.

greetings from Spain

Re:OK, damning indictment time :-(

[Peter Van Roy]

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.

And since I've just noticed who I'm replying to...

[Anonymous Brave Guy]

...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 on using inheritance with polymorphism and aggregation when it's not required. You can worry about the technical differences between subtyping and subclassing later, once they have some framework for the concepts. Introducing it all up-front from a purely theoretical viewpoint loses the major practical points of using OO, and leads to people like me objecting to examples of "bad" inheritance such as the one in the book. Obviously, this is just MHO and you're free to disagree. :-)

Re:Kneejerk reaction

[jason_watkins]

I'm going to partly retract what I sad above now that I've read more. While Programming Language Pragmatics may cover more ground, a lot of it is just trivial mention. This book sticks to the core of illustrating the concepts of modern programing, and fully exploring their possibilities. It's a different kind of book, and doesn't address the implimenters view as other "programing languages" books do. So far I'm really enjoying it.

Re: programming IS art

[markhahn]

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 make an artist/artisan.

none of this was news to Knuth. and thinking it through also explains why I always thing of software engineering people as utter knobs ;)

whose bible?

[loudici]

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!

Re:whose bible?

[Peter Van Roy]

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

Disagreement

[KMonk]

So what good does coding your own hash tables do?
Programming is about thinking - and two mean really involves two stages. Thinking and coding. Of course we need to know more than STL, and modification of standard algorithms is very important - in one of my algo courses a lot of time was spent describing how to make a modification to a simple BST to solve a complex problem. Once you can think critically and apply these skills to a programming problem, the coding is almost always trivial.
Coding up your own hash tables or whatever hardly ever gives you any advantage over really, critically thinking about data structures and algorithms outside of a coding scheme. You can learn to think in this way, and you can learn to code in this way - but there are more efficient ways to do both, not to mention more interesting ones.

Section on OOP is confused

[w7cook]

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 abstract data types are a very useful concept for organizing a program. In fact, a program can be built in a hierarchical structure as ADTs that depend on other ADTs. This is the idea of component-based programming." and "Inheritance is the essential difference between object-oriented programming and most other kinds of stateful programming." "In the most general case, a class is an incremental definition of an ADT, that defines the ADT as a modification of other ADTs. There is a rich set of concepts for defining classes. We classify these concepts into two sets, according as they permit the class to define an ADT completely or incrementally: *Complete ADT definition*... -Defining the various elements that make up a class (Section 7.2.3), namely methods, attributes, and properties. ... -Taking advantage of dynamic typing. This gives first-class messages Section 7.2.5) and first-class attributes (Section 7.2.6). This allows powerful forms of polymorphism that are difficult or impossible to do in statically-typed languages. ... *Incremental ADT definition* These are all the concepts related to inheritance, that is, they define how a class is related to existing classes." As far as I can tell the entire presentation is completely muddled. If people are interested I can give references and more detailed discussion for their confusion. For example, they don't seem to understand the difference between subtyping and inheritance (extends and implements in Java). If I get time, I will write to the authors to complain. But there is probably nothing that can be done about it before publication at this point.

Re:Section on OOP is confused

[Peter Van Roy]

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 time to correct errors in the book, so we would very much appreciate learning about any that you can point out to us.

Re:Section on OOP is confused

[ninejaguar]

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

If you decide to rename the chapter to more clearly describe its intent, I would also encourage a full coverage of the subject of OO if you haven't done so. You need encapsulation, inheritance and polymorphism to claim fully explain OOP.

Please see Anthony Sintes' "Object Oriented Programming in 21 Days". Possibly the best practical introduction to that paradigm in the past 10 years.

His discussion on ADTs is quite enlightening, and his coverage of the three pillars has yet to be matched. The explanation of the non-OOP nature of switches in the Polymorphism chapter is also not found in most texts. But, the particularly strong emphasis on object responsibility is a welcome viewpoint to someone who's had to support sphaghetti code.

Use the following ISBN to locate the text. You won't be disappointed:

ISBN: 0-672-32109-9

Re:Section on OOP is confused

[w7cook]

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" is in effect very similar to the traditional ADT in, for example, CLU. But it bothers me that the "type", which is a key part of the "abstract data type" concept is not explicit. You are not using "type abstraction" to enforce representation hiding. The commonly-accepted analysis of this form of abstraction is with existential types (see ADT1 or ADT2 for example)

Instead, you have created a form of "abstract data value" that can only be operated upon via the associated operations.

Basically I think that you should replace the word "abstract data type" with the word "data abstraction" everywhere. Then things would make much more sense. What you are talking about is various forms of data abstraction. Abstract data types are one very specific kind of data abstraction.

p 470-481

I actually like the basic idea behind this discussion. I hadn't read it when I started critiquing the OOP chapter. However, there are some issues hidden here that are important.

Most of the content in this section should be in the object-oriented chapter if you ask me. Your development of "bundled" data abstractions is basically an explication of objects.

I think the most important one is hinted at in your comment on page 474: "This version is secure, declarative, and bundled. Note that it does not use wrapping, since wrapping is only needed for unbundled ADTs."

This is one of the key difference between objects and ADTs: objects don't need type abstraction or any kind of explicit data hiding. Instead, objects use procedural abstraction alone. This calls into question the orthogonality of your attributes: In particular, bundled+open doesn't make sense.

To me, the difference between unbundled and bundled is the difference between ADTs and Objects. Either ADTs or Objects can be declarative or state-based. The open/secure distinction is not interesting because objects are always secure, and ADTs are only really useful if they are secure.

As a result, I would say that Figure 6.2 incorrectly classifies {Secure, Stateful, Unbundled} as a "unbundled variant of the object-oriented style". Instead, it is simply the normal stateful ADT.

The section "comparing two popular versions" should be better.

• I don't agree that "The implementations of both versions have to do actions when entering and exiting an operation. The calls of Unwrap and Wrap correspond to calls of @ and :=, respectively."
• The interface for the stateful bundled version is not clear. You should not list Push Pop and Empty as operations, since they are methods. The type should be
• fun {NewStack}: < op(push:proc {$ T}, pop:fun {$}: T, isEmpty:fun {$}: Bool)>

This is the clearest illustration that this object version is not an ADT. The type of the return value is completely visible; it is not an abstract type <Stack T>. Note that declarative bundled versions require recursive types.

It is very telling that you completely miss a very important difference between the two versions: this is that anybody can create their own implementation of stack in the object paradigm, and all these dif

Re:Section on OOP is confused

[seif]

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 concurrent form of objects that communicate with 'real' message sending. Chapter 6 talks about encapsulated explicit state and many ways to build such entities. In chapter 7 we constrast the functional view to the object-oriented view which really implies pholymorphism in the sense that related categories of objects accepts the same message but execute it in its specialled way. This is contrast to the case-analysis on type that has to be done in the functional view. Still all of these things are minor things in our book. The intension is a firm understanding and the relationship between different programming models, and Finally we have an extensive treatment of concurrent and distributed programming models (Chapters 4, 5, part of 7 on active objects, 8, and the chapter 11 on distributed programming) All these are done with working programs and no handwaving. --- Seif

Quicksort in Haskell

[alienmole]

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]

Re:Quicksort in Haskell

[fizbin]

Actually, that (taken from "A gentle introduction to Haskell"; 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 much more readable myself, but I tend to prefer short lines.

Re:Quicksort in Haskell

[alienmole]

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:Section on OOP is confused (CONCLUSION)

[w7cook]

I had a nice email exchange with the authors and we have come to an understanding. You can read the full discussion on Lambda the Ultimate:

Link ==> Discussion on Concepts, Techniques and Models of Computer Programming

Here is my conclusion from the disucssion:

Let me say that I like your overall presentation (despite my having said that it was "wrong or confused"). You have good content, you are just a little fuzzy on the object-oriented side and using terms like "abstract data type" too loosely.

Here is one of their final statements

We are now in complete agreement. I have discussed with Peter and we will change the book according to your recommendations, i.e. make clear the concepts: data abstraction, ADTs and objects, and the differences between objects and ADTs.