Maybe that's exactly why the likes of Elixir feel so much less functional than some other FP langs. You don't usually compose functions, merely use function application (|>).
To me, functional programming is the feeling that you can successfully reason about a local fragment of code, because you know what the code (and its callers, and callees) can and cannot do with the data being passed around. It's functional in the mathematical sense -- i.e., the output is a pure function of the input, no matter how convoluted the definition -- and knowing this helps us to reason more clearly, mainly because we don't have to worry about unseen effects at a distance. So, functional programming is a feeling of confidence achieved by making data transformations as local and as pure as possible.
The definition of FP is fuzzy and it feels like a "feeling." However, as humans we can formally define the word with an exact definition that fits the "feeling." We've already done it with mathematics and it improved our understanding by a huge margin.
What I see in practice is that we have various tribes, using various FP languages, who each define FP in terms of the languages they use (e.g., an FP lang must have certain type-system features, or be non-strict, or etc.). To put it crudely, FP is the thing that we do in our language, and which we perceive others as not doing. I've used the term "tribe" intentionally, as I do think that tribal thinking has had a role to play in the muddying of the term.
Given this, I think it's reasonable to demote FP to the level of "feeling", at least in general conversation. Discussions within a certain language community, or in the context of a book or article, are a different matter of course since a formal, contextual definition can be given there.
This was largely what people thought of mathematics before euclid formalized geometry. An exact definition exists for FP as it did for geometry and like geometry we will instantly recognize the definition of FP when someone finally decides to translate our intuition into formalization.
That doesn't strike me as a very good definition. It's possible for an imperative language to be explicit about its data-flows.
The SPARK language does this. It's certainly not a functional language.
https://docs.adacore.com/spark2014-docs/html/ug/en/source/ho...
It's interesting that, while Ada is imperative, SPARK contract annotations aren't. I won't take up the challenge, but I think someone could argue that SPARK-minus-Ada may indeed be functional (although SPARK-minus-Ada is no longer a programming language).
I don't agree that functional programming is uniquely difficult to define. Again, I agree with Wikipedia, which offers a definition that seems fine: [Functional programming] treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. [1]
It's true that we can disagree on whether immutability, or function composition, should be considered the true crux of functional programming. This isn't unique to FP though. In the object-oriented world, some consider inheritance to be the heart of OOP, and some consider dynamic-dispatch to be what really counts. [3]
> SPARK-minus-Ada is no longer a programming language
I think I agree, but I think we're in a minority (we seem to disagree with Wikipedia here). If you're working at a level of abstraction so high that you no longer think about algorithms, you aren't really 'programming'.
'Constraint programming'... isn't. The 'programmer' isn't really programming, they're writing a formal problem-description.
Formal specification languages like B-Method [4] aren't considered programming languages, for the same reason.
[0] https://en.wikipedia.org/wiki/Constraint_programming
[1] https://en.wikipedia.org/wiki/Functional_programming
b = (F.G.H)(y)
(note F.G.H is a composition of 3 functions
into 1, it can be thought of as a single function that is
called with parameter y)
b = y |> F |> G |> H
The isomorphism between applicative and point free styles are so close that it basically doesn't matter which style to use. You can easily convert from one style to the other. I advocate the point free style more for educational purposes. To help you see that the composition of functions is fundamental to FP.