[norvig]

Some points:

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

[flavio81]

>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

I'd like to interject for a moment.

As a software engineer with some years of using Python for financial software, and afterwards switching to Common Lisp, i diverge. In my opinion, Lisp macros make all the difference in the world, and I really miss them when using a language that doesn't support them. Sure, anything can be implemented on most languages including Python, but there is a big difference in the maintainability and clearness of the resulting code, as well as in effort.

So, are you abandoning us, Peter? If not nil, i will signal 'tears and no handler-bind will recover me from this condition. (joking of course)

Anyways, thanks for PAIP, it will always be in my heart.

(Note for the uninitiated: PAIP stands for "Paradigms of Artificial Intelligence: Case Studies in Common Unpython", a classic book by Peter Norvig who is part of the big PPP of Lisp literature: Paul (Graham), Peter (Norvig), and Peter (Seibel))

[kennytilton]

"The Lisp community likes to solve lots of problems with macros" sounds like "Mozart likes to use a lot of notes". I do not like to use macros, I like to hide boilerplate so the semantics stand out. And so I can type less. I do not like typing. But Siri can stuff it. I digress.

[kennytilton]

I gave this some thought. First, the silence was perfect and it was a privilege to witness that moment between you two. As for the thousand words, they were the hundred moves we do not see in a grandmaster draw after a half dozen moves from a well-understood opening and a handshake. John had by implication stood up for homoiconicity as essential. You conceded Python lacked the quality, leaving intact your equivalence argument built in part on other Python features and in part on missing things not mattering. Nothing more was needed.

But that is just my poor reconstruction of the moment. The silence was better.

[tobmlt]

I'm just a numerics person but I'd love to hear your input about relational/declarative/Prolog-like programming in Python in the following situation: if the working language doesn't have to be anything resembling Prolog, but can instead be a Python internal DSL(DSL-lite?), and further if, say, one wants to do unification only over (what amounts to) some numeric data, then Python's operator overloading can supply all the heavy lifting one needs - allowing one to build up a representation of the (computational) expression tree via overloading and then "compile" that guy into lists of relational function closures which await environments (design spaces). This is of course a really specific case, but as a "mechanical-type" engineer doing a thesis on automated geometry generation, and needing a pre-processor to quickly pair down my design space to something nice given a design specification on the fly, I've found python + unification + numerics (especially interval arithmetic - where the design space is basically closed...) to be a really useful (and work saving) combination! The end result feels like magic to me anyway. But lots of computing feels like magic to a numerical programmer - that's what makes it so fun to branch out - and Python makes that as easy as possible. (Thanks for all of your writings which help the novice do this kind of thing!)

I should summarize that long winded statement in case anyone tries to read it: eh hem... This one time, for this one specific case, off in a totally unrelated field of engineering, Python made for a pretty fair Prolog substitute for one kid's dissertation.

[kennytilton]

Was McCarthy even thinking of macros when he locked onto code as data? Or was he thinking code generation in pursuit of AI?Asking, do not know. I know macros are a great example of code=data, but I once had a ball using the AllegroStore CLOS database and a homebrewed DB synch layer to handle remote distribution and update of forms and the code to validate them in a clinical drug trial management context, where forms and their validation code are forever changing. Basically, an intractable software maintenance problem just disappeared. That's always fun. http://smuglispweeny.blogspot.com/2008/03/my-biggest-lisp-pr...

[dangerbird2]

He was not, macro libraries like defmacro and define-syntax were later addition to lisp. Well before formal macro systems were implemented, code-as-data was particularly useful for implementing the eval function in Lisp (the Lisp 1.5 implementation takes up less than a page), which greatly simplified the process of implementing compilers and interpreters.