briancarper.net (λ) (Tag: Books)

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.

Technology ain't everything

Fri, 12 Feb 2010 15:40:55 -0800

Let's discuss can openers.

Growing up, my parents would often invest in electric can openers. These things never worked. Some of them sit robot-like on top of the can and walk themselves around the top while chopping the metal. Some of them were mounted on the wall and you somehow get the can to hang in a harness while the device spins the can around. It takes a PhD and double-jointedness to get the can set up in these devices properly. And then you push a button, a lot of noise happens, and usually the can ends up half-open, half-bent up to the point where it's un-openable short of dynamite.

When I open a can, I use one of these. You jam the metal bit into the can and turn the crank, the can spins in a circle and 10 seconds later, off comes the razer-sharp top. The one I own was probably manufactured in the 1980's and it's still sharp enough to open a can with minimal effort.

Is it really that hard to turn a handle for 10 seconds? Do we really need computer-controlled robotic can-opening devices?

Consider books. I still buy and read all of my books in the form of compressed wood pulp. There are newfangled e-book readers, but I don't want one. Why? Because the only places I read are 1) In the bathtub, and 2) Lying in bed. Taking a computer into the bathtub is generally not a good idea, and holding a Kindle above my head for 3 hours is awkward compared to lying a (3-D) book on the bed beside me with one page bent up so I can read it. (Note: I have dropped a book in the bathtub on more than one occasion, and contrary to my expectations, once it dried it was still perfectly readable, no ink runnage at all.)

I know some day, maybe soon, paper books are going to be gone and we're all going to read books from digital devices. But I like my books. I know there are benefits to having electronic books instead of paper ones. But even though they're a waste of space, even though they can have pages ripped out, even though they can burn up or smudge or age and become brittle, I like paper books better.

Mostly I like paper books because they're simple, analog devices. I don't have to mess with any kind of user interface. Books don't have battery life. Books don't have copy protection. Books don't require me to sign up for user accounts at some website and worry about having an internet connection. I can flip through the pages with my fingers. I can tell how many pages are left by the thickness of the pages that are left. I have actually never comfortably finished a long e-book, not even books about programming, where you'd think the ability to copy/paste code would be a boon. I'll pay good money for a paper copy of a book even if the electronic version is free.

This is probably the most banal thing I've ever written about. But there is such a thing as too much technology. I say this as a person who spends all day trying to get people to use databases instead of keeping drawers full of paper records. Technology for the sake of technology is a waste of time.

2009 in review

Mon, 04 Jan 2010 21:18:38 -0800

2009 sucked because I was living in a different country than my wife, thanks to months of Canadian immigration paperwork and bureaucracy. This situation is going to be changing in the immediate future, which means 2010 will not suck.

I did have a lot of time to learn things, which is good. I got all kinds of things accomplished at work, learned some supervisory skills (shudder), wrote some code that was put to good use etc. My websites grew in popularity slightly. I learned Clojure and had lots of fun banging out a few apps. I tried to learn Haskell and failed. I feel like I advanced in origami a bit. I inched ahead slightly learning Japanese. I figure in another 50 years I'll know Japanese enough to say "Hello, I know Japanese but I'm too old to use it for anything now".

I read a gratuitous amount of books. I got into Asimov for the first time; usually I dislike sci-fi, but his stuff is good. I found Neal Stephenson, and wish I'd have found him earlier. I read more programming books than I can remember. I found some interesting books on psychopathy and other psychology-related topics, and read plenty of Richard Dawkins and other sciency and atheismy books.

There just isn't enough time in the day to learn everything I want to learn. I come home from a day of writing code all day at work, goof off on the internet a bit, talk to my wife, and then I read books and write code until 3 or 4AM, and it's still not enough time.

I have apps I want to code, drawings I want to draw, origami I want to fold, video games I want to play, movies I want to watch, music I want to listen to, and the list of books I want to read keeps growing faster than I can read them, even given that I already read 4 or 5 books per month. If I had a social life, I can't imagine how little time I'd have for these things.

This year I almost want to slam the brakes on, spend a lot of time with my wife, and let my brain settle. I will definitely do that to some degree, but I can't stop learning in the meantime. I'm running out of years. 29 years old, only four or five good decades left, if I'm lucky, and my brain will be deteriorating the whole time. At least I have plenty to keep me busy.

Let's parse

Tue, 15 Dec 2009 20:46:07 -0800

Is there anything more fun than parsing strings? I submit to you that there is not. I'm currently reading my way through Parsing Techniques - A Practical Guide, which has a first edition free online. (I'm hoping Santa brings me a copy of the 2nd edition this year.)

