briancarper.net (λ) (Category: Book Reviews)

Review: What Do You Care What Other People Think?

Fri, 06 Aug 2010 22:12:01 -0700

I recently reviewed Surely You're Joking, Mr. Feynman!. It was good enough that I had to get the sequel.

What Do You Care What Other People Think? is another collection of stories and anecdotes written by and/or about Richard Feynman. A bit in contrast to the first book, rather than a chronological series of anecdotes, this book focuses on a couple of main topics.

Feynman discusses his first wife in some detail. Of particular interest, he describes his and his wife's brutal devotion to honesty in their relationship, even in the face of highly unpleasant truths (terminal disease, in this case). It's the honesty of a scientist, carried into "everyday" life. This was bittersweet for me to read, because the story has a sad ending.

There is also a short series of letters from Feynman to others, where he discusses the silliness of pomp and circumstance, e.g. his foibles and breaches of protocol when meeting some king or other. As someone who hates ceremony, I got a huge kick out of these.

A large part of the book is devoted to discussing the Presidential Commission which investigated the cause of the Challenger shuttle disaster. Feynman's full report is included in the book as well.

As someone interested in astronomy and space flight (and who isn't interested in those?) I found this fascinating. There's a lot of behind-the-scenes stuff. Engineers are painted in a good light, managers and politicians not so much. (Software engineers come out looking especially good, which made me feel (unjustifiably) good about myself by proxy.) There are some diagrams and a lot of technical discussion of the shuttle. Not so much that it drowns the narrative, but enough that I'm probably going to spend the next week reading Wikipedia on the subject now.

Feynman explains his simple methods at getting to the truth in the investigation. Go talk to the guys who put things together. Get your hands on some O-ring rubber and test its resistance to temperature yourself in a glass of ice water. Cut to the heart of the matter. It's good stuff.

Ultimately, as you know if you've read the report, Feynman rips NASA apart, showing that they were fooling themselves into believing the shuttle was safer than it really was. The last sentence of the report says everything: "Nature cannot be fooled."

The last section of the book discusses the value of science. More specifically, Feynman discusses the value of doubt. I very much liked how the chapter ends:

It is our responsibility as scientists , knowing the great progress which comes from a satisfactory philosophy of ignorance, the great progress which is the fruit of freedom of thought, to proclaim the value of this freedom; to teach how doubt is not to be feared but welcomed and discussed; and to demand this freedom as our duty to all coming generations.

If there's one trait I had to pick to separate good people from bad, it would be the ability to admit being wrong. And if I had to separate the good from the excellent, it would be not just the ability to admit being wrong, but the eagerness to be proved wrong.

There's a certain kind of devotion to the truth that not many people achieve, and maybe not many people even want to achieve. There's comfort in thinking that you know things. It's very tempting. I think it's probably partly why most people are religious. I suspect it's a big reason why so many people are so stubbornly wrong about so many things in general. I suspect this comfort is an enormous source of suffering in the world.

But there's another kind of comfort that people miss out on. It's the comfort of knowing that although you're probably wrong about a lot of things, you're trying your hardest to be right. You pay the price of being aware of your own state of ignorance, but you can rest a bit easier knowing that you're maybe, hopefully, inching towards the truth. I never heard the word "freedom" used to describe this feeling before, as Feynman does above, but it fits.

That's why I like reading about Feynman and reading Feynman's words. He seemed to live this philosophy as well as anyone could hope to.

Review: Surely You're Joking, Mr. Feynman!

Mon, 26 Jul 2010 16:19:21 -0700

I'm probably the last person on earth to read "Surely You're Joking, Mr. Feynman!", a collection of stories and anecdotes from the life of Richard Feynman. But better late than never.

I'll keep this short. Feynman was the kind of nerd every nerd wishes he was, in one way or another. He was socially awkward. He was blunt and tactless. He felt out of place much of the time. And it was surprising to see how often Feynman expressed feelings of inadequacy. He wrote about being highly intimidated when talking in front of big names in physics, and jealous of the math abilities of some other people.

But none of that stopped him from having an exciting life. In fact he turned these traits to his advantage. He had romantic success, often via very highly unconventional means (e.g. walking up to girls and asking them for sex outright; they often said yes). His bluntness was seen as an admirable trait: where others might be intimidated by a famous physicist, Feynman would give his honest opinion, and that was often appreciated.

And Feynman went far outside his comfort zone. He did a stint in biology, even though he knew nothing of biology at the time. He went to Brazil and joined a samba band. He sold drawings and paintings for a while. He played drums for a ballet.

I picked up at least three lessons from this book.

Try new things, even if you suck at them. Life is boring if you stick to what you're good at.
Be intellectually honest. Brutally so. It's the only way to do good science, and arguably the only way to live a good life. I've always believed this, and Feynman hammers the point home well.
Even the best and brightest of us feel insecure at times. You shouldn't let it stop you.

On top of all of that, reading of Feynman's time at Los Alamos working on The Bomb was a fascinating piece of history. I highly recommend this book.

And watch as much of Feynman on Youtube as you can find. It never ceases to be fascinating.

Review: Hacking Vim 7.2

Fri, 07 May 2010 16:30:44 -0700

Vim is an open-source text editor with a power and flexibility matched only by the steepness of its learning curve. As the author of this book states, "Vim Can Do Everything"; but configuring it to do so is sometimes daunting. Hacking Vim 7.2 aims to help the average Vimmer get the most out of customizing Vim, for fun and productivity.

Vim has an overwhelming number of features. Its built-in help system and documentation are comprehensive and easy to navigate once you know what you're looking for, but knowing where to start is sometimes very difficult. The best you can hope for in a book is a broad outline to point the way toward features that you didn't know much about. Hacking Vim 7.2 achieves this goal.

No topic is covered in nearly the depth you'll find in the official documentation (or even on the Vim Wiki), but every topic is covered in enough detail to let you know that a feature exists and to point you in the right direction to begin using it. Most helpfully, throughout the book are references to things to look up in Vim's help system, as well as links to various relevant scripts on http://www.vim.org/scripts/.

This is not a book for an absolute Vim beginner; some familiarity with Vim is assumed. And for a Vim fanatic, much of the material may be common knowledge for you already. But any seasoned Vimmer will tell you that there are always things to learn about this editor, and I think nearly everyone will learn something from this book. For someone who uses Vim and is looking to master it, this book is a great starting point, though you'll still need to dive into the official reference material to really cement your knowledge.

The book starts on an odd note. Chapter 1 is a history of vi and the various vi clones released over the past couple decades. This information is interesting trivia and serves to give credit to programmers who paved the road to Vim, but it doesn't really help anyone "hack Vim" in any way. The book probably could've done without this chapter.

Chapter 2 deals with customizing the overall look and feel of Vim. How and where to edit vimrc is covered, with brief attention given to cross-platform issues. It covers the basics (changing font faces and colors, customizing menus and toolbars), as well as pointing out some more obscure settings, like highlighting the cursor row and column (creating a kind of "cursor crosshair"), and using the match feature to highlight multiple search terms at once. This chapter is a good foundation for later chapters and a good introduction for anyone who has never edited their own vimrc.

Chapter 3 is about text navigation. Sadly, the book doesn't go into as much detail on movement commands as I would've liked. The ability to move around and manipulate text quickly in Normal Mode by combining counts and motions/operators is one of Vim's most unique and powerful features, but it only gets a few paragraphs here.

There are some interesting key mappings provided, for example how to move up and down between "virtual" lines when lines are soft-wrapped. Search is covered briefly, both plain text search and multi-file search via vimgrep, but there's little information about Vim's powerful regular expressions, which I thought was a shame. Marks are discussed, both normal "hidden" marks as well as visible "signs", the latter being a feature I've never used.

Chapter 4 is about "production boosters" and covers a wide variety of topics. Much of the chapter is devoted to "templates" and "snippets", which allow you to build skeletons of commonly-used source code (with fill-in-the-blanks markers) that can be re-used when editing new files. A system for using these templates is built from scratch using Vim script, providing a clever and useful example of scripting in action.

Auto-completion is covered in a lot of detail. Some custom key mappings are provided to help make "omni-completion" in Vim a bit easier to invoke. This chapter also very thoroughly covers Vim's multiple copy/paste registers and how they work. Recording and using macros, pointed out as one of Vim's more overlooked features, gets a good, lengthy example.

"Undo branching" in Vim is wonderful, but difficult to understand. Chapter 4 gives a simple, step-by-step example of why it's useful and how it works. This chapter also briefly discusses folding, vimdiff, netrw (editing files remotely via SSH and other protocols), and ctags. There's lots of good stuff in this chapter and you're almost certain to learn something useful.

Chapter 5 covers text formatting, both using built-in Vim commands and by piping text through external tools like par and tidy. A lot of space is devoted to using Vim to prettify plaintext, for example by centering titles on a line, adding ASCII-art dashes for headers and making bulleted lists. If you edit plaintext in Vim often, this is probably a great chapter, but I didn't find much use for most of it.

For programmers, the book discusses the different indentation styles available in Vim and very briefly shows how to write your own indentation functions, and how to indent and reformat blocks or whole files of code all at once. "Paste mode" also gets a passing mention. Personally I think a programmer reading this book would've benefited from much more detail about Vim's myriad indentation and text-wrapping options and how they work together, as this can be one of the most frustrating parts of Vim to configure correctly.

I had high hopes for Chapter 6 and 7, which deal with Vim scripting, but I was largely disappointed. Chapter 6 deals with scripting basics, and is essentially a beginner's language tutorial. It explains which variable types exist in Vim script, how if/then/else works, how for- and while-loops work, how function parameters operate, and so on, but anyone who knows a modern scripting language will learn these things quickly without much effort. There's also some basic information about how to write a syntax-highlighting script from scratch, but there's not really enough information to allow you write one for a real programming language.

Chapter 7 is supposed to be about "extended scripting" topics, but serves largely as a style guide. It details how to structure a script to check for compiled-in features and Vim version number. This chapter touches briefly on using SID and PLUG to namespace functions, but the explanation and example left me puzzled. How to use the debugger and how to make Vimballs are both explored, and the book points out that you can use Perl, Python and Ruby to script Vim without going into much detail or giving solid examples.

If you're looking for any advancing information on writing your own functions in Vim script, you're mostly out of luck here. Previous chapters in the book do include some useful and practical functions, but those functions are never really taken apart or explained in detail.

Finally there are two appendices, one of which lists a bunch of games you can play in Vim (again this could've been left out of the book and I wouldn't have missed it), as well as examples of using Vim as a mail, chat, and Twitter client. There's also a feature-by-feature comparison of Vim to MS Visual Studio, showing that many of Visual Studio's abilities can be provided in Vim given the proper scripts. I thought it was an interesting demonstration that Vim really can do everything, just in case the reader had any doubts at this point. The last appendix is a style guide for keeping your vimrc clean, mostly via common sense and splitting your configuration into multiple files.

Overall, stylistically the book is a bit dry and humorless, but it's easy enough to read and it gets its information across clearly. There were a few typos and editing errors, including a few rather glaring typos in some code examples, but overall the author seems extremely knowledgeable about Vim. The best parts of the book are where the author says "this was useful to me personally, so here's how I do X". This book is clearly written by someone who uses Vim all the time, and most of the information provided is practical and immediately usable.

I do feel the book should've gone into more detail in many areas. At 244 pages, the book is short and gives a rather shallow view of many of Vim's features. But the book hits all the right notes and leaves few features entirely unexplored.

I'd recommend this book to any person who uses Vim and wants to explore features they may have been missing. There's nothing in this book you won't find in Vim's built-in documentation, but this book lays everything out in an easy-to-read format, and should serve as a good starting point to customizing and mastering Vim.

Review: Parsing Techniques: A Practical Guide

Sat, 13 Feb 2010 22:47:08 -0800

For Christmas this year, I received a shiny hardback copy of Parsing Techniques: A Practical Guide by Grune and Jacobs. It's a thrilling book, if you want to learn parsing, which I do.

Where most books proceed in a sort of linear fashion, this book teaches parsing in layers. First you learn what a grammar is. Then you learn what it means to parse: what's a parse tree? What's bottom-up vs. top-down? What's a leftmost vs. rightmost derivation?

Next you get some general ideas and methods for parsing, e.g. CYK and Unger, and then you dive into the implementations of parsers (in pseudocode and in C) in great detail. This is about as far as I've gotten so far, before having to go back and figure out what the heck I just read. But it's an interesting progression. Reading the book, I feel like I'm constantly revisiting things I learned a few chapters ago, but this time in more detail. The book kind of does a breadth-first traversal of the world of parsing.

Be warned however: this book is not easy reading. It's dense, heavy on the info, light on the entertainment. Unless you really get a kick of out parsing, this will probably put you to sleep if taken in large doses. But it is a trove of information, and I couldn't put the book down during certain chapters.

In fact there's so much information in this book that it's almost depressing. The bibliography alone takes up 1/4 of the book, and lists 1,500(!) authors. It'd take me a week to read the bibliography, and probably many years to read every book listed there. Parsing could easy consume a lifetime of study, and I'm saddened that I'm probably never going to find the time to master all there is to know. But such is life.

If I had one quibble with this book, it'd be the same quibble I have with most math papers. The notation is horrible. Say what you will about programmers, most of us know that code is written for humans, not for machines, and we give our variables descriptive names. In math it's all single letters variable names.

When the authors of this book run out of single letters, they use letters with bars over them, or bold letters vs. normal typeface letters, or they do things like this:

...whenever a non-terminal A is entered in to entry R_i,l of the recognition table because there is a rule A -> BC and B is in R_i,k, and C is in R_i+k,l-k, the rule A_i_l -> B_i_k C_m_n is added to the parse forest grammar, where m = i + k and n = i + l - k.

This is the first paragraph of a section. Those variables are not mentioned before this sentence. This is certainly not a style of writing that I'm used to reading. It takes me a good dozen tries to understand. (Using lowercase i's and l's right next to each other should be prohibited by law.)

In any case, this book is good. One of my favorite tools has always been Perl-style regular expressions, and I feel like this book has expanded my understanding of how they work. Learning to write a recognizer, learning how things are implemented under the hood, you couldn't ask for a more interesting topic. I can't wait to try writing a toy parser generator or regex recognizer in Clojure once I've solidified my understanding of some of these concepts.

Review: Coders at Work

Tue, 08 Sep 2009 18:47:08 -0700

Recently I received a preview copy of Peter Seibel's newest book, Coders at Work.

This is a wonderful book if you are a programmer and care at all about the art, craft, and/or science of programming. If there is any wisdom to be had in this fledgling field of ours, this book contains buckets of it.

The book consists entirely of long interviews with some big names in the world of programming: Donald Knuth, Ken Thompson, Jamie Zawinski, Guy Steele, Peter Norvig, the list goes on. There are also some names I wasn't quite so familiar with (but maybe should have been), like Brad Fitzpatrick, the inventor of Livejournal.

But everyone interviewed for the book has produced some grand, successful project in their time. These are tried-and-true, battle-tested programmers and in this book they share their war stories and advice.

Questions and Answers

There are a few questions that Seibel asked everyone, and it's interesting to compare and contrast the answers.

How do you start learning to program? Perhaps because of the varying ages of the interviewees, the answers range from punch cards to Perl scripts. Is a CS degree a necessity, a boon, or a hindrance? Is a background in mathematics necessary? Very different views depending who you ask.
How does a person become an outstanding programmer? Is the ability to program something you're born with or something you learn? This book has a lot to say on the topic, directly and indirectly. Knuth thinks that in any group of 100 people, "2 of them are programmers in the sense that they really resonate with the machine". Fran Allen says that working on a farm helped her have a better understanding of large complex systems with inputs and outputs. Many stories point to people being "naturals", e.g. Guy Steele learning APL from a couple brochures at an exhibit. But it's clear that years (or decades) of hard work and dedication are needed too.
If there's anything most of the coders have in common, it's starting at a young age and being rabidly enthusiastic. You get the impression that these guys (and gal) love programming. It's not just a job, it's a passion. Many are the tales of 26-hour coding sessions. Most of those interviewed say they still fiddle around with code in their spare time, even those who have retired from professional programming (or burned out on it entirely).
What tools do great programmers use? Which editors? Debuggers? IDEs? If this book is any indication, the answer is Emacs. Or in some cases, plain old pen and paper. There are a few representatives of the IDE side of the aisle, but mostly the tools are simple and the minds do most of the heavy lifting. (There's nary a mention of Vim. It breaks my heart a little.)
How do you go about debugging code? Print statements are (perhaps surprisingly?) very popular among the greats in this book. There is much lamenting over the current state of debuggers, which are, in the words of Brendan Eich, "pieces of shit from the '70s like GDB". One of the most common methods of debugging is just mentally stepping through code until you see a problem. Some of those interviewed share some of their horror stories of extremely difficult bugs to squash.
Is programming an art, a craft, a science, a kind of engineering, or something else? The answers are wide and varied; many seem to view it somewhere between an art and a craft, but some have other views. L. Peter Deutsch muses that "coder" is to software development what "bricklayer" is to constructing buildings.

Programming today

A recurring theme in the book is the beauty of simplicity.

Many people interviewed for this book did their best work decades ago, when computers were very different beasts. Programmers were constrained by the technology of the times, but perhaps because of those constraints, code had to be simple and straightforward, and there was an elegance in that simplicity that we've since lost.

As a young programmer who never experienced such an environment, I found it enlightening to hear the opinions of those who had. Seibel asked everyone what they thought of today's world, and the answer was often amazement combined with fear and dismay.

Quoth Guy Steele:

I guess to me the biggest change is that nowadays you can't possibly know everything that's going on in the computer. There are things that are absolutely out of your control because it's impossible to know everything about all the software. Back in the '70s a computer had only 4,000 words of memory. It was possible to do a core dump and inspect every word to see if it was what you expected. It was reasonable to read the source listings of the operating system and see how that worked.

Knuth has this to say:

There's this overemphasis on reusable software where you never get to open up the box and see what's inside the box. It's nice to have these black boxes but, almost always, if you can look inside the box you can improve it and make it work better once you know what's inside the box.

Joe Armstrong, of Erlang fame:

Also, I think today we're kind of overburdened by choice. I mean, I just had Fortran. I don't think we even had shell scripts. We just had batch files so you could run things, a compiler, and Fortran. And assembler possibly, if you really needed it. So there wasn't this agony of choice. Being a young programmer today must be awful--you can choose 20 different programming languages, dozens of framework and operating systems and you're paralyzed by choice. There was no paralysis of choice then. You just start doing it because the decision as to which language and things is just made--there's no thinking about what you should do, you just go and do it.

And Bernie Cosell, one of the original programmers who worked on ARPANET:

At one level I'm thinking, "This is way cool that you can do that." The other level, the programmer in me is saying, "Jesus, I'm glad that this wasn't around when I was a programmer." I could never have written all this code to do this stuff. How do these guys do that? There must be a generation of programmers way better than what I was when I was a programmer. I'm glad I can have a little bit of repute as having once been a good programmer without having to actually demonstrate it anymore, because I don't think I could.

Dealing with the ever-increasing complexity of computers today is something we all struggle with. We're endlessly re-inventing wheels in this field; everyone knows it. Getting back to the basics is a very appealing sentiment.

Quotes

The questions and answers in this book are brutally honest and buzzword-free, which is refreshing. It's enlightening and at times giggle-worthy. There's a kind of snark that only a disgruntled computer programmer can produce.

L. Peter Deutsch:

[M]y description of Perl is something that looks like it came out of the wrong end of a dog.

Peter Norvig:

After college I worked for two years, for a software company in Cambridge. And after two years I said, "It took me four years to get sick of school and only two years to get sick of work, maybe I like school twice as much."

Guy Steele:

If I could change one thing -- this is going to sound stupid -- but if I could go back in time and change one thing, I might try to interest some early preliterate people in not using their thumbs when they count. It could have been the standard, and it would have made a whole lot of things easier in the modern era. On the other hand, we have learned a lot from the struggle with the incompatibility of base-ten with powers of two.

The bad

The only complaint I have about the book (if it is a complaint) is the length of the some of the interviews. Some were hard to get through in a sitting. There's also some profanity, if you care about such things (I don't).

If you buy this book expecting to hear stories about TDD and .NET and RoR and other such trendy three-letter acronymns, you may be disappointed. If you are immersed in the present and don't care about the past, this book may not be for you.

Overall

This book is a great read, educational and entertaining and I dare say inspiring. Other reviews have said this and I agree: Seibel is a programmer and he asks the questions a programmer would ask. I highly recommend this book. It's for sale mid-September; check the book's website.

Books are our friends

Sun, 30 Nov 2008 22:22:01 -0800

I went on a reading binge over Thanksgiving break. Read on for reviews.

Test-Driven Development By Example

First I read Test-Driven Development By Example. This is a very short book, especially given the hefty price tag. I would probably not have bought this if I'd seen it on a shelf at the store rather than online.

That said, it's a good book if you want to understand the mindset behind the whole test-driven development fad. The book is heavy on mindset and light on mechanics; it doesn't tell you how to set up an environment, how to compile and run tests, or any such thing. It just goes through some examples and explains what the programmer was thinking, and how to tackle the problem from a TDD point of view. The intended audience therefore is someone who has plenty of experience programming and wants to learn a new way to look at problem solving.

The book goes through writing some terrible code (admittedly terrible by the author) to solve a simple problem, then refactoring the code to be less and less terrible by means of tests. The writing style is engaging and casual and he describes mistakes as well as successes, which is a nice way to write a tutorial book. The alternate writing style, belting out the correct answer the first time every time, is not as enlightening, and I appreciate it in this book.

The book places a heavy emphasis on writing tests FIRST, making small incremental changes, and refactoring as you go. It also explains how TDD can be related to various OOP design patterns, which I didn't find all that helpful. And it describes some "test patterns", which I found even less helpful. But it's mostly an aesthetic objection; something about "design patterns" sits less and less well with me the more I get away from Java-like languages. The information is still good, straightforward and to the point, take it or leave it.

I have been unable to drink the TDD Kool-Aid, but I can see where it'd probably result in an improvement in some of my code for certain specific kinds of problems. I'll probably try it out again next time I have to write a little library at work.

This book is expensive and short, but the alternative for learning about TDD are half-baked blog posts, which is why I bought a book. I don't know of a better book because this is the only one I have, and I'm unsure at this point whether I really want to buy another book on this topic. But this book is highly recommended by many TDD ~~fanatics~~ enthusiasts, so I don't know.

The Little Schemer

Next I read The Little Schemer. The style of this book can best be described as "cute". Examples all use food, and it instructs you at various points to go make yourself a sammich (even leaving room in the book for "jelly stains"). This somehow makes the topics, which can be rather intimidating, somehow less scary. The book is very short, and not very dense (not many words on a page), but they somehow cram a lot of information into the book anyways, via the many examples. It's a very focused and methodical book.

This book goes through developing a simplified dialect of Scheme, with a focus on recursion and building up parts of the language from very simple primitives. There are some neat little things along the way, like using s-expressions to represent numbers, and building up a full set of arithmetic functions using nothing but "add 1", "subtract 1", and recursion. It'd be insane to do in real life because of performance, but it's really neat from a "hey look what you can do, isn't this cool!" point of view.

The first half of the book is pretty simplistic (at least for me, with some basic knowledge of Lisp and Scheme), but the second half really starts delving into some crazy things, passing lambdas around to lambdas and writing evaluators and stuff. But you almost don't even notice because of how solidly the foundations are built up to that point, and how well the examples are explained. (You probably will notice once you hit the y-combinator, on account of your brains detonating.)

This not a good book for "learning Lisp" in terms of learning the gritty details of to use a real-life implementation of Lisp. But it's a good book for learning some of the concepts that make Lisp and functional languages powerful. This is a very interesting and unique book, also highly recommended by many in the Lisp world. I'm already planning to try The Seasoned Schemer next.

Real World Haskell

Finally I started plowing through the recently-released Real World Haskell. This book is freely available online, which is great. It also allows readers to make comments on every paragraph in the book, which is a highly collaborative and probably very intelligent way to write a book, and also can provide insight for readers who don't understand the text at any given point. I may buy a hard copy, I haven't decided. (The online version has some FIXME notes and typos that I can only hope are fixed in the real thing.)

I'm only up to chapter 11, but it's good so far. It gives a ton of examples and goes slow enough for people completely new to Haskell to pick the language up. And it includes some of the mechanics of compiling and/or running programs in GHC, which is extremely helpful. I did start getting lost around the time monads were introduced, but that's to be expected. It usually takes me two or three good reads of this kind of book before I grok it all, which is no fault of the book.

Haskell. Last time I used it, I wrote Pong in Haskell in one of my college classes. It was an immensely painful experience. I'm going back to re-learn Haskell now because I find myself edging more and more toward functional languages and away from the C/Java world.

Haskell is far too much to swallow if you have no experience with functional programming, which is probably why I hated it in college. (That said, a smarter person than I may have fewer problems.) After graduating school, I got my first whiff of this world again via Perl's map and grep and friends. Then Ruby pushed it home for me with its widespread use of block parameters (lambdas in disguise). And after learning Lisp (and especially later, Clojure) I can't live without higher-order functions. If I had to write a classic for-loop and manually keep track of a counter variable I'd probably vomit at this point. Haskell takes function manipulation to an even greater extreme, which I still haven't fully wrapped my head around, but I like what I've learned so far.

Laziness is awesome, function currying is awesome, and this is the first time I've read about folding, apart from brief struggles with Ruby's (poorly named) Enumerable#inject. Pattern matching strikes me as vaguely similar to Common Lisp's / Clojure's destructuring-binding, which is one of the nicest features I've seen in any language when it comes to making a programmer's life easier.

Maybe it's all just interesting because it's still new to me. But I like the whole idea of functional programming. I like the idea of functions that always produce the same output from a given input. How and when to handle side-effects and object mutation is a problem that's always nagged at the back of my mind even when writing Ruby code.

That said, Haskell still (at this point in the book) does not strike me as a practical or real-world language in the slightest. You've got to jump through some crazy hoops to get a lot of things to work, especially when it comes to I/O. The book describes how to write a pretty-printer, and how to parse a binary file, both of which require some acrobatics to write concisely in Haskell. In particular the parser library lost me entirely; functions were being chained to functions in all directions and I couldn't follow it.

I think one reason Java is so popular is that you don't have to be a genius to write it. To write Haskell (or even Lisp) well, to take advantage of the language and use it smoothly, you really do need to do some deeper thinking. The abstractions are more powerful and more "abstract". It's not too hard to understand a world made of objects with a bunch of knobs you turn via method calls. Lambdas and recursive functions and monads and typeclasses are a more ephemeral thing.

That said I plan to stick with the book. Practice makes perfect.

PAIP review

Mon, 10 Mar 2008 17:21:35 -0700

It's been a while since I acquired PAIP. I can't say I've read all of it over the past couple months, but I've read most of it.

The initial chapters that give an intro to Common Lisp seem largely useless to me. There are better books to introduce Common Lisp (especially now that we have PCL). Norvig admits as much himself, and thankfully doesn't devote much of the book to intro material.

Once you get past those, this book is densely packed with information. Just tracing through and understanding the source code would probably take me a couple of months, let alone grasping all the concepts the source code is trying to exemplify. It's a wonder to me that one person can produce this much material. But the downside is that it's a bit difficult to read at times; it's kind of dry and reads like a text book. In spite of that, I was glued to this book for quite some time; the information inside is engaging enough to make up for the lack of presentation.

Some of the examples of code in the book really are quite startling. For example Norvig writes a pattern-matcher that implements some subset of Perlish regular expressions, and it only takes a couple pages of code. Later in another couple pages of code, he implements a variant of Prolog. At one point he writes some pattern-matchers that can parse a surprisingly large subset of the English language. But a lot of other examples of code weren't quite so interesting to me personally; a lot of the material is dedicated to tree and graph search algorithms, which brought to mind long boring lectures from my college days. (As a side note, it's very sad how much of the history of AI can be reduced to "clever graph search algorithms". I don't know much about AI today but I hope it's advanced a bit past that.)

