Monoids, Monads, and Applicative Functors: Repeated Software Patterns - David Sankel - CppCon 2020

---
Forget factories, singletons, and proxies; What are the real patterns in software development? This talk explores abstract mathematical structures that commonly recur in software development. Once a mind is trained to recognize these patterns, it becomes easy to identify the fundamental operations for domain specific classes and how to put the pieces together. This discussion is for those who enjoy math, abstract concepts, and expanding their minds.

---
David Sankel is a Software Engineering Manager/TL at Bloomberg and an active member of the C++ Standardization Committee. His experience spans microservice architectures, CAD/CAM, computer graphics, visual programming languages, web applications, computer vision, and cryptography. He is a frequent speaker at C++ conferences and specializes in large-scale software engineering and advanced C++ topics. David’s interests include dependently typed languages, semantic domains, EDSLs, and functional reactive programming. He is the project editor of the C++ Reflection TS, a member of the Boost steering committee, and an author of serveral C++ proposals including pattern matching and language variants.

---

*-----*
*-----*

[AllForMarketing]

This guy presents on whole new level <3

[gieseanw]

Really clever way to handle a remote presentation

[NonTwinBrothers]

With this presentation style you'll go far

[youknowwho]

Excellent. Sound, presentation, delivery. Very impressive and even entertaining... talking about monads... would never expected. Thank you.

[DiegoPerini]

Thank you so much David, CppCon and the crew.

[ilikedirt]

This was so awesome I want all category theory to be introduced like this.

[piliparbotond]

Those kids are serious about their computer science knowledge! :)

[ericzenk]

This video is great. It has category theory and kids answering questions about category theory.

[Krzysztow]

Haha, awesome use of your family! Wonder if they'd be able to sat there through the whole talk. The talk is good too :)

[Yupppi]

Gotta say, Sankel feels so much more restricted when he's not able to walk around the stage while presenting. He's really good at that pacing combined to the presentation based on having seen his other talks. I really enjoy his talks in general, he always has something important and useful to say. This was a weird and different way to visualize the talk but it was funny and effective. But I feel a bit discouraged how Sankel's small kids are much smarter on this than I.

Recently I've been trying to expand my views by getting into functional programming and this just hits the spot perfectly.

In my opinion monoids and functors and monads don't seem like complicated concepts per se, but there's all this vocabulary abstraction and mathematical "jargon" describing accurately what they do that it becomes just repeating unfamiliar words many times in a sentence, which completely obscures the ability to interpret the concept. Like when showing an example piece of code (preferrably without templating and being general because that messes people up even more) it looks like a familiar action that only had an unfamiliar name and list of rules/specifications you never thought about. Like I swear almost all of us have written a monoid, used a functor, perhaps monadic too. I swear nobody has ever read a formal mathematical description and applied it like that. You write the mathematical description after you've figured out a pattern of sorts and then everybody reads it and you show what you mean and then they start to understand and apply.

[GrzegorzMilka]

I'm glad to see ideas from cat. theory getting more widespread :) A well prepared presentation, thank you!

[deathvally]

Came back at it after a year with some haskell attempts. With haskell syntax, I was sliding off of monad with some level of understanding of map and applicative functor. To me, monoid and applicative functor in C++ looked reasonably good . Though verbose in C++ but still grasping the concepts seemed easier . Here I'm only taking in the concepts whereas in the case of haskell the problem is both the syntax and concepts are new . So definately it was helpful for me.

[paxdriver]

This is so amazing lol the peanut gallery is adorable!

[MrGyulaBacsi]

The getStrings(.) example at 20:05 did not work for me this way. I had to replace the 'auto' keywords to exact type declarations then it worked. Like for f1. Is there a way to still use those 'auto' keywords anyway? It'd be nicer and more compact and flexible.

[skyeplus]

The parser from example is effectful. It should take string as an input, or better - const char*.

[colin]

At 19:20 when you talk about how std::function is a functor, i'm confused about the type of the first parameter. Shouldnt the type of the first parameter be a std::function with one parameter (a std::function) that returns another std::function, rather than just a std::function that accepts the return type of the second parameter?

[vicissitude]

I wonder if FP is promoted by those who are predominantly programmers by occupation or whether it's mathematicians being bored. Using Haskell is torturous and it seems like I'm fighting the language more often than addressing the programming issue at hand. Moreover, something like std::vector<std::optional<T>> entertained in this talk is cache-unfriendly because Ts will be interspersed by the flags that indicate whether the std::optional contains a value. I fear that following FP principles incurs runtime costs, where instances are coupled with extraneous state for tab-keeping (more specifically, it's encouraged to keep tab-keeping local to each individual instance), which calls for extraneous state checks and branching.

[francisgrizzlysmit]

this is like abstract algebra's I used to study these in pure mathematics fun

[mmdk]

32:42 so how does one pass the list of digits to convert them into a number when the characters are not even stored anywhere?

[arnebovarne]

It's a mix of too simple and too complicated. Too easy and it's obvious. Too complicated and it feels messy and unclear.