Functional Design Patterns - Scott Wlaschin 

THE BEST talk that gracefully and beautifully introduces and explains monads. This should be how textbooks teach monads to programmers.

03:19 FP Design Patterns 06:13 Core FP Principles 06:50 Functions are things 11:45 Types are sets 20:50 Functions as Parameters 29:30 *Every function is one parameter 16:58 Exceptions in Functional Land 40:47 Chaining functions instead of if-else 43:07 Monad 44:06 Bind mis-match functions 49:40 Map (*Mappable types r functors) 53:06 Monoids (Things with 3 rules)

This is really excellent. As an out of practice math nerd who has made a living slinging code for decades this was a breath of fresh air. Despite the disclaimers of don't expect to understand everything on first listen it all made perfect sense. A fine job of teaching this stuff piece by piece.

one of the best programming talks i've seen

A brilliant talk. It is plainspoken, direct, but conveys the real essence of the topic at hand. The slides are clear and fresh. Scott is a remarkable educator.

1:04:55 - "A monad is just a monoid in the category of endofunctors"

Scott is a brilliant teacher. It’s common for FP to be explained in a confusing way, but this talk is succinct and clearly explains the value of using a FP approach!

I still love coming back to this talk, as it's one of the bests in succinctly explaining many very fundamental advantages of functional programming languages and the functional mindset itself

If more experts explained FP or any topic like this, we would all be programmers.

The best functional programming introduction. Period!

This champion just casually drops the most intuitive explanation of the monad joke on the internet.

Beauty of functional programming in plain english. This talk give me the light in my head of what really is the benefit of FP!

Excellent ! Best monad step by step explanation !

A great speech that is still worth revisiting even after a long time.

Best talk about functional programming ever. Thank you

This is one of the many videos I found helpful and insightful which enlightens me on the way to FP. Thank you!!!

Clear and understandable. You did an amazing job!

Outstanding clarity! Thank you!

Four years later and this is still awesome

Amazing objective unbiased talk! I am coming from an OOP perspective and I knew some of the FP principles already (and some of it is already influencing how I do certain things in OOP in certain contexts. Even though we only wizzed past some of the principles I think I never saw it clearer :)

Extremely digestible, thank you Scott

모나드를 간단하고 덤덤하게 설명 잘해 주시네요 . 감사합니다

It's beautiful! I've looked at this for five hours now...

Good talk and very good presentation. thank your for sharing your thoughts :)

"It's really simple and I will show you. Now this is getting complicated." XD

A monad is a monoid in the category of endofunctors.

"An OR object is not easy to make in object oriented" I knew my ventures into C++ would be useful.

This is a gem.

Brilliant!

Great talk on Functional programming!

Great talk 👍👍 Gained a lot of in-depth insights only in an hour

amazing. best FP video I've ever seen

this is simply awesome, thanks for the talk

Great slides! Great graphics! Wonderfully subtle humour!

FP Design Patterns [3:10] OO pattern/principle [3:20] FP equivalent: Functions FP patterns are different Outline [4:16] (Some) Core Principles of Functional Programming [6:12] Core Principle: Functions are things [6:50] Core Principle: Composition everywhere [9:23] Designing with composition: Functions all the way down [10:22] Core Principle: Types are not classes [11:45] Types can be composed too [12:54] "AND" / "OR" "AND" types [13:46] Example: paris, tuples, records "OR" types [14:22] Real world example of type composition [15:05] Design principle: Strive for totality [16:57] Design principle: Use static types for domain modeling and documentation [20:13] Functions ad Parameters [20:50] Parameterize all the things [20:54] Tip: Function types are "interfaces" [25:10] Example: Strategy pattern [26:40] Example: Decorator pattern [27:30] 1 parameter function [29:15] Pattern: Partial application [32:08] Pattern: Use partial application to do dependency injection [34:37] Pattern: Chaining callbacks with continuations [40:53] Monads [43:07] how to combining switches "Bind" is the answer! Bind all the thing! [44:30] Pattern: Use bind to chain tasks [46:30] a.k.a "promise" "future" Pattern: Use bind to chain error handlers [47:19] Maps [49:40] Guideline: Most wrapped generic types have a "map". Use It! [52:38] Guideline: If you create your own generic type, create a "map" for it. Terminology: Mappable types are "functors" Monoids[53:05] Pattern: Convert non-monoids to monoids [1:00:17] Pattern: Seeing monoids everywhere [1:02:22] Metrics guideline: Use counters rather than rates / make sure your metrics are monoids Monads vs. monoids [1:03:54] "monad laws" are just the monoid definitions

Incredible talk