This is a good book, with enough math to be rigorous but not so much that it's completely unreadable. It starts from the absolute basics ("What's a grammar?") and goes through the Chomsky hierarchy and then dives into parsing techniques in great detail, in a language-agnostic way.

Languages and grammars are fascinating. In high school I studied Spanish, French, Latin and German, largely in my spare time. When I was 16, if people asked what I wanted to do for a living, I said "translator".

The plan to become a translator failed partly because the quality of my early education was horrendous and partly because mastering a language is extremely difficult and at 16 I wasn't motived enough. And then computers showed up in my life, which gave me a never-ending supply of languages to play with, while being fun (and profitable) in so many other ways. But I still took two years of Japanese classes in college for no reason other than enjoyment, and I'm still trying (and failing) to learn Japanese in my spare time 8 years later.

Perl was my first favorite language probably for no reason other than regular expressions. I can understand how people call PCRE syntax line-noise, but to me it's beautiful line noise. I live and breathe regular expressions nowadays. My favorite CS class in college was one where we went through and laboriously built finite-state automata and pushdown automata and Turing machines. Seeing the equivalence of these simple machines with the different classes of grammars was a huge epiphany. Such a simple concept with such huge consequences.

Dijkstra said:

Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.

I strongly agree with that sentiment. People tell me at times that I'm good at written communication. I have my doubts, and anyways I find it funny because I'm so terrible at verbal communication. I think if I have any success at writing, it's because I view writing as a mechanical process.

I told a prof in college once that I felt like my papers wrote themselves once I had an idea in mind. There are rules of grammar and style, and you learn them and follow them, or break them deliberately if you have a good reason to. You write some prose, then you debug it until it "works" mentally. I don't care about typos and I split infinitives and comma-splice on purpose, but ambiguous or awkward phrases usually stand out to me like compiler bugs in my brain.

What's more important than language? Few things. Language is important enough to be nearly hard-wired into our brains. Children learn it instinctively. Human beings can still easily and effortlessly out-perform the best supercomputer at the task of parsing and interpreting speech. We think in words. The programming languages computers understand are dirt-simple by comparison, but writing code still feels like writing "thoughts for the computer" sometimes.

There are very few times you'll hear me say "What a wonderful world we live in". But one of those times is when I have the opportunity to explore an area of study like language. It's such an enjoyable experience to struggle and try to master such a thing. It's an amazing universe where we have these weird little rules and they work and we can understand them and manipulate them and produce things with them.

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.

Real Confusing Haskell

Thu, 02 Apr 2009 23:44:54 -0700

I can pinpoint the exact page in Real World Haskell where I became lost. I was reading along surprisingly well until page 156, upon introduction of newtype.

At that my point my smug grin became a panicked grimace. The next dozen pages were an insane downward spiral into the dark labyrinth of Haskell's type system. I had just barely kept data and class and friends straight in my mind. type I managed to ignore completely. newtype was the straw that broke the camel's back.

As a general rule, Haskell syntax is incredibly impenetrable. => vs. -> vs. <-? I have yet to reach the chapter dealing with >>=. The index tells me I can look forward to such wonders as >>? and ==> and <|>. Who in their right mind thought up the operator named .&.? The language looks like Japanese emoticons run amuck. If and when I reach the \(^.^)/ operator I'm calling it a day.

Maybe Lisp has spoiled me, but the prospect of memorizing a list of punctuation is wearisome. And the way you can switch between prefix and infix notation using parens and backticks makes my eyes cross. Add in syntactic whitespace and I don't know what to tell you.

I could still grow to like Haskell, but learning a new language for me always goes through a few distinct stages:

Curiosity -> Excitement -> Reality Sets In -> Frustration -> Rage ...

At Rage I reach a fork in the road: I either proceed through Acceptance into Fumbling and finally to Productivity, or I go straight from Rage to Undying Hatred. Haskell could still go either way.

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.

Functional programming hurts me

Sat, 02 Feb 2008 00:53:23 -0800

This post will probably come back to haunt me, but functional programming doesn't sit well with me. I'm trying again to read through SICP. Last time I tried, I lost track of it and gave up after a few chapters. This time I hope to persevere, and I'm trying to go more slowly through the examples to really understand things.

I was trying to do some of the exercises in chapter 1 today, and pretty much bombing on all of them. Most of the exercises I've seen so far in SICP sound like they came out of a math book. "There is a clever algorithm for computing the Fibonacci numbers in a logarithmic number of steps..." Uh huh. This is not the kind of problem I enjoy, or have even the slightest use for. But maybe the problems are only pointless examples to illustrate a point, like "mass-less friction-less pulleys" in physics textbooks. I can live with that I guess.

