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
type Cell = Cell Location (Maybe Player)
flipPlayer : Player -> Player
flipPlayer currentPlayer =
case currentPlayer of
X ->
O
O ->
X
flipPlayer : Player -> Player
flipPlayer X = O
flipPlayer O = X
Naming multiple top-level values `flipPlayer` makes things ambiguous. When you
say `flipPlayer` which one do you want?
128| flipPlayer O =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).
[1]: http://taylor.fausak.me/2015/04/09/write-more-understandable...
Finally, I think there are a few red flags in your code. For example you have a hardcoded list of cell locations but you use a method to compute the number of rows which has a sqrt in it... might as well hardcode the number of rows :)