A Retrospective on PAIP (2002) | Hacker News Reader

A Retrospective on PAIP (2002)

norvig.com

31 pointsTomte5 comments

PAIP is absolutely great in terms of lessons for software engineering. i do not think you need to know lisp before hand in order to digest it. what's more you can now read it in nice markdown format [0]. however an even better solution, if you want to work through the book, is to convert markdown files to org documents [1] and enjoy the book interactively via org-babel [2]. for those unfamiliar, this is like having a book released as a jupyter notebook, except better. in any event if you are interested don't be afraid of lisp, it is a super-easy syntax to learn

[0] https://github.com/norvig/paip-lisp

[1] https://emacs.stackexchange.com/questions/5465/how-to-migrat...

[2] https://orgmode.org/worg/org-contrib/babel/intro.html

Only one past submission with a comment:

https://news.ycombinator.com/item?id=27353083 (1 comment)

PAIP is still on my list to work through.

Last time I tried I got as far as the first substantive program (https://github.com/norvig/paip-lisp/blob/main/lisp/gps.lisp), was generally confused by the code, and was then not surprised when the following sections pointed out all the faults (i.e. bugs) with the initial approach and suggested various improvements. I've come to trust my own "how can this possibly work?" confusion as a strong signal that a design is probably buggy or fragile, so it was nice to see it confirmed here.

Which is not to say that what this book teaches is not useful, but I wouldn't go to it looking for best practice and robust software engineering techniques. Much of what I saw in this book wouldn't pass code review in many situations ("too fragile" or "too clever"). Most of what he's talking about are techniques that "allow a programmer to delay making decisions". This is a different kind of programming than very the very concrete kind of programming that can dominate day to day professional work. I suspect that these kinds of "delayed decisions" are best applied sparingly, but applied correctly they can be powerful.

To get a flavor of the "Norvig approach" to things, his Advent of Code solutions in IPython notebooks are fun: https://github.com/norvig/pytudes

i have a different understanding. the book teaches a design process that starts of by understanding the problem you are trying to solve, then working out the specification of your program, followed by implementation, followed by introducing tests, followed by code analysis and review in order make correct abstractions to build a general modular code-base that can be used across different applications. i am not sure about your experience, but as far as i know this is a very up-to-date approach in software engineering. for reference here is the chapter on GPS [0], which by the way is the first non-introductory chapter! i think you should work more through the book before holding strong opinions about it

[0] https://github.com/norvig/paip-lisp/blob/main/docs/chapter4....

> Which is not to say that what this book teaches is not useful, but I wouldn't go to it looking for best practice and robust software engineering techniques.

It's actually demonstrating the iterative style of software development, which has come to dominate the way we develop software. Though the problems are, generally, "small" so it's not a full-scale application of it. Which is also nice as a teaching text. Instead of showing a fully-formed solution, he walks through the ideas of solutions, identifies problems (which the reader may or may not have noticed themselves), and then resolves them (usually with much more general forms of the program than the previous versions, as well). This is very helpful because seeing the thought process can convey a lot more than just seeing the final solution.

Reply on news.ycombinator.com