Review of “ANSI Common Lisp”

Posted on July 14, 2008
Filed Under Programming, Programming Languages | 8 Comments

Why Lisp?

A few months ago, I decided that this summer would be the summer I learn Common Lisp. There are two bloggers who are at fault for this decision: Steve Yegge and Slava Akhmechet . Linked are the pertinent articles, both proposing and explaining the idea of data storage as a Lisp program.

The idea is beautifully simple: Why spend the time to parse and transform your XML into usable code when you can get parsing, for free , in an equivalent S-expression? To me, this is simple, yet profound. it helped me realize why I wanted to learn Lisp: It’s interesting . Lisp is functional, it uses a very different syntax than any other coding I’ve ever used, its macro support causes pseudo-religious experiences, and a lot of very smart people swear by it.

At this point, I’ve spent almost a month going through ANSI Common Lisp by Paul Graham. I’ve read through the book once, and I have played around with a lot of the exercises in the top-level interpreter. I am currently solving all of the exercises, chapter by chapter.

\

How was the book?

The Good

I would never in good conscience let someone teach themselves their first programming language with this book, but it works very well for the experienced programmer. Mr. Graham explains most of the concepts very clearly, programmer-to-programmer. He gives design rationale, anecdotes, interesting history, helpful diagrams, and good examples.

As opposed to many authors that attempt to build all knowledge from the ground up, Mr. Graham starts by giving the reader enough tools to be dangerous. The first coding chapter, Chapter 2 , gives the readers functions, printing, variables, lists, conditionals, and introduces the idea of recursion for the uninformed.

For me, this was wonderful. Once I figured out what Lisp environment I wanted to use (I ended up using SBCL in Slime), I spent some time experimenting with the Lisp equivalents of the building blocks I knew from other languages. If anything can be learned of Paul Graham from Arc, it is that he likes to experiment. In this vein, he gives the reader plenty of opportunities to play with the syntax of Lisp.

The explanations of the fundamentals (cons, predicates, lambdas, structures, etc) were all very well done. Unfortunately, his meticulous explanations were not a constant through the whole book. For example, the explanation of functional programming techniques like closures was cursory, even though he constantly refers to the importance of functional programming in Lisp. Were better explanations the victim of strict editing? It’s difficult to tell.

These missing or unsatisfying explanations were few and far between, however. For the most part, this book was well-conceived and well-explained.

The Great

Some of my favorite math books are the texts that have tons of examples, and Paul Graham followed this style successfully. The biggest challenge of learning Lisp is thinking in Lisp. I’m used to a C++ style syntax and thought process, so Lisp was hard to work with in the beginning. Thankfully, the example code written for the book was up to the challenge: In fact, it was the best part of the book.

Every idea presented comes with the necessary code to run it. Every chapter has one or two minor sample applications that use the concepts presented in the chapter. Typing these into the top level interpreter and puzzling through their rudimentary logic helped infinitely more than his explanations. This is not to say that the explanations did not belong in the book. However, they were at best a supplement to the sample code.

Mr. Graham also includes a few badass applications, such as ray tracing. The book has examples of real programs that perform interesting work, and the practical grounding gives the book a sensible air.

The Cons

Some of the exercises left for the reader showed quite a bit of carelessness on a few levels.

First, some of them were not even solvable, Chapter 3 standing out in my mind. One of the exercises asks you to find the longest finite walk in a graph, cycles allowed.

You show me your longest finite walk with a cycle, and I’ll show you one better.

Next came the lack of volume of exercises. All of the exercises are short exercises. Very short. Each of the questions either asks you modify a previously-written program in some minor way, or to write a small snippet of code.

The lengthy puzzles were lengthy because I was trying to find a common trick, such as passing a lambda function to a reduce call in order to switch argument order. On one hand, I appreciated these puzzles, but couldn’t help but wonder if they were better suited as examples in the text.

Don’t get me wrong! A lot of the questions are there to ensure that the reader has learned very basic Lisp concepts, and the book wouldn’t be as effective without them. However, I never got the appreciation for medium-scale application design in Lisp. All of the problems were very small and situational, designed to help the newbie understand simple features of Common Lisp.

Do you recommend this book?

Absolutely.

At the end of the day, coding books are just an excuse to get the reader to write code, and ANSI Common Lisp succeeds marvelously. Code is clearly the central focus of this book, and most of the code is well-supported by explanations. Even though there were not enough programming exercises, and there was a notable absence of hard programming assignments, this text works very well as a “First Common Lisp Book”. Going through all of the exercises will give you a nice introduction to Common Lisp, and if you’re like me, an in-depth examination of compiler and interpreter errors of the Common Lisp implementation of your choice.

Do I feel like I am a Lisp programmer? Hardly. However, this book has given me an appetite for learning more about the language.

Next up:

Paradigms of Artificial Intelligence Programming by Dr. Peter Norvig. Given its size, I’m sure the review will be ready by 2012.

Popularity: 27% [?]

Graham and Feynman Meet in the Middle

Posted on July 11, 2008
Filed Under Programming, Quote | Leave a Comment

I’m working through ANSI Common Lisp by Paul Graham right now (book review on Monday), and I found this little chestnut:

Experienced Lisp programmers work bottom-up as well as top-down. While they’re writing their program down towards the language, they also build the language up toward their program.This way, language and program meet sooner, and more neatly.

~ Paul Graham, Section 6.4 ANSI Common Lisp

