4 ms·

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/g

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 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 https://github.com/norvig/pytudes

medo-bear 5y ago
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.md https://github.com/norvig/paip-lisp/blob/main/docs/chapter4....
Jtsummers 5y ago
> 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.

medo-bear 5y ago

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.md https://github.com/norvig/paip-lisp/blob/main/docs/chapter4....

Jtsummers 5y ago

> 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.