> Let’s talk about code as data, shall we? What enables that? Of course, it’s the s-expressions and prefix notation.
s-expressions and prefix notation are orthogonal concepts. Nothing in the definition of s-expressions says it uses prefix notation. S-expressions are just a data format and its external notation.
> But we won’t want to write a macro that simply sits at the beginning of an s-expression and takes in a bunch of arguments, because then we could just write a function.
Functions and prefix notation are also unrelated concepts.
Lisp syntax uses prefix notation, but not everything is a function call. There are also Lisp variants, which don't use prefix notations, but still have s-expressions and even macros,
Take a lambda expression: (lambda (a b) (* a b (+ a b)))
It has a lambda symbol in prefix position, but it is not a function call.
> So the very first thing you do with your macro powers, and pretty much the only useful thing you can do, is break s-expressions.
Which is nonsense. Macros don't break s-expressions.
> Every future macro must account for every previous macro
Which is also nonsense. The typical macro expansion mechanism takes care of that most of the time.
> Once the first macro is written you can no longer assume that inputs to macros will be s-expressions with the function at the beginning and arguments following.
Well, now we not only have special forms (!), functions, lambda expressions, etc., but also macros. The main difficulty now is: more syntax and even user-defined syntax.
> First-class functions are a much more coherent, consumable way of using code-as-data.
Which are unrelated concepts.
> Most of the features of Common Lisp I actually want are in other languages now. Garbage collection? REPLs? First-class functions? Higher-order functions? They’re all in other languages now. Python, for example has all those things.
There are cars which have wings, can swim, etc. But that does not make them especially useful, say, to bring the kids to school every morning. The raw assembly of features is not the point, it's their integration for certain use cases.
> Wright-brothers style planes today and we shouldn’t use Common Lisp just because it was first to have those things.
Common Lisp wasn't first. CL was defined 26 years (in 1984) after Lisp (1958) was invented and standardized after ten years more work (1994).
> But I tend to think that learning functional programming is the part that people are referring to,
Not really. One can learn functional programming with much simpler languages. Legions of students used simple Lisp dialects/subsets to learn some FP concepts. See SICP (and many other books/courses) - which doesn't use macros, btw.
> and frankly, there are better languages in which to learn functional programming. Haskell, Standard ML, or OCaml would be a better choice.
Since Common Lisp was never designed to enforce or advance statically-typed Functional Programming, it's only logical that it is not particular good at it.
s-expressions and prefix notation are orthogonal concepts. Nothing in the definition of s-expressions says it uses prefix notation. S-expressions are just a data format and its external notation.
> But we won’t want to write a macro that simply sits at the beginning of an s-expression and takes in a bunch of arguments, because then we could just write a function.
Functions and prefix notation are also unrelated concepts. Lisp syntax uses prefix notation, but not everything is a function call. There are also Lisp variants, which don't use prefix notations, but still have s-expressions and even macros,
Take a lambda expression: (lambda (a b) (* a b (+ a b)))
It has a lambda symbol in prefix position, but it is not a function call.
> So the very first thing you do with your macro powers, and pretty much the only useful thing you can do, is break s-expressions.
Which is nonsense. Macros don't break s-expressions.
> Every future macro must account for every previous macro
Which is also nonsense. The typical macro expansion mechanism takes care of that most of the time.
> Once the first macro is written you can no longer assume that inputs to macros will be s-expressions with the function at the beginning and arguments following.
Well, now we not only have special forms (!), functions, lambda expressions, etc., but also macros. The main difficulty now is: more syntax and even user-defined syntax.
> First-class functions are a much more coherent, consumable way of using code-as-data.
Which are unrelated concepts.
> Most of the features of Common Lisp I actually want are in other languages now. Garbage collection? REPLs? First-class functions? Higher-order functions? They’re all in other languages now. Python, for example has all those things.
There are cars which have wings, can swim, etc. But that does not make them especially useful, say, to bring the kids to school every morning. The raw assembly of features is not the point, it's their integration for certain use cases.
> Wright-brothers style planes today and we shouldn’t use Common Lisp just because it was first to have those things.
Common Lisp wasn't first. CL was defined 26 years (in 1984) after Lisp (1958) was invented and standardized after ten years more work (1994).
> But I tend to think that learning functional programming is the part that people are referring to,
Not really. One can learn functional programming with much simpler languages. Legions of students used simple Lisp dialects/subsets to learn some FP concepts. See SICP (and many other books/courses) - which doesn't use macros, btw.
> and frankly, there are better languages in which to learn functional programming. Haskell, Standard ML, or OCaml would be a better choice.
Since Common Lisp was never designed to enforce or advance statically-typed Functional Programming, it's only logical that it is not particular good at it.