I immediately noticed a correlation to Richard Feynman’s appendix to the Rogers Commission Report on the Challenger Space Shuttle disaster, written almost a decade before Graham’s publishing date:

The usual way that such engines are designed (for military or civilian aircraft) may be called the component system, or bottom-up design. First it is necessary to thoroughly understand the properties and limitations of the materials to be used (for turbine blades, for example), and tests are begun in experimental rigs to determine those. With this knowledge larger component parts (such as bearings) are designed and tested individually. As deficiencies and design errors are noted they are corrected and verified with further testing. Since one tests only parts at a time these tests and modifications are not overly expensive. Finally one works up to the final design of the entire engine, to the necessary specifications. There is a good chance, by this time that the engine will generally succeed, or that any failures are easily isolated and analyzed because the failure modes, limitations of materials, etc., are so well understood. There is a very good chance that the modifications to the engine to get around the final difficulties are not very hard to make, for most of the serious problems have already been discovered and dealt with in the earlier, less expensive, stages of the process.

The Space Shuttle Main Engine was handled in a different manner, top down, we might say. The engine was designed and put together all at once with relatively little detailed preliminary study of the material and components. Then when troubles are found in the bearings, turbine blades, coolant pipes, etc., it is more expensive and difficult to discover the causes and make changes. For example, cracks have been found in the turbine blades of the high pressure oxygen turbopump. Are they caused by flaws in the material, the effect of the oxygen atmosphere on the properties of the material, the thermal stresses of startup or shutdown, the vibration and stresses of steady running, or mainly at some resonance at certain speeds, etc.? How long can we run from crack initiation to crack failure, and how does this depend on power level? Using the completed engine as a test bed to resolve such questions is extremely expensive. One does not wish to lose an entire engine in order to find out where and how failure occurs. Yet, an accurate knowledge of this information is essential to acquire a confidence in the engine reliability in use. Without detailed understanding, confidence can not be attained.

~ Richard Feynman, Appendix F, The Rogers Commission Report

Popularity: 19% [?]

ICANN and Ctrl-Alt-Shift-Tilde-Backflip

Posted on July 7, 2008
Filed Under Misc | 1 Comment

The Background

On June 26th, ICANN decided that the world needs more top-level domain names. Instead of the big three: .com, .org, and .net, we can now look forward to top-level domains such as .pepsi, .nyc, and .travel.

This plan wasn’t forged from malice. There are quite a few benefits to the proposal. For example, users of non-Roman alphabets will find new support for native-language domain names. However, I found my gut reaction strongly critical the idea, so I ended up putting a little bit of time into thinking through the (negative) consequences of the move.

Expectations and Security

A lot of my initial concerned boiled down to the following question:

Is it wise to change one of the foundations of the internet this late in the game?

I don’t mean this from a technical standpoint, but rather a human standpoint. Unlike most of the technical organization of the internet, people actually interact with top level domains directly in multiple ways.

First is the grouping idea behind the expansion: even though usage is currently very limited, there is a practical difference between google.com and google.cn: without even looking at the sites, I know that I am far more likely to understand the content on the first domain than the second domain. After looking at the sites, I am 100% sure I can’t understand the content at google.cn, and am mystified about the goofy hover-animations at the bottom of the page. Obviously, the proposal aides this human interaction with the internet.

Second is the simple issue of memory: At the moment, I can’t think of a site that I regularly use that has a domain other than .com, .net, .edu, and .org. That really limits the amount that concerns me when I memorize a new location on the web. Is this a big deal? Not really. Is it a factor? Absolutely.

Last is the security of top-level domain names. We all know that we shouldn’t go to www.mybank.com.info. That’s not to say nobody ever goes to phishing sites, but it’s a simple and useful safeguard against the faceless evil on the internet.

The security aspect of the top-level domain switch had me worried for a while. Let’s say that the newly formed .travel domain allows anybody to nab a new travel account. After all, a lot of people like to travel. Why not let them create their own .travel blogs about travelling?

Unfortuantely, this opens up an unfortunate can of worms. Can you trust a visit to orbitz.travel, a seemingly innocuous domain at the nascent .travel top-level domain? Was it account.orbitz.com, account.orbitz.travel, or account.travel.orbitz?

This is not to say that any new top-level domain registrar will actually implement any of these measures. However, this will force a shift for a new mental security model.

What Actually Concerns Me

Soon, I realized that my concern over the proposal was just a defense of my boundless love of keyboard shortcuts! In Firefox, I’ve been using the domain completion keyboard shortcuts for a few years now, so much so that they have grown to be a necessary part of my browsing experience.

As my girlfriend can attest, a normal browsing session is not complete without the following exclamation/keyboard interaction:

“I wonder how the crazies are doing!” <Ctrl>-t, reddit, <Ctrl>-<Enter>.

It takes me literally less than a second to find out why Ron Paul thinks C++ is worse than Haskell’s type system (with benchmarks), and I will be crushed when I am forced to navigate to other websites without my precious keyboard completions. I will either have to <god forbid> type out the whole domain, or find a Firefox plugin that will let me use archaic shortcuts like <Ctrl>-<Alt>-<Shift>-~-<Backflip> in order to properly navigate to the .travel domain.

Keyboard Shortcuts? Are You Serious?

Absolutely not! The above section is triple-underlining my belief that the top-level domain switch will not be a technical issue, but will create extra people problems. Once the new top-level domains are activated, all internet users will have to go through a new adjustment (good and bad) on their conceptual models of organization and security of information on the internet.

Popularity: 11% [?]

« go back — keep looking »