Oh, I'd forget that there's this post "Writing Friendly Elm Code" written
by Tessa
Kelly. http://tech.noredink.com/post/146963432518/writing-friendly-elm-code
It also discusses how to model data in the app.
On Sunday, December 11, 2016 at 8:01:09 PM UTC+1, Brian Marick wrote:
>
> I’m repeatedly finding myself running into decisions about sum and product
> types where I’m choosing among alternatives like these:
>
> > type FormValue valueType explanationType
> > = Valid valueType
> > | Invalid valueType explanationType
> > | Unchecked valueType
> >
> > -- vs
> >
> > type ValidationStatus explanationType
> > = Valid
> > | Invalid explanationType
> > | Unchecked
> >
> > type alias FormValue2 valueType explanationType =
> > { value : valueType
> > , status : ValidationStatus
> > }
> >
> > -- vs
> >
> > -- Something better that makes invalid states
> > -- impossible.
>
> Too often, I realize the drawbacks of a decision way later than I’d like.
>
> Because I was hanging around with OO people in the early 80s, I recognize
> this kind of floundering. Idioms and patterns that we find obvious today
> were the subject of much discussion, experimentation, and - finally -
> widespread diffusion. (Though design patterns sort of took a wrong turn,
> and are now out of favor, their original goal of documenting and explaining
> the “why” behind certain common solutions was really powerful.)
>
> Since FP has been around for a long time, too, I’m hoping that those
> idioms and patterns have been written down, with a good effort toward
> explaining them (with examples!) Where?
>
> (What I’ve seen has been focused more on laws and provability, as opposed
> to the OO emphasis on Simon’s “satisficing” [*]. Plus, the rather banal
> observation that many OO patterns are unneeded or built in to FP languages
> led to some strong claims (around 2000, especially) that FP systems don’t
> have any design patterns - and I’m afraid the hangover from that has kept
> people from writing the sort of example-based guidelines I’m looking for.
> Hope I’m wrong.)
>
>
> [*] Satisficing is the process of looking for good-enough solutions rather
> than continuing on in hopes of finding an optimal one.
> https://en.wikipedia.org/wiki/Satisficing
>
>
>
--
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.
