Your point about moving from a beginner FP programmer to now seeing the use of point free in using Higher Order Functions such as fold and map is a normal progression with experience we have all gone through, and as you progress further, you may see more ways to use it and still have easy-to-understand code. The fact that using currying/point free is optional means that one can choose to write in the verbose way without it or more concisely with it as seem best…
In fact, point free notation in definition of functions does depend on currying, which is one of the reasons that Roc supports neither currying nor (as a result) point free notation. When functions have only one argument, the difference between point free notation and just piping is just the difference between leaving out the single argument, as in the following:
myIntSqrt : Int -> Int
let myIntSqrt int = truncate <| sqrt <| toFloat int -- or let myIntSqrt = \ int -> truncate <| sqrt <| toFloat int
let myIntSqrtPF = truncate << sqrt << toFloat
or the other way around using forward piping or composition. This is indeed handy when forming inline functions for Higher Order Functions such as fold/map/filter, but so is the full points free version when more than one argument are used, for instance for filtering all of the integer square roots greater than two as follows:
myFilter : List Int -> List Int
let myFilter lstint = List.filter ((<) 2 << truncate << sqrt << toFloat) lstint -- or
myFilterPF = List.filter <| (<) 2 << truncate << sqrt << toFloat
@benjamin-thomas has explained very well why one would like to use currying and point free notation even though they are just “nice to have” features as there are other ways to make functional programs work without them (as chosen by Roc): currying, partial application, and point free notation lead to more concise code as he says; one can program perfectly well without using Type Classes (Haskell)/Abilities (Roc)/Capabilities as shown in using F#/Fable, and yet these are the most requested features because it makes code more concise. In the Elm spirit of doing things, making code more concise is not a bad thing, although using too many obscure operator symbols to make concise code is made impossible. In other words, Elm is all about a balance between writing concise code and obscure code, and currying/partial application/point free notation are considered acceptible if used reasonably…
However, this is an aside in the discussion of an ElmPlus language that is fully back compatible with current Elm code in that since Elm supports currying, ElmPlus must too…