His code here demonstrates why. It is both shorter and much easier to understand than anything the LLMs generated. It is not always as efficient as the LLMs (who often skip the third loop by calculating the last factor), but it is definitely the code I would prefer to work with in most situations.
[1] https://www.udacity.com/course/design-of-computer-programs--...
WITH all_numbers AS
(
SELECT generate_series as n
FROM generate_series(1, 108) as n
),
divisors AS
(
SELECT *
FROM all_numbers
WHERE 108 % n = 0
),
permutations as
(
SELECT a.n as n1, b.n as n2, c.n as n3
FROM divisors as a
CROSS JOIN divisors as b
CROSS JOIN divisors as c
)
SELECT *
FROM permutations
WHERE n1 * n2 * n3 = 108
AND n1 < n2 And n2 < n3
ORDER BY n1, n2, n3
It's amazing how he never used the words "AI" once in this course despite the fact that it is a straight up AI course.
I revisit the course notes at least once a year and I still walk away with something new every time.
But it's especially great if you want to appreciate PN's code more. He actually offers explanations of choices for his distinctive style of coding here. His 6 rules for good code are particularly good. He says they are for good lisp but I think they broadly apply to any language:
https://github.com/norvig/paip-lisp/blob/main/docs/chapter3....
*Edit:* After reading this book I am often really surprised that this book is not referenced as often or more often than SICP is. Not the time or place for a soapbox rant but SICP is often cited as landmark functional programming text when in fact it is largely advocating OO practices implemented in scheme, whereas PAIP really demonstrates full power FP programming on display (type system independent), and where OO practices such as CLOS are used he is quite explicit about it.
Speculating: the sheer bulk of the book might also push people away. It's usually an anti-signal for riches within.
https://web.archive.org/web/20140122073352/https://www.udaci...
Yes, I know that you can get the Q value via RL with Bellman equation or non-parametric evo learning, but at the time I didn't know that and I'm glad I didn't.
Depending on how you count, this code features either 2 or 4 mutually recursive functions, something that is quite rare in Python (esp outside the context of an FSM) but is a signature of PN code.
I had to learn so much about so many things to untangle it.
I think this makes sense. LLMs are trained on average code on average. This means they produce average code, on average.