Ooh Ooh My Turn Why Lisp? (2008)

Well, the key part is gracefully. Lots of languages can manipulate code as data, but so for for me only in homoiconic languages does it end up feeling graceful for a while (although as I noted, it stops feeling graceful pretty quickly).

As the other comment says, that doesn't really make sense. However, I have had to debug a codebase where lisps unhygienic macros led to extremely weird errors. The second time that happened in a big project I decided that schemes hygienic macros are superior. The extra cruft writing them is worth it. I have literally spent weeks debugging weird macro errors introduced years after the macro was first written.

> What I mean by “code in an object language is data in the metalanguage” is that, in the metalanguage in which you're writing a compiler or interpreter, the object language program that you're processing is represented as a data structure (say, as a syntax tree). It's just a triviality, I'm not saying anything really deep.

I understood what you were saying, and didn't ask for an explanation. I just don't see why you felt the need to correct me on my calling first=class functions "code as data" and substitute your own definition that had nothing to do with what I was saying.

> My definition of functional programming is “using (procedures that compute) mathematical functions whenever possible”. A mathematical function is a mapping from values to values, so if a language doesn't have a good notion of (possibly compound) value, then you're going to run into trouble writing procedures that compute mathematical functions.

Again, I didn't ask what your definition was, because it wasn't relevant to the conversation.

You're basically interrupting me to tell me I'm not using the same definitions of words as you are, and it's not particularly endearing. If you don't understand what I'm saying, I'll be happy to explain. If you do, however, understand what I'm saying well enough to correct me on my usage of the English language, then my usage of the language has been clear enough for my goals, so I wouldn't be interested in your corrections even if they represented HN's common usage (which they don't).

> I just don't see why you felt the need to correct me on my calling first=class functions "code as data"

Because first-class functions aren't “code as data”. When you have a first-class function, the only thing you can do with it is call it. If it were a data structure, you could analyze its constituent parts.

> You're basically interrupting me to tell me I'm not using the same definitions of words as you are,

The Wikipedia article you linked says:

“In computer science, functional programming is a programming paradigm—a style of building the structure and elements of computer programs—that treats computation as the evaluation of mathematical functions [emphasis mine] and avoids changing-state and mutable data.”

The emphasized part is just what I said. That a mathematical function is a mapping from values to values is unquestionable - it's not something I'm saying, it's a mathematical fact. So if you can't express compound values, you're limited to a world where mathematical functions can only manipulate primitive values.

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