This book is from 1992 and some of it does feel a bit dated. This book was apparently written just after Common Lisp was standardized. Object oriented programming was apparently relatively new back then, and Norvig glosses over CLOS. Most of the code is written in functional style. However Common Lisp today still doesn't force OO on you by any means, and a lot of Lispers today apparently still don't care much for OO, so the code is more relevant than you'd imagine.

And as you can't help realizing after reading an old CS book or two, CS as a science hasn't seen all that many breakthroughs in the short couple of decades it's been around. It's really quite sad in a way that a book written over 15 years ago can still be so relevant; we have all these huge advances in computer hardware, yet it still feels like we're in the Stone Age of computer programming.

Not being an Artifical Intelligence person myself, I can't judge how well this book serves as a guide to AI. But Norvig's stated goal was in large part to show the history of AI, and he does that very well. (This was history back in 1992 when the book was written, so it's even older now, but still interesting.) He walks through implementing a lot of famous AI programs from the past, and explains their limitations and how they can be improved. Want to write ELISA or other chat-bots? He does that. Want to write an Othello-playing program? He does that too.

One of the best things about this book is that Norvig's code is just about the Lispiest code I've seen. He does many things that take full advantage of all the nooks and crannies of Common Lisp and wouldn't make much sense in other languages. This is a good book to help you think in Lisp.

So I recommend this book. Though I'm unsure I'll ever manage to absorb most of the information in it.

PAIP, review one of probably many

Wed, 06 Feb 2008 01:12:18 -0800

I got through the first four chapters of PAIP yesterday and today. It's good so far. I had reservations about spending $80 on a book, but it's 950 pages and almost all of it is good stuff, from what I can see at a glance. Little space is wasted on introduction material or tutorials for people who know nothing about programming. He dives right into the good stuff in chapter four.

Already I've picked up a few nice bits of info, interesting standard functions / macros like TRACE which is good for debugging. And SUBLIS which takes a list of (key . value) sublists and replaces all the keys with all the values, in some other list. Common Lisp is such a freaking huge language, in terms of its standard library of functions. Good thing or bad thing? It may be a bad thing if not for the fact that you load Lisp once and it persists forever.

Norvig makes an interesting point about the REPL. What do most programs need to do? Take input from the user, do something with it, and give output back to the user.

To get input, your program can read from command-line args, or prompt to STDIN, or take it out of text fields in a QT app, or read it from a config file. But it's generally always strings. So you get some strings, and then what? You have to figure out what the strings say, and either turn the strings into something usable or use the strings to figure out what action to perform. So you may have a dedicated library to parse command-line args and a dispatch table to map them to function calls. Or you may match the strings against a regex and depending what the strings look like, turn them into your language's representation of an integer or float using some "parseInt" or "parseFloat" functions. Or if your strings are XML, you may parse them into some big funky XML structure, then access bits of that structure to figure out what to do.

In Lisp on the other hand, you happen already to have a powerful reader/parser at your disposal: the REPL itself. It already knows how to read string representations of lists, numbers, pathnames, and many other things, and it can turn them into Lisp objects for you with no effort on your part. If you were using Ruby or Perl, short of ~~evil~~ eval, you wouldn't get anything close to that capability in your program.

What's more, the REPL knows how to read string representations of Lisp code (new functions and function calls etc.), and evaluate the code and end up with Lisp objects. It would be like if you wrote a C program which prompted you for input, and the input you gave could be a string representing a new C program that when run would produce a string that contained your input (or produce in-memory C structures your C program could use). So the main program would call GCC and compile and run your input to get results and use those results as its final input. Except that still wouldn't be nearly as powerful as what Lisp is doing.

So if you can figure out how to shape your input into a form that the Lisp reader can read, you're set. And it so happens sexps are a great representation for a great many things. Maybe this is part of why Lispers seem to worship the REPL and shun compiling their apps into command-line, standalone executables? Maybe this is part of what's meant by the oft-quoted-to-death Greenspun's 10th Rule?

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Much more PAIP to follow. It should be enjoyable. There's nothing like a good book.

On Lisp (review)

Sat, 24 Nov 2007 22:09:32 -0800

Paul Graham's On Lisp is available in PDF form (and Postscript) for free download, so I thought I'd give it a read. It's an older book (early 90's) and you can tell. It has a lot of good knowledge if you can make it past some of the things that obscure the more relevant parts.

