It can be functional, just as it can be object oriented or procedural, but those labels matter less to what Lisp is than does the intense focus on things like metaprogramming, in my opinion.
There was always more to Lisp (I read a cute essay from the mid-60s about how to balance assignment-and-goto style programming with recursive-pure-function style programming in Lisp), but older people making that connection isn't unreasonable, or younger people who've only heard older people talk about it.
More, early lisps were far more up front about their imperative abstractions. Something that we try our damnedest to hide from folks nowadays. In ways that are actually hard to fully explain. Used to, you were given an array of functions not just as a programmer, but as a user of the machine. The "side effects" of the functions were the point of them. They literally made the machine do something.
So, yes, functional has always been a defining element of lisp. I can fully support that statement. The defining element, though? I have a hard time supporting that one.
As for what makes Lisp "different," I think it was true in about 1960 that it was mostly the functional support. It hasn't been for a long time, but I just think that people who don't know Lisp assuming that it is isn't completely unfounded.
> More, early lisps were far more up front about their imperative abstractions.
I will say that I have no idea how someone could look at Common Lisp and not realise it was largely an imperative language unless they had some major preconceptions going in.
Love that quote from McCarthy, btw. I have not seen that before. Is there more in the context of where that came from?
So it might not be 60 years ago, but 40 is already quite some years.
Rather, I was claiming that most of the hallmarks of functional code in today's programs wasn't possible in older hardware. Specifically, many of the "functional data structures" that people are growing to love nowadays were decidedly not possible on so little memory.
I could also given Symbolics as example.
As 40 year old examples, in 20 years the use of Lisp improved a lot since the early IBM mainframes.
My assertion is that "functional" is not the defining feature of lisp. My evidence is much of modern functional programming was not done for a large part of it's history. My claim is further that many modern idioms couldn't be done on older hardware. Not that lisp couldn't run there, but that modern practices couldn't. Regardless of language.
Functional is certainly a feature. Even a prominent one. Just not a defining one.
I've never claimed that functional was not a facet of lisp. Just that it is not the facet.
Now, the claim I'm making that requires the most evidence is that many of the common functional datastructures people learn of today would not have been feasible on older hardware. I will not claim that they are too slow. I will claim that they are a bit too memory intensive for older hardware.
So, immutable lists are not equal to cons lists. Since most implementations allow direct modifications of cons lists. (Scheme bucked this trend, and people laud it for that. But it was certainly not the norm early on.)
Similarly, the highly branched vectors and other datastructures popular in clojure and friends are just too unfriendly to hardware. Could they have been done? Possibly, but the mutable structures had massive advantages on the hardware of the time. (Arguably, they still have advantages, just nowadays we get to make more tradeoffs between bleeding performance and maintenance.)
I'm definitely open to the idea what I'm saying is flat out wrong. I doubt I've reached my quota on stupid claims for my lifetime. And if my reading of your post was as off as one of the siblings where you weren't trying to contradict my claim, but strengthen it, my apologies. :) And my thanks for sticking with the thread.