DEV Community

Discussion on: Elm 0.19 Broke Us đŸ’”

Collapse
 
erebos-manannan profile image
Erebos ManannĂ¡n

Minor but indicative: Evan has posted many times telling users to change the way they talk or think about Elm. (Fair point: he's nice about it and there are valid points. But still... indicative.) Examples: Don't use the word Components. Don't say "native"; say "kernel" instead. Union types should now be called Custom Types.

I think this is the only thing about what you say that I disagree with a bit - terminology is important, and it's important to try to keep reminding people to use the same terminology not to confuse people who don't have a solid grasp of what you're talking about.

This issue is even more important when you're dealing with non-technical people, but it's very important with beginners to any technology too. If you have 5 ways to say the same thing, people are going to get super confused.

Collapse
 
wires profile image
Jelle Herold

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.

Collapse
 
erebos-manannan profile image
Erebos ManannĂ¡n

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.

Thread Thread
 
wires profile image
Jelle Herold

Right, thanks, so that is failed reasoning.

  1. The people fluent in FP will waste a lot of time figuring out the mapping of terms
  2. 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...