A lot of the code given in the book favors efficiency over simplicity and readability, which is probably a product of the book being 15 years old and written by someone who's clearly been programming for a lot longer than that. It's something I notice a lot in older books. Of course there was a good reason for it: you had to worry about efficiency if you wanted your program to finish before next year.

Given today's computers and the kind of programming I tend to do personally, I don't care about efficiency beyond making my code "fast enough". Very rarely does this ever mean manipulating my code to make it tail-recursive so my compiler can optimize away some of my function calls, which Graham devotes a lot of effort to in the book. Someone once said something about "premature optimization" which I'm sure everyone is familiar with and may apply here.

(But I have a ton of respect for people who programmed computers back when every clock cycle and every byte of RAM was precious. I'm not sure how I could've ever managed in that kind of world. Sometimes it seems like you had to be a genius to get anything done back then. Maybe necessity was the mother of invention though.)

Common Lisp was apparently just being standardized or being heavily revised when this book was written, judging by much of what Graham writes. A lot of stuff I read in Practical Common Lisp that Seibel glossed over as being "something the old-school Lispers used to do" is in full-effect in Graham's book, and a lot of what Graham mentions as "new" is probably very solidly standard nowadays. Graham uses lambdas for EVERYTHING: data storage, algorithm optimization, sometimes even just to introduce a new lexical scope. And our primitive friends the CAR and CDR and their many cousins make plenty guest appearances in this book, to the detriment of my poor brain.

