> Somehow I could not shake the feeling that homoiconic macros were intimately tied to the very essence of functional programming
That's the first time I've heard anything like this. Lots of great FP languages exist that are not dynamic or offer such macros, why would they be a requirement for FP?
It's not, he just couldn't shake shake the feeling. Kind of how you can't shake the feeling that there should be left-over pizza in the fridge, knowing very well that you already ate it all.
I think many of us probably tend to associate certain styles and features with functional programming that really are orthogonal to whether the program is functional or not.
As I've had it explained to me, if you write your program using functions whose output only depends on the arguments provided to that function, and nothing else, then you have yourself a functional program. But then again, people tend to treat the concept like a scale, with some programs (or languages) being more or less functional than others.
I think the problem hovers around the idea of first class ness. In Clojure, I can use a function like '<' as a key in a hashmap. In Python, I can't. Because '<' isn't a function, it's an operator in Python. First classedness has to do with non-complectedness. Python has operators and statements in addition to expressions. Clojure, because it's a Lisp, gets by with just expressions.
That would make the function pure, not necessarily make what you're doing functional programming. First-class functions and their manipulation is also a requirement, IMO
> whose output only depends on the arguments provided to that function, and nothing else, then you have yourself a functional program
You can choose to do this in any language, but that does not make any language conducive to FP. The other main ingredient is that a function should be a primitive data type in the language, and can be stored, re-assigned at run-time, passed to other functions, and returned from functions. Without this, you definitely cannot have a functional language.
Right! I didn't know that it would have to be a primitive in the language, and would have thought that functional programming was more of a methodology than a technology.
Wikipedia[1] seems to think that functional programming is a subset of declarative programming. It would be interesting to see a table, or possibly a decision tree, of possible language design choices to see the different parameters by which a language can vary.
FP is not a methodology alone. It requires language support.
Some languages support it better than others. Some are clearly and only functional, others offer many functional features but not the whole package.
Also, the degree that a language needs to support certain features to be called functional varies among developers. Some languages are very clearly not functional in any way, while others, like C++ since 2011, offer a lot of functional features but do not offer the same paradigms that languages like Clojure and Haskell offer. That's because the other "primitive" a language should support to be fully functional are persistent data structures that can be bashed on by numerous functions without performance cost. Such structures don't exist yet for C++ (though many have tried, and they might eventually), but are the core of Haskell and Clojure.
That's the first time I've heard anything like this. Lots of great FP languages exist that are not dynamic or offer such macros, why would they be a requirement for FP?