Peter Norvig has this unique style where he explains his design process in detail, including exploring the problem on example cases, writing multiple solutions, the thinking involved in moving from one solution to the next one, including profiling and finding bottlenecks etc., you see how he goes about problem solving and he is a master problem solver. In fact his writing provides a good opportunity to reflect on what designing programs even means: investigating and choosing trade-offs, choosing an adequate representation (data structure) for a problem etc. This illustrates on a small scale how a lot of the most serious software engineering happens, the engineering where you actually have a definite, hard problem to solve, rather than just making the program pretty by criteria on which there is no agreement etc.

He does this not only in those notebooks but for example also in his "Paradigms Of Artificial Intelligence Programming" book. I have not seen this done to any serious extent in any algorithm textbook or tutorials.

I code Python professionally (and passionately), and would consider myself quite experienced. His code in ' When Cheryl Met Eve: A Birthday Story' is the most beautifully constructed stuff in the world. That sort of stuff isn't about coding ability, it's about a reasoning process that some people have developed to such an extent that it's innately beautiful no matter how it's expressed. I'm sure his javascript solution would be nearly as beautiful.

> I'm sure his javascript solution would be nearly as beautiful.

I really like his Python code, but I think his Lisp code from PAIP is extremely underrated. In fact, it makes me sad he switched to Python for some AI tasks (same as Goodman & Tenenbaum in http://probmods.org) given that Lisp offers a unique feature for AI: homoiconicity.

This is something that I think will make a comeback with Bayesian program learning. For a glimpse of the future, see above link.

And how many great books and papers from before the early 80s are stacking dust in libraries and college archives ?

there are lots of lisp/fp books that aren't as known as PAIP. based on the few I took on ebay (henderson's recursion book and the likes) we might have a lot of surprises.

> His code in ' When Cheryl Met Eve: A Birthday Story' is the most beautifully constructed stuff in the world.

Where is this published? I couldn't look it up.

Isn't it right here? https://github.com/norvig/pytudes/blob/master/ipynb/Cheryl-a...

The content of the challenges aren't the focus. The main take-away is to see how Norvig does it after you've had a whack at it yourself. You can learn a lot by seeing how he reads the problem, dissects it into different functions, documents and tests them, and keeps an eye out for performance and computational complexity.

His code is highly readable and elegant, and I wish every single person I'll share a codebase with will have studied him before.

Ha, brilliant programmers can sometimes be hard to appreciate. They make problems look easy. But the simplicity comes from the complete understanding of the problem.

I think it's a trait of brilliant minds. They simplify things. I don't remember the exact quote, but it was something like this:

  * a fool doesn't understand
  * a normal person can be taught
  * a in intelligent person can teach
  * a genius can simplify

This reminds me of the quote attributed to Albert Einstein

“If you can't explain it to a six year old, you don't understand it yourself.”

I really thing what Einstein is getting at here is the ability to simplify things to the level that a six year old can understand it. Of course, you probably can't simplify the mathematics to the level of a six-year old, but you can simplify the concepts so that they are understandable by a six year old.

I've found this to be true in my own life. I think I understand something, but then I try to teach it to someone else and then I learn that I don't really understand it. So I have to go back and study and think about it so more until I understand it better. If I really understand thoroughly, inside and out, then I find that I am able to simplify things such that I can explain them to my young children.

This is why rubber duck debugging works. You start explaining to a rubber duckie what problem you have, how you're trying to solve it and what happens. Posting a question on a hostile forum or snarky IRC channel also works. When I think how to formulate my question best, to cause no misunderstanding, I often stumble upon the solution.

It is also why teaching people programming makes you a better programmer. Even if you're answering newbie questions, it often makes you re-evaluate your knowledge or realize you don't understand something as clearly as you thought. Even newbies have different needs and interests, so they ask different questions than you would.

And a slight twist on it, if you find the problem too hard, you're looking at it wrong.

We all had moments when we realized how stupid the solution was. Most of the things that eludes us trigger a chase for complexity when it's mostly trying simple stuff that aren't in our neural habits.

teaching involves didactic reduction, in other words: simplification; from the easy to the difficult, from the special case to the generalization.

You should check out Norvig's design of computer programs course on Udacity (https://www.udacity.com/course/design-of-computer-programs--...) where he uses these kinds of puzzle programs to teach programming design concepts. It is a hard but really rewarding course.

>I get it that Peter Norvig is a very smart programmer. But can someone explain to me - like a farmer to his cow - how do these resources differ from typical programming challenges found on the web ?

By virtue of being better written and more thought out.

Also, they are not "programming challenges". They are solutions to programming challenges.