More coherent post here... first, don't freak out, this is from April. I think I've seen it before.
One argument that's at least worth debating is: There is no map function, but there are List.map, Dict.map, Array.map among > others, and none of them are related to one another. This is not only > annoying, but also breaks the abstract data-type guarantee: our call-sites > are now tightly coupled to our implementation details. If I decide to > change from a List a to an Array a for efficiency reasons, my whole > codebase needs to know about it. I think this is wanting to have it both ways: I want the compiler to know what data type this is, but I don't want my codebase to know. And his justification for this is "the abstract data-type guarantee", as if that's handed down in a sophomore CS course. And it's true, Python has a map function and Ruby enumerables have a map method. But that contributes to the, well, abstractness of the code. Elm's module naming schemes mean you get noun and verb together, rather than "map over this mappable thing". It's much like a lot of haskell code: "yes I know it's a monad but I have no idea if you're doing IO, inserting into a singleton list, or creating a constant random number generator -- and I need to know that to figure out if this code does what I want it to do!" But in Elm, if you want to change from List to Array, change the type defintion or annotation and the compiler will tell you where everything else needs to change. Sure, it's tedious, but I'd rather have a boring and straightforward path forward then none at all. Finally, the fact that we're pissing off Haskellers is good. We're not making the language for them. We're making it for JS developers and those new to programming. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