Here is a Scheme example from SICP to compute b to the power of n:

(define (expt b n)
  (expt-iter b n 1))

(define (expt-iter b counter product)
  (if (= counter 0)
      product
      (expt-iter b
                (- counter 1)
                (* b product))))

This is presented as a wonderful and novel functional programming approach.

One of my problems is the amount of brain-work it takes to understand this. OK, start with EXPT. We take b and n, and then call some recursive helper function with b, n, and a state variable product initialized to 1 HEY WAIT A SECOND THERE'S A STATE VARIABLE?!

This is one way to cheat in functional programming, I guess. product is a variable name / symbol, which describes "something" that takes on different values over time, each value representing the same "thing" in different states. That qualifies as a state variable to me. The only difference is that the state variable is actually N different variables (with the same name) splattered across a bunch of frames on a call stack, instead of an abstraction of a single simple bucket where I dump a value.

Now in EXPT-ITER, counter starts at n, and every time the function calls itself, counter decreases by 1, until you reach 0, at which point EXPT-ITER stops calling itself and returns something. So this is a perverted, inside-out way of saying "do something N times", where every iteration costs me a recursive function call. Nice.

OK, what are we doing N times? We're multiplying product, which starts at 1, by b, which then becomes the new value of product next time around.

SO WHY NOT JUST WRITE THAT TO BEGIN WITH?

(defun simple-expt (b n)
  (let ((total 1))
    (dotimes (i n)
      (setf total (* total b)))
    total))

In Common Lisp this reads as "Let total start at 1. N times, set total to the product of total and b. Then return total." This is EXACTLY what the Scheme version is doing. Except I don't have to turn my brain inside-out to write it down this way. The CL code reads exactly like what the program is doing.

When all you have is a hammer, every problem looks like a nail. When all you have is recursion, every problem looks like it should be solved using recursion, I guess.

Actually if I ignore the functional programming bits, SICP is a great book. There are a lot of good things in there. But (so far) Scheme isn't one of them.

Sigh

Sun, 02 Dec 2007 03:20:45 -0800

Part of what Ableson and Sussman keep saying in these lovely lecture videos is that a good way to solve a problem is to divide it into layers of abstraction, where one layer of abstraction gets its work done by using a "language" that you wrote in the abstraction layer immediately below it. They say that a good way to solve a problem is to write something powerful enough to solve the general KINDS of problems that you're trying to solve, because you're probably going to need something that powerful later anyways. In these videos they tend to say in a very clear, direct, rigorous way things that I've heard said many times in other places by other people.

In particular, in the videos they stress trying to keep your "custom languages" written in such a way that they can be used recursively. My grand PHP project that I've been working on for some time at work is disturbingly similar to some of the examples they use in those lectures; namely, my project seems to be a good example of how NOT to do things.

My project is a set of scripts to build forms to conduct an interview. It's basically an enormous HTML form, but the form is split into pages, and the pages contain questions, which are groupings of HTML controls and text labels and Javscript and other things. To borrow language from SICP: questions are really my primitives. In addition to questions there are "groups" of questions that behave like single questions in certain circumstances but not others. And some questions have "sub-questions" that depends on them in hard-to-handle ways. So in SICP terminology: Questions can be combined by forming groups, or forming question/sub-question pairs, or otherwise just by listing them sequentially. The groupings can be into rows, or into columns, or into both, or into other kinds of patterns.

The program works by having someone write the survey in YAML, which is a very easy plaintext-ish way to write config files. Then my scripts parse the YAML, build my question objects and render them. The end. What I have though is essentially a custom language, with YAML as its syntax, used for building arbitrary surveys. It works fine and I was able to write our 20-page interview in this survey-language very easily. Ableson and Sussman would hopefully be proud (if highly disgusted by the details of my implementation in PHP).

When I was designing these scripts I do remember having the thought of whether I should make the questions in my language behave fully recursively. In other words I could simply make EVERY question have the ability to store references to one or more sub-questions. Then there would be only one kind of question, which may or may not have sub-questions. When I render a question, I'd just have it render itself and then render all its children recursively.

I gave that a try but gave up. In practice (so I thought at the time), questions should never really need to nest more than one or two levels deep, and the questions should only be combined into groups in a very limited couple of ways. So really, a fully recursive language wasn't necessary. So I wrote my language such that grouping questions together was a special case handled with extra code. Likewise sub-questions for normal questions were a special case handled with even more extra code. This worked OK.

