Functional programming design patterns by Scott Wlaschin
Why Stack Overflow recommends it
Stack Overflow users link it when answering questions about enterprise patterns in FP, avoiding exceptions in favor of types like a non-zero integer, and structuring functional code.
Recommended by 2 people across 2 different months, 2016 to 2020.
What it is
Scott Wlaschin's conference talk surveying design patterns and principles from the functional programming world, as a counterpart to OO patterns like Strategy and Decorator and principles like SOLID. It mixes an overview with demonstrations of FP design in practice, using F# examples. This copy is a mirror uploaded to Ivan Plyusin's channel.
What people said
Recommends Scott Nimrod · 2016-04 · Stack Overflow · on “What's an alternative to throwing an exception when managing pattern matching with guards?”
He discusses it in this video: [this video] In the video, he advises not to throw an exception when dividing by zero. Instead, he advises to create a type called Nonzero.
Recommends Wesley Wiser · 2017-03 · Stack Overflow · on “Enterprise patterns with functional programming”
@nanounanue Looks like it was "Functional programming design patterns -- Scott Wlaschin" Mirror here [this video]
Cites hdkrus · 2017-08 · Stack Overflow · on “Defining a non zero integer type in F#”
How I can define a non zero integer in F# that rise a compile time error when assigning zero value? My question comes by watching this Scott Wlaschin video [this video] in minute 16:00 I have found another answers to this question in SO but all refers to a dynamic checking(throwing exception at creation time) but this approach is not a big deal and can be done in any OO and not OO languages. What I'm looking is something like: type NonZeroInteger = int except 0 or something like that.
Cites Brendan · 2020-01 · Stack Overflow · on “How to decrease arguments in elm?”
There are several strategies for this: Use types to abstract away data complexity. Model your problem using types, and then create simple functions to operate on those types. Define constants and helper functions at higher levels so that they are in scope for functions, rather than passing them in as a parameter. Narrow down function parameters to only what is strictly needed for that function. In the header example, you might provide your own types for the style, title and subtitle: type alias Title = String type alias SubTitle = String header : HeaderStyle -> Title -> SubTitle -> Element Msg When you do have lots of information to pass around, records are usually the first go-to for holdin