Graham also glosses over a lot of the code in his book and leaves it to speak for itself, making this probably a book intended for far more advanced Lispers than I. For an intro to Lisp I still highly recommend Seibel's book; his code and prose are so transparent and easy to understand that it's a joy to read. Graham's book reads more like a math textbook.

If you can get past all of those things, there's clearly a lot to learn from the book. It's really amazing some of the things you can pull off in Lisp, and Graham gives a great demonstration. Many of the design principles that Graham lists as goals for his new language Arc are explained really well in this book, so it's worth a read if you're interested in that. It's funny that a book about Lisp often blurs into a book about programming language design, probably because as Graham says, when you write Lisp you often build the language up to your program at the same time you build your program down to the language.

K&R

Wed, 12 Sep 2007 14:07:28 -0700

I got K&R (the ANSI C version) as one of the going-away presents from my current / last job, and I just finished reading it.

A lot of what's in the book is sort of review for me now but there were some things I'd never seen before. For example in the book they like to put function declarations inside other functions instead of globally at the top of the file. I never even thought to do that, for whatever reason. I also was unfamiliar with some of the more obscure corners of the C language, like register variables. Apparently the book was just written when ANSI was becoming / had become standard, so it's also fun to get a small glimpse at how things were before that. (They looked to be a mess.)

