Not sure how you reached that number. The Elm code, with blank lines removed, is less than 320 lines. Given the incredibly spacious style its written in, I'd definitely say 300 rather than 400.
But sure, that's still a lot. Part of it is that Elm lacks the proper generics support (which you can observe in the function names) and part is that the archotecture chosen by the creator may not be optimal in terms of maintainability. For example,
type Cell = NotOwned CellLocation | OwnedBy CellLocation Player
and I think, why not
type Cell = Cell Location (Maybe Player)
? Its isomorphic (carries the same information) and it removes the need for the complicated getters.
Elm is pretty kludgy - its nice for learning FP for beginners, but because they're really committed to staying in that niche (which I think is great tbh, the more people write functional code the better!) the language lacks a lot of nice features that enable better code reuse and conciseness.
Elm doesn't even advertise itself as FP. In fact, the Elm style, although still FP, goes against a lot of FP ideals and canonical practices[1].
Instead, I think it would be more correct to say that Elm aims to be its own thing, totally independent from the Javascript and FP community, at the same time welcoming people from both (as it has been doing for quite a long time now).
Elm is definitely FP and advertises itself as such.
The first sentence of the Elm guide is "Elm is a functional language that compiles to JavaScript" (https://guide.elm-lang.org/).
I'm not sure what your link has to do with FP in the large. It's a Haskell library that aims to de-emphasize point-free programming and emphasize reverse function application over normal function composition. Neither of these choices are defining features of FP (e.g. Scala can't really express point-free programming and method calls are essentially reverse function application, OCaml doesn't have a built-in function composition operator and as a result the community very rarely uses point-free, Haskell generally uses normal function composition, F# generally uses reverse function application, etc.).
FWIW, Elm's standard library has all the operators defined in that library (pipe i.e. reverse function application, reverse function composition) as well as their ordinary Haskell equivalents (forward function application and forward function composition).
Why are you referencing a blog post about importing F# style into Haskell for a statement about “FP ideals and canonical practices”? Do you think FP is defined by F# instead of F# being I've of many FP languages, none of which individually defines canonical FP practices?
