And yet it has among experts and textbook authors for nigh-on 60 years. It's even sometimes presented (quite credibly, imo) as the feature which makes all the other aspects of functional languages worthwhile.
I didn't notice purity become quite the deal it's become until recently, when boosters started talking it up as a concurrency panacea. Sure it's always been ubiquitous, and mutability was seen as a tricky tool that's best used sparingly, but that was seen as a matter of culture as much as it was a matter of definition. Valuing immutability definitely wasn't presented as functional 'territory' - a somewhat difficult position to hold given things like the PURE keyword in Fortran, or the variable and constant keywords in Ada.
It's pleasant to think of how far we've come, that now most people can just take it for granted that they can pass around functions, that functions can be anonymous, and that closures work more or less the way they ought to. The only languages I can think of that don't support this stuff are ones that are old (like C), or low-level on purpose (again, like C), or defined by a community that is chronically hidebound (like Java). There seems to be a loose consensus among successful programming language makers that higher-order functions and closures are reasonable and expected.
In the future, I expect the next things to become mainstream from the Weird FP Languages will be more type inference, and side-effect annotations. I've often wished that I could declare a few types in a language where you normally omit them, and have the compiler infer as much from those declarations as it reasonably can. I know it's possible, because the SBCL compiler for Common Lisp already does it. This gives many of the same benefits as stricter typing, but in a very lightweight way. And the idea of side-effect annotation is that you can declare whether or not functions have side-effects, and then have the compiler warn you if your code breaks that assumption -- like the PURE functions in Fortran you mentioned. Considering the dangers of mutable state, anything easy you can do to help keep it straight is probably a win.
(Note that in a sufficiently extensible language, e.g. Arc, these things can easily exist outside the language core. I hope that this kind of extensibility becomes mainstream, but wouldn't get my hopes up.)
> It's even sometimes presented (quite credibly, imo) as the feature which makes all the other aspects of functional languages worthwhile.
In other words it doesn't matter how we define "function" as long as they are first class? that's nonsense.
Regardless of historical (ab)usage "functional programming" should be re-appropriated to mean (from wikipedia): "a programming paradigm based on mathematical functions rather than changes in variable states".
Functions are from math, and mathematical functions are first of all pure (f(x) = x + 1 shouldn't also give your dog a bath).
I didn't notice purity become quite the deal it's become until recently, when boosters started talking it up as a concurrency panacea. Sure it's always been ubiquitous, and mutability was seen as a tricky tool that's best used sparingly, but that was seen as a matter of culture as much as it was a matter of definition. Valuing immutability definitely wasn't presented as functional 'territory' - a somewhat difficult position to hold given things like the PURE keyword in Fortran, or the variable and constant keywords in Ada.