The author very clearly defined what he means by functional, and he is correct, idiomatic Lisp is not. IF being a value-returning expression only encourages functional programming in the author's sense, since functions with conditionals can be written without explicit control flow where you can sneak side effects in. But, to be clear, flow control doesn't affect functional purity, and so it can be said that IF expressions vs. statements don't actually provide more or less functional behavior.
With side effects rife within Lisp's standard library, and with things like dynamic variables included with the language, I have a difficult time believing that it would be easy to "abstract out" side effects with some macros, while simultaneously providing a convenient, broad set of capabilities to program with. At that point, you might as well use macros to compile a whole new DSL within Lisp.
Defining an already used word to mean something precise and then arguing based on that is fine when constrained to a subset of technical readers who are used to this idea (you see this a lot in philosophy papers), but when publishing to a general readership you can't expect people to just accept that.
I would agree with you if the author did not explicitly say what he meant, and assumed the reader knew what he meant, but the author did not make any such assumption.
In order to quell the issue of "functional" having many definitions, the author chose one, and wrote about it. I don't see your alternative, which seems to be "accept that functional means something different and write about that", as one that is worthwhile to pursue.
Maybe to acknowledge that "functional" is used with a different meaning, often, would be sensible rather than just pretending all one needs to do is re-define it from common usage and proceed.
People are not compilers. If you want to redefine a word that is already in your readers' vocabulary with a meaning ascribed you've kind of got to talk about why you're doing that and why your redefinition is worthwhile and the alternative, generally accepted meaning needs to be jettisoned. Or you risk unintentional impersonation of a crank, which would be a shame if you're actually correct.
The point here is that the definition in the article is not something new. The author merely chooses to pick an accepted definition of functions, and build from there.
You makd it look like he's trying to push a new definition, which is not true.
> The author very clearly defined what he means by functional, and he is correct, idiomatic Lisp is not.
But if the definition is the author's own special definition, the conclusion may be true and still be completely uninteresting. The standard definition is the standard one for a reason - it turns out to be useful for having meaningful conversations about the issue.
But even if you accept the author's definition, then you run into:
> In fact it can be argued that lisp is one of the least functional languages ever created
For that to be true, "one of the least functional languages ever created" must be a really large set. That set must include, say, 95% of all languages ever created - which makes the claim not a very meaningful statement.
If you think the author's definition is clear and precise, then Haskell definitely doesn't qualify as functional by that definition, either. E.g., Haskell only encourages writing functions (i.e. total functions), so by that definition it also just encourages functional programming. See my other comment: https://news.ycombinator.com/item?id=13601299
With side effects rife within Lisp's standard library, and with things like dynamic variables included with the language, I have a difficult time believing that it would be easy to "abstract out" side effects with some macros, while simultaneously providing a convenient, broad set of capabilities to program with. At that point, you might as well use macros to compile a whole new DSL within Lisp.