Excellent - once I got past the dinosaurs it really gave me a really excellent insight into this paradigm. I did computer science in 1982 and I really struggled with OOP and actually gave up eventually - focused instead on Machine programming and PLC's - just too different from the way I think. This on the other hand is exactly how I think. Its like Asperger programming! And I am one of those!

That was mind blowing!

Great speaker.

Scott is the best teacher

This man is mad genius, my brain is just exploded, a couple of shopping-list-like lines of code can be compiled into the exact same thing. As if I am talking to the machine and it is talking back.

The one parameter function concept is a game changer

How to do this in typescript? Recommendations?

I love that quote "A monad is a monoid in the category of endofunctors", because it's a great example of jargon, but also, it just boils down to (in the context of functional programming) `M` is a monad when you can write `pure : a -> M a` and `join : M (M a) -> M a` for it, so it's not really difficult to understand, you just have to hand-wave through a couple of Wikipedia pages :p

The best!

I didn't understand functional programming before, but now I do.

the doX functions in 43:01 have a type signature of: Option.Val -> Option

killed it! awesome!

Great video

anti-tip: you can also 'superficially slim down' the pipe by chaining function calls within the function body

Very well explained!

So if golang had monads, would they be gonads? I'll get my coat.

I need to share this with the team.

FP diehards be like, "its so simple let me show you. This is gonna get complicated so excuse me if it's confusing"

I am getting ready to start watching the video so peeped the comments. Sounds like this talk is going to change my life. Hitting play now!!

Excellent !!

you can have a very limited set of functions but yet achieve an entire set of elements even from input to output (input == output) by looking at these elements as a set that can make up a group given the right function a.k.a operation.

oh okay, a monoid is anything i can do a "reduce" on

Where in the ivory tower do the JavaScript developers live? ☺

This one railway two tracks illustration says more than a whole medium article

a functor is any type that provides a 'map' function! Options provide a 'map' function

29:02 Didn't get how the same log function was taking an int (first) and a bool (second).

Audience is too quite, I believe that's why Scott referencing another video on his site ;)

15:00 So unions from C, then?

Is this about interior design

I need to heckle the TwelveDividedBy function bit to say that most integers given won't return an integer.

Oof, I am fond of OCaml and F#, but the choice to write the type of `Some 5` as `int option` is really rather unfortunate. Haskell's `Maybe Int` seems much more consistent/readable.

Most tangible metaphor for bind I have ever seen.

🎯 Key Takeaways for quick navigation: 00:24 🎙️ Functional design patterns and principles are demonstrated using F# but are applicable to various programming languages. 01:36 🤖 Scott Wlaschin, the presenter, introduces himself as an object-oriented programmer turned functional programmer with a background in Smalltalk and other languages. 03:15 🛠️ The talk will cover core principles of functional programming, including functions as parameters, composition, and the role of types. 06:31 🧩 Core principles of functional programming include treating functions as standalone entities, using composition extensively, and distinguishing types from classes. 08:48 🔄 Functions can be used as inputs and outputs, leading to powerful and flexible composability in functional programming. 11:55 🧑‍🔬 Types in functional programming act as sets of data, allowing for flexible composition using "and" and "or" operations. 16:51 🏗️ Functional programming excels in domain modeling, where types can be composed using "and" and "or" to create powerful and expressive structures. 17:07 🚧 Designing for totality involves ensuring functions are total (never throw errors) by either constraining inputs or using types like "Maybe" to handle potentially undefined outputs. 20:09 📚 Using static types for domain modeling provides clear documentation, compile-time checks, and helps design total functions. 21:58 🔄 Parameterizing functions, including the looping action and list type, enhances flexibility and decouples behavior, a key principle in functional programming. 22:13 🔄 Generic List Iteration in F#: F# makes list iteration easy, allowing for generic list iteration with parameters like action and initial value. 23:11 🔄 Common Code Extraction in F#: In F#, the fold function helps eliminate duplicate code by extracting common elements, parameterizing the initial value and action, emphasizing the importance of functional collection functions. 25:34 📦 Functions as Interfaces in F#: In functional programming, functions serve as interfaces, aligning with principles like the Single Responsibility Principle and Interface Segregation Principle. Functions compatible with an interface don't require inheritance. 26:42 🔄 Functional Approach to Strategy Pattern: In functional languages, the Strategy pattern is implemented by passing the strategy (function) as a parameter, avoiding the need for class interfaces. 27:52 🔄 Decorator Pattern in Functional Style: Rather than classic decoration with wrappers, functional languages use composition, combining functions to create new ones. The example showcases logging without explicit wrappers. 29:24 🔄 Single Input, Single Output Principle: While multi-parameter functions exist, every function in functional programming can be conceptualized as a series of one-parameter functions, offering simplicity and consistency. 32:11 🔄 Partial Application and Flexibility: Partial application allows flexibility by transforming a multi-parameter function into a series of one-parameter functions, demonstrating its usefulness in various scenarios. 34:52 🧩 Dependency Injection with Partial Application: Dependency injection in functional programming can be achieved using partial application, providing flexibility without relying on specialized frameworks. 38:27 🔄 Parameterizing Behavior: By parameterizing behavior, functions gain flexibility, enabling the caller to decide the next steps, illustrating the power of parameterization in controlling program flow. 41:13 🔄 Monad Simplified: The concept of a monad, often viewed as complex, can be simplified as chaining continuations together. The example demonstrates this with a helper function for handling optional values. 43:20 🚂 Gluing functions together involves using a branching railway analogy, where functions can either return something or nothing. 44:29 🔄 Switch functions with one input and two outputs pose a challenge in composition. The solution is to use "bind," a functional programming concept that transforms one kind of function into another. 45:52 🔄 Bind is the core of a monad, simplifying the gluing of functions and transforming one function type into another. 46:20 🌐 Using the example of handling errors in a web service, the talk introduces the concept of monads to simplify code, making it look similar before and after error handling. 48:59 🔄 The talk discusses how the mapping pattern, using functions like "map" on different types, is a common and powerful approach in functional programming. 52:58 🔤 Functors, or mapable types, are discussed, emphasizing the importance of the "map" function in functional programming. 56:41 ➕ The talk delves into the concept of monoids, which are sets equipped with a binary operation, associativity, and an identity element, providing a generalized structure for combining elements. 01:02:52 🔄 Functions and function composition are explored as monoids, where combining functions of the same input-output type produces another function of the same kind. 01:04:12 ⚖️ Monads are discussed as monoids in the category of endofunctors, connecting the concepts of monoids and monads in functional programming. Made with HARPA AI

