Books

From A History of the English Speaking Peoples by Winston Churchill:

In our own fevered, changing, and precarious age, where all is in flux and nothing is accepted, we must survey with respect a period when, with only three hundred thousand soldiers, widespread peace in the entire known world was maintained from generation to generation, and when the first pristine impulse of Christianity lifted men’s souls to the contemplation of new and larger harmonies beyond the ordered world around them.

No Starch Press sent me a copy of The Art of R Programming last Fall and I wrote a review of it here. Then a couple weeks ago, Manning sent me a copy of R in Action. Here I’ll give a quick comparison of the two books, then focus specifically on R in Action.

[click to continue...]

When Flannery O’Connor went to the University of Iowa for graduate school, her mentor Paul Engle could not understand her Georgian accent. Engle later recalled his reaction when she asked to attend his workshop.

Embarrassed, I asked her to write down what she had just said on a pad. …

Like Keats, who spoke Cockney but wrote the purest sounds in English, Flannery spoke a dialect beyond instant comprehension but on the page her prose was imaginative, tough, alive: just like Flannery herself.

Source: Flannery O’Connor: The Complete Stories.

Here is a recording of O’Connor reading her story A Good Man is Hard to Find. I don’t find her at all hard to understand. The recording was made 13 years after her first encounter with Engle, and perhaps her accent had moderated. Or perhaps my ears are simply accustomed to Southern speech.

Here’s a very simple idea: Use Project Gutenberg for content and Readability for style.

Project Gutenberg has a large collection of public domain books in digital form. The books are available in several formats, none of which are ideal for reading. Project Gutenberg provides text without much styling in order to make it easier for people to use the content as they please.

You can go to the HTML version of a book on Gutenberg and use Readability (or Instapaper) to format it for easier reading. Importing the HTML page to a Kindle similarly improves the formatting.

***

Has anyone made a style sheet to approximate the look of Readability or Instapaper? I’d like to use something like that to improve the appearance of the static HTML pages on my site.

In 1926, Houston completed construction of a new public library. This building has been restored and reopened to the public this month. My wife and I visited the library yesterday and I took a few photos.

When you visit the library, now known as the Julia Ideson building, the staff recommend you begin your tour on the third floor to see the ceiling.

[click to continue...]

A computer science degree doesn’t prepare you to be a programmer. Here’s an excerpt from a blog post I wrote comparing computer scientists and programmers:

I had a conversation yesterday with someone who said he needed to hire a computer scientist. I replied that actually he needed to hire someone who could program, and that not all computer scientists could program. He disagreed, but I stood by my statement. I’ve known too many people with computer science degrees, even advanced degrees, who were ineffective software developers. Of course I’ve also known people with computer science degrees, especially advanced degrees, that were terrific software developers. The most I’ll say is that programming ability is positively correlated with computer science achievement.

How do you bridge the gap between obtaining a computer science degree and becoming a professional programmer? For years I’ve recommended that CS grads read Code Complete. Now I’d also recommend New Programmer’s Survival Manual by Josh Carter. This new book has some similarly to Code Complete. However, Code Complete is about good programming technique, not programming as a profession.

The Survival Manual has four parts:

1. Professional Programming
2. People Skills
3. The Corporate World
4. Looking Forward

The first part has the most similarity to Code Complete, though even there the two books are complementary. The second part, people skills, has some great advice, though I imagine most CS graduates will skim over this part because they don’t realize it is important.

CS students may do well to read the Survival Manual, especially parts one and three, to find out whether they want to be programmers. Some who find abstract computer science fascinating will find a typical programming sorely disappointing. See Mike Taylor’s post Whatever happened to programming.

A few of these may be able to find refuge as computer science professors, but not many. If you want to become a professor and think you’ll be able to get an academic job, watch So you want to get a PhD in theoretical computer science and read No, you cannot be a professor.

The Survival Manual assumes the majority programmers will be working in cube farms on enterprise software, which is true. But there is a small middle ground between enterprise development and academia, jobs that will give you a chance to use advanced computer science without having to write papers about it.

One reservation I have about this book is that it may be overwhelming. If you have a friend who is starting a new career as a programmer, maybe you could buy a copy of the Survival Manual and rip it into chapters. Then mail your friend one chapter a week.

Another reservation I have is that new CS graduates may not benefit much from the book because they won’t believe it. They may deny that the real world is as Josh Carter describes.

