I'd love to see those "patterns" written down, too! For now, other than Richard Feldman's talk "Making Impossible States Impossible", I have only found two F# resources:
* The "Designing with types" series on F# for fun and profit https://fsharpforfunandprofit.com/series/designing-with-types.html * Types + Properties = Software by Mark Seemann http://blog.ploeh.dk/2016/02/10/types-properties-software/ I really liked Mark's series, because it shows a specific example that is solved in an elegant way – something that I wish to be able to do on my own. Basically I followed his steps, but instead of implementing the kata in F#, I did it in Elm – it was a very fun experience! I posted a short summary of it on my blog – http://mirrors.link/posts/the-polyglot-approach-to-modeling-state-and-property-tests-in-elm 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.