It's definitely the kind of book I wish I'd have had back in high school when I was just learning to program. For example the very straightforward explanation of how file handles work in Unix systems is nice and clear and is one of those things that I was wondering about for years in my youth: How is it that I can access stdout, stdin and stderr without doing anything? Where are those handles coming from? They seemed to be there like magic, and I never knew if it was always safe to assume that I'd have those available in every programming language I used on every OS I tried, or what. Likewise, I remember in the vast majority of programs I wrote in high school, I would trip up over I/O buffering. K&R explains that really well also.

Things that everyone "just knows" and assume that you also know are the biggest pitfall in learning computers, to me. Unix / Linux seems chock-full of that kind of crap. How do you know to try --help or man to figure out how to use a command? How do you know that ~ means "home directory"? How do you know that you start X via startx? If you don't know those things, short of asking someone else, it's very hard to discover how to do them. For people who know how to do it, it's such common knowledge that no one bothers to write it down. It's a huge leap that people have to make when first learning Linux or programming in general. A book like K&R is great because it gives you a starting point, and they explain pretty much everything. "Comprehensive" is probably the word I'm looking for.

In any case, as a rule, I detest low-level programming, of the "bit-twiddling" form. But there's obviously a need to know how to do it at times, and I think if I was more in the practice of falling back to C or other low-level languages when the problem at hand demanded it, I would probably be a better programmer. So I'm glad to try to learn more of it.

