
Practical Common Lisp
About this video
Peter Seibel's 2006 Google TechTalk on Practical Common Lisp, framed by the Sapir-Whorf hypothesis and Paul Graham's Blub paradox. It shows Lisp features such as condition restarts and its generic-function object system.
Why it appears in the archive
HN remembers it as the memorable explanation of restarts and multiple dispatch, referenced whenever those features come up.
AI-generated summary and labels from the source dataset; verify important details against the video. Source & credits.
From the Hacker News discussion
I agree that my macros explanation was stretched. I simplified it too much. Restarts are really nice, I first heard about them in "Practical Common Lisp" google talk: [VIDEO]
Read original comment ↗The author provides a good example of legitimate use of change-class with his compiler example. About violating "some earlier architectural plan" in the case of libraries: Being able to do this allows CL programmers to freely mix libraries with different "architectural plans" without resorting to some half-baked fusion architecture that has to account for the different styles used by the libraries. Last but not least, change-class is not a hack - it's behavior is well defined and documented. And when you consider that CL's "object orientation" is more generic that c++'s or java's, based on generic methods alone, inferring from c++- or java-paradigms to good CL style just does not work. Peter Seibel's talk "Practical Common Lisp" at google explains that pretty well: [VIDEO]
Read original comment ↗Peter Seibel's talk "Practical Common Lisp"[1] covers that from a different angle, also comparing multiple dispatch with the visitor pattern. [1] [VIDEO]
Read original comment ↗I will forever think of this talk by Peter Siebel (author of Practical Common Lisp) whenever I hear about multiple dispatch: [VIDEO]
Read original comment ↗Peter Seibel talks about it in Practical Common Lisp and in the talk he had at Google about the book: [VIDEO] The book is available online I think.
Read original comment ↗