Date: 17 Dec 2004 05:14:13 -0000 Message-ID: <20041217051413.24444.qmail@plover.com> To: mjd-book@plover.com (Higher-Order Perl announcement list) Subject: "Higher-Order Perl" proofreading almost done, again Organization: Plover Systems From: Mark Jason Dominus If you forgot what this list is about, or you don't know why you're getting this message, please see http://perl.plover.com/hop/ To unsubscribe, send a blank message to mjd-book-unsubscribe@plover.com. ---------------------------------------------------------------- What's in this message: * Current status of HOP * Indexes * Monads * Buy me * New book coming * Patience ---------------------------------------------------------------- CURRENT STATUS When I last wrote, I had a fantasy that the book would be printed and available by 10 December. Ha! Ha, I say! At least the delays are not my fault this time. There have been two sets of delays. First, the compositors did a really terrible job. Normally, you get the first page proofs, and then you proofread them and send back corrections. Then you get the second set of page proofs and you check them over to make sure all your corrections from the first pass were properly implemented and maybe make a few final corrections. Then you get the third set of page proofs which are perfect and you send them to the printer. What happened this time was that the compositors totally botched the first set of page proofs. In my last message, I said: There were lots of errors. All the single-quoted strings in chapters 6, 7, 8, and 9 have been carefully set with balanced quotation marks instead of with apostrophes at each end. Also they decided to randomly change the indentation in most of the code displays. So we had a second set of page proofs doing what the first set should have done. I was about 2/3 of the way finished with correcting these when it was discovered that there was a major layout error. When I shipped my HTML off to the publisher, way back in June, each chapter was one big HTML page with a little table of contents at the top. The compositors dutifully typeset this table of contents. My editors at Morgan Kaufmann sent the production manager a request to have those tables of contents removed. Then the production manager quit and was replaced by another production manager and the request was lost. This occasioned another batch of delays. The second set of page proofs became junk. The index person had to change all the page number references in the index he had made up. I had to start proofreading over again. I am now about 2/3 of the way through the third set of page proofs. Once my final corrections are incorporated, I will check over the fourth set of page proofs, which I hope go to the printer. The last official publication date I heard was mid-January, but I would be surprised if it appeared any earlier than mid-February, because my deadline to return the corrected proofs is 21 December, and then everyone goes on vacation for two weeks. (Except the compositors, who will be toiling away in Bangalore.) INDEXES Speaking of indexes, I have discovered something interesting. The O'Reilly folks used to tell me that they had their indexes done by a professional indexer, and this was better than having the author do it. But I remember when "Perl Cookbook" first came out Tom Christiansen was in a tizzy because the professional indexer had put all dopey entries into the index, such as <> (circumfix) operator, 224, 236-240, 274, 602 So I've always had my doubts about the professional indexers. They have two problems. One is that they will do the job, but they will not toil over it. You get an OK index but not an excellent index. But I've been toiling over this book for five years now and I darn well want everyone else to toil too. The other problem with the indexer is that he is not as familiar with the subject matter as the author is. So as I was reading the third (and second) set of page proofs, I was making up my own index. I figured that I would merge this with whatever the professional came up with and then we would have a really super-duper index. And I think that is true. But had we skipped the professional indexer entirely, I think I would still have done a better job than he did by himself. I estimate that my index would have had about 40% more items in it, and of course they will be more apt and germane. I can believe the O'Reilly folks when they say that the professional usually does a better job than the author would. But I can also believe that most authors would not commit as much toil as I would. W. Richard Stevens, author of "Advanced Programming in the Unix Environment" and "TCP Illustrated" has a bunch of really useful web pages up, one of which describes how he makes the indexes for his books. I recommend it to anyone who is interested in toiling over the index: http://www.kohala.com/start/indexing.html MONADS I continue to investigate functional programming techniques. Lately I've been reading a lot about "monads". The big problem with functional languages like Haskell is that they don't mix well with side effects. Assignment, references, exceptions, concurrency, and other side effects all wreck the nice functional properties that functional programming experts love so much. Unfortunately, without side effects, programs are mostly useless. Input and output are side effects. With no side effects, your computer is a black box with a power cable. You plug it in, it gets warm, maybe hums quietly. Your boss asks you what it's doing, and you say "It's computing!" Ooops. Between about 1980 and 1995 a lot of people invented a lot of ad-hoc ways to get various kinds of side effects into functional programming languages in tractable ways. But around 1995, a new, very general mechanism was discovered. It's called "monads". A monad is a sort of abstraction of a side effect, but it's also an abstraction of the idea of sequencing: "Do this, and then do that other thing." A monad value is an ordinary value wrapped up with a representation of a side effect. There's an operator for combining monads; it's responsible for joining together the side effects and returning a new monad that has both effects. Using monads, you can communicate to the compiler just what parts of your program might have side effects, and what parts are side-effect-free, and the compiler can do useful things with that information. The big problem with monads is that they seem to be incomprehensible. Nobody can understand them. I struggled for a year or two to get the idea. One day a couple of months ago I was walking to work and having a conversation with an imaginary person in which I was trying to explain monads. I had a realization: monads are hard to explain because they're so simple that there's hardly anything to say about them! Now I can't understand why it took me so long. (Part of the problem might be the name. "Monad"? The name comes from a category theory, an unusually abstract branch of mathematics, and it doesn't make a lot of sense even if you know the category theory behind it.) So I went back and started to reread all the stuff I had already read and only half-understood. I did some implementations of monads in SML and in Haskell. I found a bunch of places in my book where monads probably would have made the code simpler. And I'm writing up an article about it with examples in Perl. I'll post a link to the article when it is done. BUY ME You can pre-order the book online at http://perl.plover.com/hop/ORDER.html If you do this, I get an extra kickback. If you can get it cheaper somewhere else, that's good too. NEW BOOK COMING I now plan to write another book. The new book will be based on my successful classes "Perl Program Repair Shop and Red Flags". It is a book of case studies of refactoring Perl code. (My web pages at http://perl.plover.com/yak/flags/ have some information about the classes.) This is a very different book from HOP. HOP was all about being as clever as I possibly could be. The Red Flags book is just the opposite. I've worked hard to eliminate as much cleverness as I can. The Red Flags book is about how to write good code even if you're hung over. As a result, it is a much easier book to write. I have about half of the manuscript finished now. I will probably sign a contact for it early next year. This leaves me in a slightly rough spot with this mailing list, however. I don't want to throw away my 650 addresses. But I promised repeatedly that *this* mailing list would only carry announcements about HOP, and I would shut it down when HOP was done. I can't want to break that promise. So if you're interested in my new book and any future books I might write, you can send a message to mjd-books-subscribe@plover.com To subscribe the address fred@example.com, send a message to mjd-books-subscribe-fred=example.com@plover.com (Notice that the @ has turned into an =.) I expect that the new mailing list will get no more than a few posts a year, just as this one has. If you don't subscribe to this new list, then you will NOT get announcements about the new book or free samples from the new book. You will get one automatic invitation to join the new mailing list, and after that if you have not subscribed to the new list, I will throw away your address as I promised. PATIENCE Nobody wants to see the finished product as much as I do. But it is almost here. Reading over the proofs has reminded me that this HOP is a really excellent book. I am sure you will like it. Thanks again for your patience and support.