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