Design Patterns continued

Tue, 14 Aug 2007 21:49:46 -0700

I'm about halfway through Design Patterns: Elements of Reusable Object-Oriented Software, and it's pretty good. I can't read Smalltalk very well, so that's an impediment, but most of the code is C++ so it's OK. The book itself is very well-written. The patterns are laid out in a clear and thorough format, explaining pros and cons, giving good examples of when to use each pattern and when not to. The patterns are grouped by what purpose they're trying to serve, and similar patterns are compared / contrasted. The book sounds almost like it's trying to prove to the world that design patterns really are practical and relevant, which is amusing in hindsight because they obviously succeeded in doing so, at least among some large portion of programmers today. The "Lexi" example program used to introduce patterns in the first third of the book is pretty dated at this point, based on what looks like Motif and Windows 3.1 widgets etc., which isn't surprising given that this book is from 1994.? But the catalogs that come after are still very relevant and a joy to read.

I've been struggling with something in a Rails app I've been working on. It has to do with how to organize a hierarchy of parallel "model" classes. I had a sort of Eureka moment reading Design Patterns, when I realized one of the patterns is exactly what I need to solve this problem. That's always good. My original solution was a horrendous hack involving runtime editing of classes to inject methods into them, and it was entirely broken when pushed beyond a certain point.

