1,199 karma · joined September 21, 2007
I was also able to get to about a 2 second solution, but I didn't have to do bit operations: https://nbviewer.jupyter.org/github/norvig/pytudes/blob/mast...
- Yes, the original publication year was 2000. I've added that to the file.
- @HelloNurse: You've got the key point. I provided Lisp code to teach AI; but my goal was to teach AI, not Lisp. As more schools and students were familiar with Python and not with Lisp, I needed to make the switch to keep teaching AI effectively.
- @jonathanstrange: Yes, "batteries included" is key to Python; there is some pain in doing any change; this page attempted to alleviate some of the pain.
- @rauhl: "in the silence a thousand words were said". I'm not sure what words are in that silence. But to me, the words are: Lisp and Python are different ecosystems with different customs. The Lisp community likes to solve lots of problems with macros. The Python community doesn't. For 95% of the usages, neither approach is better than the other, they are just different. For example, in Python, `with` is a statement, and you define custom classes for each usage you think of. In Lisp, you define a macro like `with-open-file` for each usage. The end result in usability and efficiency is similar. In Lisp, you often define macros for custom data types, e.g.
(def-tree T1
root (A B C)
A (D E)
B (E F)
...)
In Python you use a combination of built-in data types (like dicts), custom classes, and ad-hoc parsers of text. Again, the approach is different, but readability and efficiency is similar.It is certainly true that if you want to define, say, a mock Prolog system, it is easier to do it in Lisp with macros than in Python, where you would need to deal with the far messier `ast.parse` module. Is that where the silent words were? For me the words would be "Lisp is a much better choice if your primary goal is defining a full-blown domain specific language. For most other programming tasks, the two languages offer similar functionality in different way."
Fortunately for both of us, he had been diligent about making backups and din't lose his entire thesis.
"What's an anagram of Banach-Tarski?"
A: "Banch-Tarski Banach-Tarski"
Good question. I think the engineering discipline part is much harder. I'm not sure that is because the problems really are harder: messier, ill-defined, changing over time; or whether it is that the academic community has focused on more well-defined formal/fundamental questions and mostly nailed them, so what we're left with is the harder messier stuff. Certainly it is easier for me to find someone to hire fresh out of college who has excellent CS fundamentals than to find someone with strong engineering discipline. And while my title included "Research", we all work very closely with Engineering.
Tell you what, Ill make a deal: I'll keep writing if you keep reading. K?