This is quite good so far, although I can tell I'm going to have to work to get through the first third or so, before the book gets to the point where it really pulls me along. I frequently have trouble getting into biographies or history books (and this is both), because there's nearly always a lot of background to lay before the book gets to the part I'm really interested in. (That's ironic, because I'm sure that's the way everyone I know feels when I start explaining something or telling a story, because I always think the background is way more important than most of my friends do.)
In this case, the primary topic of the book is how Lincoln forged his cabinet from his chief rivals, and how that strong-willed cabinet, under Lincoln's equally strong leadership, was an important factor in achieving the goals for which Lincoln is revered. But Lincoln isn't elected until more than a third of the way through the book. I know that what I'm reading now (the lives of the four main players, plus the campaign for the Republican nomination and then for the presidency) is crucial for establishing the tense relationships between the men, to give weight to the bravery and shrewdness of Lincoln's decisions. But it's not what I *want* to read.
Got this book for Christmas from my parents. It gave me perverse pleasure for my die-hard right-wing parents give me this, one of Barack Obama's favorite books. (Although I've been interested in the book since long before I knew Obama had read it; I heard the author on a local PBS show and thought it sounded fascinating.) We'll see how long I can resist reading it while I finish other things.
I'm not very far into this yet, but I'm already a fan. I've read Paul Hudak's and Simon Thompson's books on Haskell, and know the language well enough to read code and write a few toy programs myself, but I've never felt *comfortable* in Haskell. This book is already filling in the gaps.
My problem with the other books was that they focused almost entirely on the purely functional aspects of the language. Obviously that deserves a lot of attention, but I found that relatively easy to grasp. What was harder for me was how to integrate that aspect of the language with the cordoned-off, "impure" parts of Haskell -- the parts that are necessary for "real world" programming.
The way Haskell deals with IO and other not-purely-functional tasks has implications on how you structure your programs, and other books I've encountered treat IO as an afterthought, and completely ignore the issue of how programs must be structured to mix the functional style with IO. That's not something that should be left as an exercise for the reader.
Erik Meijer recommended Graham Hutton's *Programming in Haskell* to me, but from looking at the table of contents, that book seems to suffer from the same problem: IO isn't mentioned until more than halfway through, and is given just one chapter.
*Real World Haskell* is a breath of fresh air. In chapter 4 it touches on this issue, giving a brief skeleton program that does IO for you and allows you to plug in your own functional treatments of the input data. This framework gives readers a scaffold they can use to write programs of interest to *them* -- a great way to learn. The focus on integrating functional algorithms with real tasks seems, from my perusal, to continue throughout. Bravo!
It's funny to me how often my reading for different purposes manages to overlap. I've never had any serious interest in seafaring or navigation, but this book about those topics (which I'm reading to better understand how teams function in my field of software development) feels rather familiar to me, because of two John McPhee books I read just for the love of his writing: [*Looking for a Ship*,](/glv/books/0374523193/looking-for-a-ship/) which is about life in the merchant marine, and [*Uncommon Carriers*](/glv/books/0865477396/uncommon-carriers/), which deals with people in transportation industries in general (and in which one essay revisits the central figure of *Looking for a Ship*). An incident in the opening anecdote, in which a sailboat risks collision by tacking across the path of an unpowered navy ship, reminded me instantly of anecdotes in "A Fleet of One" and "Tight-Assed River", two very different pieces in *Uncommon Carriers*.
After a pleasant start, the book is a little hard to get into, due to the necessity of laying down a lot of background information: social and organizational structure in the navy, possible impact of an outsider (the author) on the team, as well as basic background information about the navigational tasks that the team performs.
I ordinarily enjoy learning about such things that are outside my ordinary experience, but I've found this to be slow going. I suspect that's at least partly because the information about navigation seems painfully obsolete. The book was published in 1995, and recounts research that began about 10 years earlier. Thus, GPS was not a part of the naval navigators' job. It was just starting to be widely used at the time the book was actually written, and the author acknowledges that the navigational techniques described here were in the process of being completely overthrown by GPS.
I saw this book on a shelf at a client site a while back, and snuck it into my backpack ... no, wait, that's wrong, I put it on my wishlist. I'm just getting around to reading it.
The book is about the processes of learning and reasoning in a team setting. It stems from research made observing the team on the bridges of navy ships at sea. As a result, the tasks being performed and the structure of the team performing them are rather complex.
Most thinking and writing about cognition has involved individuals. But it was instantly clear to me that this book was addressing something real: that cognitive processes are affected by social and organizational contexts. I don't know yet what I think of the conclusions this book draws, but it's definitely touching on an underexplored topic, and I'm sure it will at least provide food for thought.