If only I'd have seen these videos a month ago. This week I came upon a situation where the survey-building language I came up with isn't powerful enough to handle a certain type of grouping construct which I need. My language isn't arbitrary enough to let me do what I need to do. To make matter worse, looking at my code now, I realized that all the special-case code required to handle all the things I thought wouldn't be a problem has accumulated far beyond what I'd have ever expected.

Live and learn, I suppose. I think I was wandering down the right path, even if I fell off into the ditch before I reached the end of it.

Some other guy built a similar survey system for a different group at work a while back, and I had a chance to look at his code. That code consisted of one long listing of intermingled PHP, SQL and HTML, hard-coded throughtout to work specifically for the survey the group was conducting. I wanted to use those scripts myself but they were essentially unusable because they were so non-generic. I at least did better than that.

Even more Lisp

Fri, 30 Nov 2007 00:58:05 -0800

Having read and re-read Practical Common Lisp probably four or five times at this point if you add it all up, and having skimmed Graham's On Lisp enough to realize I need to come back to it later, I decided to move on to Structure and Interpreation of Computer Programs, which is a book available free online.

Side note: It's so wonderfully delicious that so many amazing books are available free online, isn't it? I'm almost in disbelief sometimes at how amazing that is. Such knowledge and secrets, not only easily accessible, but easily accessible for free. As I did with PCL, I'll probably end up buying one or both of the other books I mentioned above just because I like to have a hard copy of things to read in bed, but in the meantime the online version is great.

If that wasn't enough, you can also download (for free) videos of lectures covering this material, given by two guys who authored SICP. I'm only up to lecture 2b, but it's proving very informative to say the least.

SICP is a book apparently used in CS classes at MIT, and it deals with abstractions, the different kinds, and particularly functions and procedures as first-class objects and functional programming. The language used throughout is Scheme, which is different enough from Common Lisp to trip me up already. Although not being all that comfortable with CL at this point maybe also be a blessing, because if it turns out I like Scheme more I can make the switch without having to break any ingrained habits.

I've been watching the lectures and translating the Scheme they give as examples into CL as I watch, as a means of trying to familiarize myself with both languages. A while back I read about the Lisp₁ vs. Lisp₂ distinction but didn't pay it much mind. Then I read about it again on a Lisp mailing list last week, but didn't pay it any mind. Well today in the course of my Scheme -> CL translations, in a very roundabout manner, this distinction bit me and caused me no end of trouble. Which is funny because I still never saw it coming, even having read about it in two different places and two different context. But now at least I can say understand the distinction in a very tangible way. Just goes to show the only real way to learn a language is by writing code in it.

