But if we take a holistic view here, languages that treat paradigms as a thing have been trounced in the marketplace of ideas. And to find an example of a non-functional programming language your first instinct was to talk about Java 7 - where there is a strong consensus that if you were going to create a new program today it should not be used. We're up to Java 22.
The attempts from decades past to draw a distinction between OOP and FP paradigms has largely failed. Consensus seems to be that whatever is concise and easy to understand is best and attempting to force code into a paradigm is inferior to looking at specific individual features and techniques in context of the problem being tackled.
> "Functional Programming" doesn't have a precise definition at all as far as I know, so it is likely it doesn't refer to a real thing. Most of the paradigms are similar as they don't seem to actually mean anything.
> The distinguishing characteristics don't distinguish FP from anything.
> The attempts from decades past to draw a distinction between OOP and FP paradigms has largely failed. Consensus seems to be that whatever is concise and easy to understand is best and attempting to force code into a paradigm is inferior
This last statement is a marked departure from your original, first assertion which is a descriptive claim that functional programming, and indeed all paradigms, don't actually exist or mean anything; in it you instead make the normative claim that "attempting to force code into a paradigm is inferior," on the practical bases of concision or comprehensibility.
Moreover, if paradigms don't actually exist as per your first assertion, I find it difficult to understand what exactly it is we are "forcing code into" in your second statement. Clearly there exists some cluster of related features you are referring to when you point out the pitfalls of trying to pigeonhole your problem into a certain style of solution. As mentioned, Python even has a name for this cluster, and it's called the `functools` module, which lives alongside other implementation styles (OOP, procedural, etc.) in its multi-paradigmal space of solutions.
> And to find an example of a non-functional programming language your first instinct was to talk about Java 7 - where there is a strong consensus that if you were going to create a new program today it should not be used. We're up to Java 22.
The claim was basically that OOP and other paradigms don't exist; to refute the claim I supplied a counter-example of a language that leans so heavily towards the OOP side of the spectrum that writing FP code within it is prohibitive. Just because that language has been updated to incorporate techniques from other paradigms doesn't mean that the OOP paradigm ceased to exist once Java 8 came out. Just because following a "purist" FP or OOP approach is impractical does not mean that such categorizations don't exist, even if only as a limit or extreme to which varying languages tend to with varying degrees of resemblance. Java 22 can be considered mixed-paradigm, but it's probably still more OOP than Racket Lisp.
There is a difference between claiming that a distinction does not exist, and that drawing distinctions is an inferior or impractical approach.
In general I agree with the sentiment that one should be comfortable working with multiple paradigms, because as per the "expression problem" a strictly FP or OOP approach comes with tradeoffs, and which tradeoffs should be made depends on the particular problem being tackled.
The attempts from decades past to draw a distinction between OOP and FP paradigms has largely failed. Consensus seems to be that whatever is concise and easy to understand is best and attempting to force code into a paradigm is inferior to looking at specific individual features and techniques in context of the problem being tackled.