Coming from Haskell, some things that haven't been mentioned yet: (1) Learning to embrace pattern matching, especially in situations where you don't have to in Haskell, like getting the first item of a list. (In Haskell, `head` returns `a` instead of `Maybe a`, so you can just check whether the list is empty, and if it isn't, use `head`.) (2) Learning what to use instead of guards and `where` clauses. (3) Learning how to live without (type)classes. Aka, learning how to hide direct imports (`map`), and instead use qualified imports (`List.map`, `Dict.map`, `String.map`, etc) to tell them apart. (4) Learning the command/subscription idiom (and before that, signals).
I note that after learning to do things the Elm way, it becomes clear that Elm is indeed doing things "the right way". I really appreciate that Elm is willing to break with earlier programming traditions in order do things the right way. (I do miss (type)classes just a little bit though.) >I'd say learning how to make illegal states unrepresentable. Indeed. Compare making a simple binary tree in Elm/Haskell to making one in the imperative-OO language of your choice. Learning to use `Maybe` correctly (and thus realizing how imp-OO languages do `null` all wrong) is a subset of this. On Thursday, August 11, 2016 at 4:07:33 AM UTC-5, Peter Damoc wrote: > > "The fundamental fact about learning: Anything is easy if you can > assimilate it to your collection of models. If you can't, anything can be > painfully difficult.” - Seymour Papert > > I'm trying to come up with a sorted list of concepts and models that a > prospective Elm user needs to learn in order become proficient in Elm. > > Here is my list (I actively tried to keep it short) : > > - types : the concept that information flowing through an Elm program has > a specific type and that the compiler will not accept the wrong type. > > - type composition: the concept that types can be composed into more > advanced types using union type syntax and record syntax. > > - type variables : the concept that you can have a type constructor that > can take arguments and produce a custom type (List, Maybe, etc) > > - functions as types: the concept that you can give functions to other > functions in order to customize their application. > > - currying/closures: the concept that you can take a multi argument > function and produce another function that has some of those arguments > applied. > > - declarative: the concept that the Elm programs are made of one big > function that returns a specific type instead of a series of instructions. > > How does your list looks like? Which one gave you most troubles? Which one > did you find most amazing | useful | mind-blowing ? > > > > > > -- > There is NO FATE, we are the creators. > blog: http://damoc.ro/ > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
