The most important one I keep coming back to is the design principle of
rigorously separating functions and data - don't keep functions in your
model, etc.
In many ways I jumped on Elm just because it felt so immediately *right*
and natural, as opposed to "I heard Elm was great but now I have to adjust
to a whole new way of thinking", so there wasn't a lot of mental
gymnastics. But coming from C++ (and more recently Scala) I still started
out doing things like creating 'interface types' that were records with a
couple of function fields and passing those around as arguments to other
functions.
I guess the other one would be getting used to function signatures and
currying. Simple examples like plus : Int -> Int -> Int are relatively easy
to explain as "it can take two Ints and return an Int, or take one Int and
return a new Int -> Int function" but I still find some cases a bit
mind-bending especially when type aliases get involved - here's some helper
code I recently wrote:
type alias Comparator a =
a -> a -> Bool
both : Comparator a -> Comparator a -> Comparator a
both firstComparator secondComparator first second =
firstComparator first second && secondComparator first second
So the both function is declared as taking two comparator functions and
returning another comparator function, but thinking of it in those terms
the implementation actually takes the first two functions *and the two
arguments of the resulting function*, and returns the final result. It all
makes sense if you mentally 'flatten' the type signature and think about
partial application a bit, but at first glance it seems odd.
On Thursday, 11 August 2016 19:07:33 UTC+10, 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.