(You can read much more about Lisp₁ vs. Lisp₂ here. For those who don't want to read, and for my own future reference: Lisp₁ vs. Lisp₂ refers to whether there's a single namespace for functions and variables, or two separate namespaces for those things. Scheme has one namespace, CL standardized on two. This results in CL being much more verbose when calling lambdas and passing them around between functions, but also arguably results in CL being more suited to using macros without having to worry about name collisions. That's my probably limited understanding at this point. )

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.

expat

Sun, 12 Aug 2007 19:27:17 -0700

Thank you very much to numerodix's latest blog entry, which caused me to pay extra attention when upgrading system packages this week. I do read my elogs, but I don't read it as carefully as I should. I know I would have missed the warning about expat1 -> 2 necessitating a revdep-rebuild. I am going to tail them onto my desktop from now on.

expat really does affect a huge number of packages. Every GUI app on my system is affected. Possibly because GTK and QT are affected. But I don't know. urxvt and conky are also affected. Thankfully I had a Firefox window already open, along with a few urxvt terminals, when I did my expat upgrade. So as long as I don't close them I should be OK to keep using them for a while.

Looking at these issues, I realized today how little I know about the specifics of how linking works in Linux. I had a few days about it in a class on OS design in college, but it was a few years ago after all and we didn't go into much detail back then. This all inspired me to read up again on how linking works. I am reading this article on linux.org to start with. It looks like a good article, keeping in mind that someone who actually needs the article (e.g. me) is probably the worst person to judge whether it's a good article or not.

In other non-news, I recently ordered Design Patterns: Elements of Reusable Object-Oriented Software. I have a design patterns book already, namely Head First Design Patterns, but it's geared very specifically toward Java, and the whole book is written in a fairly unorthodox and sometimes extremely annoying way. It also doesn't cover ALL the design patterns, only a few. I'd like to read the original source, and read something that isn't polluted with Java ugliness.

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.

Mozilla C++ portability guide

Wed, 18 Jul 2007 19:48:40 -0700

I'm up to Chapter 18 of Stroustrup's The C++ Programming Language. The templates chapter was painful and I had to read it twice. I think I got it the second time through. Stroustrup talks about how people ask him how long it takes to learn C++ and he says (paraphrased) "a year or two probably; be happy, it's not as long as it takes to learn a spoken language or a musical instrument". It's still frustrating. The syntax and whatnot are so easy to learn, but the idioms and common practices take forever to ingrain.

Today in my somewhat futile half-hearted attempt to learn autotools, I chanced upon the Mozilla C++ portability guide It includes such advice as:

Don't use templates.
Don't use exceptions.
Don't use namespaces.
Don't use the C++ standard library, not even iostream.
Don't put assignments in if statements.
Use macros.

This is interesting, since it's the exact opposite of what Stroustrup writes. And Stroustrup also says he wrote this book in such a way as to demonstrate "standard" portable code. I guess I don't doubt that the Mozilla guys know what they're talking about, but if that's the extent you have to bend in order to write "portable" code, I hope I don't ever have to.

Interfaces

Thu, 12 Jul 2007 21:31:23 -0700

I'm done with 10 chapters of my new book so far. There's some good stuff in there. I'm always glad when I get a book that makes me realize how little I actually know about something, because it's probably a good sign I'm learning something.

Stroustrup makes some nice comments about interfaces. He wrote a little lexer/parser program and then showed how he would break up the code into logical chunks and organize it. He split the "user interface" and the "implementer's interface" into two different pieces in the process. I'd never seen a problem laid out in quite that way done before. But it made me think about a lot of problems I have at work. When I think of "interface" I think of what the end-user sees when running the program. But the code a programmer sees when dealing with code you wrote is also an interface. In the interests of expediency at work I often find myself thinking "I have no time to clean up the backend. I'm smart enough to figure this out anyways, who cares if it's a bit clunky?" I'm pretty sure that comes back to haunt me more often than it should.

As a novice programmer, it's an effort just to get something that solves a problem at all. As you learn more, you start to think about how to solve it well: efficiently and cleanly. I think the next step is when you take it for granted that all the little parts of your program will work as they should; the new problem is getting all the little solutions to play well with solutions to other problems. I wonder sometimes how much of that part of it can be learned and how much of it is having a proper aesthetic taste and a proper way of thinking about problems.

It always amazes me just how easy it is to write horribly crappy code. Computer programming is like trying to shoot a target with a gun that has a nearly overwhelming tendency to want to point at your own foot.

I love that new textbook smell

Wed, 11 Jul 2007 20:53:47 -0700

So as I alluded to after chattering on for hours, C++ is my new language of the week/month(/year?). My copy of The C++ Programming Language came in the mail a day early today, so I got to read it on the bus ride home from work, which was fun. I've apparently already read five chapters without realizing. Time goes fast I guess. It's been a long time since I did homework problems, but I gave some of the ones in the book a shot.

You can really tell this is a book for geeks. From (?1.1.2):

The exercises vary considerably in difficulty, so they are marked with an estimate of their difficulty. The scale is exponential so that if a (1) exercise takes you ten minutes, a (2) exercise might take an hour, and a (*3) exercise might take a day.

Then he goes on to give some problems a difficulty of (*1.5), which means some exercises have fractional exponents for difficulty levels. I haven't quite worked out how many hours that comes to.

There's probably a reason all the non-geeks at work recoiled in horror when I gleefully brandished my shiny new book at them. For some reason no one took me up on my offer to let them read my book during their lunch break. Their loss.

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.

Dilemmas continued

Sun, 18 Mar 2007 13:13:56 -0700

I previously prattled on about what the right abstraction should be for an icon theme. I said a hierarchy of subclasses would work.

I was very wrong. It didn't work at all. For example I tried to write a == method for my Icon class. With the class structure I was using before, the only thing I could compare between two Icons is the icon name. In which case, two icons of different sizes in different contexts would have to be considered equal. That's not right. The only other option was to make some kind of is_equal? method all the way at the top of the class hierarchy, and have it construct a complete picture of an icon on the fly, and use that in the comparison. That kind of defeats the whole purpose of setting up the class hierarchy that way to begin with.

A better abstraction is a single Icon class with size and context as properties. An icon needs to know these things about itself. I recently was reading Head First Design Patterns and one of the first "rules" it gives is:

Favor composition over inheritance.

It's right in this case. I was tripped up by the fact that on disk a size does contain a context, and a context does contain an icon. But there's no reason my abstraction needs to match that structure.

On a side note, it's a good book, even though it mostly deals with Java. Many of the "design patterns" it gives are workarounds for the inflexibility of Java itself, but it does give some interesting ways of looking at certain problems.