Aren't "Or" types just enums? Why is it so difficult to have those in c#?

Arguably, the distinction between types and classes is purely aesthetic. After all, the word class in its conventional sense (from which the OOP sense is derived) refers to "a set of things" which is the same as your definition for a type. Likewise, you say that types have no behaviours, but you could think of any function that takes an input of that type as being a behaviour of that type. But, perhaps that's okay. Aesthetic differences can be worth making sometimes.

For me, the phrase "function composition is a monoid" makes no sense to me.... What would make sense would be something like "the set of all endomorphisms under function composition form a monoid" or "the functions from a set into the same set form a monoid with respect to function composition". Is this what the author meant? If so.. I would argue then that his wording is incorrect. If this is not what he meant, can someone shed some light? Thanks

Where is the FIzzBuzz example again?

9:05 - This guy nodes

amazin

Watching this as a C, JavaScript, and PHP holdout... Thinking WTH is an option?

I accept a nonzero int that can divide 12 without using any storage and can always be done *before* anyone pulls the power cord - or else can keep working even without power and through the heat-death of the universe... ... ... uhh, I'll throw an exception

great talk, now i can understand the meme

bind == ifSomeDo

Does some guy next to camera start eating crisps around 45 mins in?

Category Theory is to Programming what music theory is to Music.

In some cases, I believe it will cause stack-overflow when it calls functions too deeply...

The infinite series mathmaticians want a word with you on that order of additions doesn't matter point.

Golang needs it's own "special" implementation of monads.... so, as well as 'goroutines', it could have...........

he broke the burrito curse

So TIL. Typescript is basically a functional language.

monadic bind = - takes in an Option & a Function - unboxes the Value out of the Option - passes the unboxed Value to the Function the functions passed to the monadic bind = - takes in a Value - returns an Option

Railways are a strange analogy to use here because you can't send railway track down a train tunnel unless it's smaller

this guy memes harder than most kids of my age

Not me getting jealous some people get all these dope tools from their language while I have to use python at work...

this should be taught in every computer science class so we dont end up with tragedies like stackoverflow and c++

So funny how he was afraid of using word "object“. Functions are things :D

This is a pretty nice talk but be warned that a lot of what it covers are things that aren't related to FP (e.g. discriminated unions). Many functional languages don't do static type-checking at all. If you're interested in the ML family of languages specifically, this covers a lot of their conventions. It mostly doesn't translate to e.g. the Lisp family though.

"50% of your code is error handling..." Hahahaha. HAHAHAHAHAA. I wish, but people are usually more optimistic than that....

It's truly unfortunate how OO has presumptuously taken itself to be the 'default' frame of reference ... It bewilders me, coming from a functional background, why anyone would want their functions 'trapped' in objects and classes ... or how anyone finds it acceptable to have idiosyncratic/non-compositional abstractions.

what the hell is an endofunctor?!

take a shot every time he says functions

As far as I can tell none of this is specific to FP.

01:17 test

so monoids are value objects?