For some reason I tend to overlook inheritance as a "decision-making" tool.? Saying "I'll take any object that implements this interface" or "I'll take any object of this class or its subclasses" is a nice open-ended yet well-structured way of implementing a conditional.? "When you give me an object, if the object meets these criteria (by nature of being of a certain type or implementing a certain interface), proceed, else fail immediately."? You let the compiler or interpreter do the work for you.? And if the object meets the criteria, you can use it while blindly assuming it'll work as expected.? I'm always muddling up my code and trying to juggle a million things at once and doing other classes' work for them in all the wrong places, instead of letting classes properly handle their own business independently.? I definitely have some bad programming habits that I'm trying to unlearn, with some success I think.? If nothing else, I have experience doing things the wrong way and clearly seeing how and why they're wrong and the price of being wrong, so hopefully in the future I can avoid the same mistakes.

So, the book is largely about design decisions.? Not just breaking a problem up into parts, but breaking them up into parts with the right granularity, and with the right relationship to other parts, and with the ability to be easily used in the future to solve other problems.? That's the hard part of programming, I guess: making those design decisions.? For me anyways, at this point.? The book is helpful in that regard.

It's interesting how so many of these patterns have little or no relevance to Ruby. For example, the Abstract Factory pattern. The book uses Smalltalk as an example of a language with classes that are themselves objects like any other objects; a language with class objects can just use the class objects themselves as factories. As the book says, a class object is already a factory: a factory that produces objects of a single sort. And produces them very nicely, for that matter.? But other patterns do apply to Ruby. Obviously it also depends somewhat on the specific problem you're trying to solve, but it's fun to try to think of which patterns might be more relevant than others given how different a language like Ruby is from a C++ or Java or what have you.