The people who may benefit the most from reading the Survival Manual are programmers with some experience who want to improve their skills. They may have learned through hard knocks about some of the challenges Carter writes about. Also, Carter describes life in a software shop with fairly high standards. Those who are used to producing lower quality software will do well to read about life in an organization with higher standards.

Related posts:

Where does programming effort go?
Coming full circle
Writing software is harder than writing books

“There never was a time when those that read at all, read so many books by living authors rather than books by dead authors. Therefore there was never a time so completely parochial, so completely shut off from the past.” — T. S. Eliot

via I Read Dead People

Posts related to T. S. Eliot:

Historical sense
Calendars, Connections, and Cats

Posts on old books:

Firsthand knowledge
Applied topology and Dante

In The Art of Readable Code, the authors call the following the “Fundamental Theorem of Readability”:

Code should be written to minimize the time it would take for someone else to understand it.

They go on to explain

And when we say “understand,” we have a very high bar … they should be able to make changes to it, spot bugs, and understand how it interacts with the rest of your code.

The Tangled Web is a security book that you may find interesting even if you’re not interested in security. The first half of the book is an excellent explanation of how Web technologies work in theory and especially in practice. This material is included in order to discuss security implications, but it’s interesting on its own. The second half of the book is directly devoted to Web security.

The author, Michal Zalewski, has a colorful writing style. His book is serious and loaded with technical detail, but that doesn’t stop him from turning a nice phrase here and there.

Here’s an excerpt from The Tangled Web that I particularly liked, one that explains why security concerns on the Web differ from previous security concerns.

In the traditional model followed by virtually all personal computers … there are very clear boundaries between high-level data objects (documents), user-level code (applications), and the operating system kernel … These boundaries are well studied and useful for building practical security schemes. A file opened in your text editor is unlikely to be able to steal your email …

In the browser world, this separation is practically nonexistent: Documents and code live as parts of the same intermingled blobs of HTML, isolation between completely unrelated applications is partial at best …

In the end, the seemingly unlikely scenario of a text file stealing your email is, in fact, a frustratingly common pattern on the Web.

If you’re not interested in a subject, do cartoons make it more palatable?

My guess is that cartoons may help keep your attention if you’re moderately interested in a subject. If you’re fascinated by something, cartoons get in the way. And if you’re not interested at all, cartoons don’t help. The cartoons may help in the sweet spot in between.

No Starch Press has given me review copies of several of their Manga Guide books. The first three were guides to the universe, physics, and relativity. I’ve reviewed these here and here. Recently they sent a copy of the newest book in the series, The Manga Guide to Biochemistry.

I’m much more interested in physics than biology, so I thought this would be a good test: Would a manga book make it more interesting to read about something I’m not very interested in studying? Apparently not. It didn’t seem that the entertaining format created much of an on-ramp to unfamiliar material.

It seemed like the information density of the book was erratic. Material I was familiar with was discussed in light dialog, then came a slab of chemical equations. Reading the book felt like having a casual conversation with a lawyer who periodically interrupts and asks you to read a contract.

Someone more interested in biochemistry would probably enjoy the book. Please understand that the title of this post refers to the fact that I find biochemistry uninteresting, not the book. If I had to study a biochemistry book, the Manga Guide to Biochemistry might be my first choice. At times I’ve found biochemistry interesting in small doses, describing a specific problem. But it would be nearly impossible for me to read a book on it cover to cover.

O’Reilly’s “Head First” series is similar to the Manga guide series, though the former has more content and less entertainment. I enjoyed the first Head First book I read, Head First HTML with XHTML & CSS. Maybe I enjoyed it because the subject matter was in the sweet spot, a topic I was moderately interested in. The cartoons and humor helped me stick with a dry subject.

When I tried another Head First book, I was hoping for more that same push to keep going through tedious content. The books clearly had the same template though with different content. What was interesting the first time was annoying the second time, like hearing someone tell a joke you just heard. So at least for me, the Head First gimmick lost some of its effectiveness after the first book.

From C. S. Lewis:

It has always therefore been one of my main endeavors as a teacher to persuade the young that firsthand knowledge is not only more worth acquiring than secondhand knowledge, but it usually much easier and more delightful to acquire.

This quote comes from the essay On the Reading of Old Books, part of the collection God in the Dock: Essays on Theology and Ethics. Lewis says here that it is easier to read Plato or St. Paul, for example, than to read books about Plato or St. Paul.  Lewis says that the fear of reading great authors

