Oh yes, that's a great example! Yeah, we tend to create a type that's very similar to the structure of the JSON we receive through flags or http responses. Then write a transformation functions from those Flags or Backend types to a Model. And when encoding some data to JSON, for example as the body of a request, the same trick can be used there too!
Nice technique. This smells like another one of those things that people (unfairly) criticize Elm (and other FP languages) for because the effective techniques for handling common patterns are very different from those found in languages of the other paradigms. Novices are not likely to discover the technique in their own code writing and therefore their frustrations dealing with a lesser-effective technique are likely to be targeted toward Elm itself; fair or otherwise. I still find it difficult to communicate these subtleties with beginners and wonder how Elm will face these challenges. Maybe I heard it somewhere else, maybe not, but I carry a motto for Elm in my mind that says "it's broken until it's easy for everyone", and maybe another one that says "if it makes things harder, we're not adding it." I'm excited to see how Elm and the community will make better and better abstractions that enable even higher level programming with even less complexity. Thanks for sharing your post.
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.
Oh yes, that's a great example! Yeah, we tend to create a type that's very similar to the structure of the JSON we receive through flags or http responses. Then write a transformation functions from those
FlagsorBackendtypes to aModel. And when encoding some data to JSON, for example as the body of a request, the same trick can be used there too!Nice technique. This smells like another one of those things that people (unfairly) criticize Elm (and other FP languages) for because the effective techniques for handling common patterns are very different from those found in languages of the other paradigms. Novices are not likely to discover the technique in their own code writing and therefore their frustrations dealing with a lesser-effective technique are likely to be targeted toward Elm itself; fair or otherwise. I still find it difficult to communicate these subtleties with beginners and wonder how Elm will face these challenges. Maybe I heard it somewhere else, maybe not, but I carry a motto for Elm in my mind that says "it's broken until it's easy for everyone", and maybe another one that says "if it makes things harder, we're not adding it." I'm excited to see how Elm and the community will make better and better abstractions that enable even higher level programming with even less complexity. Thanks for sharing your post.