DISASTROUS

Wed, 25 Jul 2007 21:06:35 -0700

If only I had a dime for every time Stroustrup used the phrase "This would be disastrous". It can refer to everything from misuse of pointers, to making your destructors non-virtual in a class that will be a base class for some derived class, to all sorts of other C++ pitfalls. I got my copy of Effective C++: 55 Specific Ways to Improve Your Programs and Designs today, and Meyers seems to use the same phrase a lot too. Maybe that says something about C++.

Maybe it's my twisted sense of humor, but I really get a kick out of that kind of over-the-top hyperbole though. The other thing I get a kick out of is programs that insult their users. You can't beat that for a laugh. Scott Meyers has already insulted the average uninformed C++ programmer a bunch of times in his book, and I'm only on chapter 1. Clearly good times are ahead.

Although I'm theoretically "done" reading Stroustrup, I've resolved to go back through the book and do all the end-of-chapter exercises. I figure that's a good place to start before trying any kind of larger project in C++. He must've included all those problems in there for a good reason. I can already think of something at work I'm going to try to redo in C++ to try to speed it up a bit compared to the Ruby version I have now. (I doubt I could make it any slower than Ruby if I tried.)

Tonight though I was distracted by a really fun site called Project Euler, which is a collection of small mathematical-type programming problems that you can try to solve for fun. I finished 15 of the 159 problems after work tonight. All in Ruby, of course. But I think I did the easy ones. Some are harder than others. But according to the FAQ, all problems on the site are meant to be able to be solved in less than a minute of runtime on a modern computer. Some of the problems are brute-force solvable but some others require some sophisticated algorithms to have any chance of solving before the universe ends. Coming up with an algorithm for a problem that has a nice big-O runtime is by far one of my weakest areas, so this is good practice.

You can register on the site, write a solution, submit it and it'll tell you if you're right. It also collects statistics (if you choose to give them) about who's using what programming language to solve the problems, and what country you're from. And then it ranks how many people use each language, and how successful each languages' users are (going by how many problems they've solved). So in that sense the whole site is a kind of programming language battle to the death. (Did some people really solve these problems in Tcl?)

If that site is any judge, C and C++ (lumped together perhaps inappropriately, according to Stroustrup anyways) is/are the most popular language(s), followed by Python and Java. Ruby made a good showing, which makes me happy. Ruby's immense standard libraries make many of the problems there trivial no-brainers. Either way, this seems to indicate that there are a lot of C programmers out there. Or it may be that the number-crunching mathematical nature of these problems lends itself well to C, which is why so many people picked C to solve it.

Agile Web Development

Fri, 27 Apr 2007 21:14:47 -0700

Today at 5:00 I bought Agile Web Development with Rails. As of now 10:15 I have finished reading it. Pretty good book. I think for Rails you really need either a good web tutorial or a good book or about a month to read through the API. Way too much stuff is done by convention to ever learn it all otherwise. And the jargon thrown around is impressively extensive. Routes, actions, views, partials, layouts... these things don't mean much without a really good knowledge of the context of Rails.

I decided I needed to ingest a book sooner rather than later. I have too much tendency to dive face-first into coding without doing enough preparation or planning, and then having to backtrack and redo a lot of things differently. I guess that's always part of programming, but I rather want to minimize it as much as possible.

So this weekend begins the grand Rails experiment. I'm going to port all of my other website into Ruby. Or get as much done this weekend as I can, at least. We'll see how this goes.