… springs from humility. The student is half afraid to meet one of the great philosophers face to face. He feels himself inadequate and thinks he will not understand him. But if he only knew, the great man, just because of his greatness, is much more intelligible than his modern commentators.

This does not only apply to literature. I see the same theme in math. Sometimes early math papers are easier to read because they are more concrete. When I was a postdoc at Vanderbilt I asked Richard Arenstorf about a theorem attributed to him in a book I was reading. He scoffed that he didn’t recognize it. He had done his work in a relatively concrete setting and did not approve of the fancy window dressing the author had placed around his theorem. I sat in on a few lectures by Arenstorf and found them amazingly clear.

The same theme appears in software development. Sometimes you can dive to the bottom of an abstraction hierarchy and find that things are simpler there than you would have supposed. The intervening layers obscure the substance of the program, making its core seem unduly mysterious. Like a mediocre mind commenting on the work of a great mind, developers who build layers of software around core functionality intend to make things easier but may do the opposite.

Related posts:

Endless preparation
Opening black boxes
Why Shakespeare is hard to read
C. S. Lewis on reading old books

Martin Gardner (1914 – 2010) was best known for his articles on recreational mathematics, especially his column in Scientific American which he wrote from 1956 to 1981. Once Gardner wrote a letter of recommendation for a young man applying to graduate school at Harvard.

I don’t know a lot about mathematics, but this kid invented two of the best card tricks of the last ten years. You ought to give him a chance.

The kid was Persi Diaconis. At the time, Diaconis, like Gardner, was something of a mathematical outsider, someone with more creativity than credentials. Diaconis went on to become a mathematics professor at Harvard and won two MacArthur genius awards. He is now a professor at Stanford.

Source: Magical Mathematics

The tautochrone is a curve such that a ball rolling down the curve takes the same amount of time to reach the bottom, no matter where along the curve it starts. (The name comes from the Greek tauto for same and chrono for time.) It doesn’t sound like such a curve should be possible because balls starting further up the curve have longer to travel. However, balls starting higher also have more potential energy, and so they travel further but faster. See the video below for a demonstration.

[The video is entitled "brachistochrone race" rather than "tautochrone race." The brachistochrone problem is to find the curve of fastest descent. But its solution is the same curve as the tautochrone. So different problems, same solution.]

I first heard of the tautochrone as a differential equation problem to find its equation. But someone could run into it in an American literature class.

Clifford Pickover’s new book The Physics Book has a chapter on the tautochrone. (In this book, “chapters” are only two pages: one page of prose and one full-page illustration.) Pickover points out a passage in Moby Dick that discusses a bowl called a try-pot that is shaped like a tautochrone in the radial direction.

[The try-pot] is a place also for profound mathematical meditation. It was in the left hand try-pot of the Pequod, with the soapstone diligently circling round me, that I was first indirectly struck by the remarkable fact, that in geometry all bodies gliding along the cycloid, my soapstone for example, will descend from any point in precisely the same time.

Here are my first impressions of The Art of R Programming. I haven’t had time to read it thoroughly, and I doubt I will any time soon. Rather than sitting on it, I wanted to get something out quickly. I may say more about the book later.

The book’s author, Norman Matloff, began his career as a statistics professor and later moved into computer science. That may explain why his book seems to be more programmer-friendly than other books I’ve seen on R.

My impression is that few people actually sit down and learn R the way they’d learn, say, Java. Most learn R in the context of learning statistics. Here’s a statistical chore, and here’s a snippet of R to carry it out. Books on R tend to follow that pattern, organized more by statistical task than by language feature. That serves statisticians well, but it’s daunting to outsiders.

Matloff’s book is organized more like a typical programming book and may be more accessible to a programmer needing to learn R. He explains some things that might require no explanation if you were learning R in the context of a statistics class.

The last four chapters would be interesting even for an experienced R programmer:

• Debugging
• Performance enhancement: memory and speed
• Interfacing R to other languages
• Parallel R

No one would be surprised to see the same chapters in a Java textbook if you replaced “R” with “Java” in the titles. But these topics are not typical in a book on R. They wouldn’t come up in a statistics class because they don’t provide any statistical functionality per se. As long as you don’t make mistakes, don’t care how long your code takes to run, and don’t need to interact with anything else, these chapters are unnecessary. But of course these chapters are quite necessary in practice.

As I mentioned up front, I haven’t read the book carefully. So I’m going out on a limb a little here, but I think this may be the book I’d recommend for someone wanting to learn R, especially for someone with more experience in programming than statistics.

Related post:

R: The Good Parts