Ironically, a lot of time is wasted trying to figure out what "name" elm uses for existing FP concepts, so many thing have names entirely different to more standard OCaml, Haskell, etc. names.
I believe the reasoning for this was that the FP people will understand the concept anyway, and the beginners to FP will understand the non-FP terminology better.
The people fluent in FP will waste a lot of time figuring out the mapping of terms
The people not yet fluent in FP will waste time later (when moving to a usable language such as Purescript), figuring out the "proper" name for the stuff they learned.
Also, it's not that Haskell "invented" the names, most come from research papers in FP and are established concepts there.
Imagine writing a new "better" textbook on biology and renaming all the terms. Doesn't make sense...
Also, come to think of it: The whole point of a symbol like <$> would be to not really indicate any "intuitive" understanding of what it does; just remember the type and learn to apply it. The understanding should remain abstract...
This is pretty much in line of the "No Abstraction" attitude of Elm; makes sense, but wrong...
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Ironically, a lot of time is wasted trying to figure out what "name" elm uses for existing FP concepts, so many thing have names entirely different to more standard OCaml, Haskell, etc. names.
I believe the reasoning for this was that the FP people will understand the concept anyway, and the beginners to FP will understand the non-FP terminology better.
Right, thanks, so that is failed reasoning.
Also, it's not that Haskell "invented" the names, most come from research papers in FP and are established concepts there.
Imagine writing a new "better" textbook on biology and renaming all the terms. Doesn't make sense...
Also, come to think of it: The whole point of a symbol like
<$>would be to not really indicate any "intuitive" understanding of what it does; just remember the type and learn to apply it. The understanding should remain abstract...This is pretty much in line of the "No Abstraction" attitude of Elm; makes sense, but wrong...