Monads in Modern C++ - Georgi Koyrushki & Alistair Fisher - CppCon 2023

cppcon.org/
---
Monads in Modern C++ - Georgi Koyrushki & Alistair Fisher - CppCon 2023
github.com/CppCon/CppCon2023
Monads are a common technique in functional programming languages to reduce boilerplate and abstract detail in order to produce simple, pure pipelines. While traditionally associated with languages like Haskell, monads are making their way into more mainstream languages, including C++ - with monadic operations being added in C++23. Due to their increasing applicability in real-world situations as alternatives to more traditional paradigms, these functional techniques may become core pillars of C++ development.
To many developers, monads are either unknown or confusing - they have a reputation as being notoriously difficult to understand. This talk will combine both theory and coding examples inspired by our day-to-day work on a large-scale enterprise financial risk system. The aim is to demystify the monad and enable attendees to gain a practical insight into its internal workings.
While the focus of our talk will be on C++, the ideas are relevant to any other programming language - the shift towards these functional features is not unique to C++.
No functional programming knowledge required.
---
Georgi Koyrushki
Georgi Koyrushki is a Senior Software Engineer at Bloomberg, where he works in the Multi-Asset Risk System (MARS) Engineering team. He has worked at the company for nearly five years, prior to which he earned a bachelor's degree in software engineering from the University of Glasgow. Georgi's interests include (among others): C++, functional programming, design patterns, distributed systems, and more.
Alistair Fisher
Alistair Fisher is an Engineering Team Lead at Bloomberg. He works in the Multi-Asset Risk System (MARS) Pricing group in London, where he is focused on building scalable and reliable components for portfolio pricing and risk analysis. He is interested in the use of functional programming techniques for writing simpler and safer software. Prior to joining Bloomberg, he completed a master's degree at the University of Cambridge.
---
Videos Filmed & Edited by Bash Films: www.BashFilms.com
KZbin Channel Managed by Digital Medium Ltd: events.digital-medium.co.uk
---
Registration for CppCon: cppcon.org/registration/
#cppcon #cppprogramming #cpp #monad

[@woodandgears2865]

Great talk. Thanks. The first answer (or lack thereof) reflects a challenge I see with using monads. Often simple and reasonable questions are not quickly answerable by experts.

[@k17101989]

Transform followed by a join

[@insu_na]

Gotta love C++ developer humor. "Let's name a function that has nothing to do with connecting 2 things "join", lololol"

[@Roibarkan]

Well, in python str.join() in python is meant to take a range of str’s and concatenate them to a single str. I think std::ranges::views::join is quite similar - an ‘unwrap’ operation. I agree that the leap from here to unwrapping optional is quite a leap 😏

[@insu_na]

@@Roibarkan yeah, then they should've named it "unwrap" tho 🤣

[@atijohn8135]

in a sense you're joining the outer optional with the inner optional

[@pixlark4287]

to be fair, when it comes to monadic operations there isn't a very good way to intuitively name things because the operations are so generalizable. Plus, "join" in particular isn't a C++ invention, it's the traditional name for that operation in functional programming (see: Control.Monad.join in Haskell)

[@PixelThorn]

Tagging this one

[@AGeekTragedy]

yay views::nullable

[@origamibulldoser1618]

Well... I'm sure this is nice. On paper. But calling n-1 additional tests just to be able to not write the checks.. I don't know. Seems too blunt of an instrument.

[@djupstaten2328]

I would say that if the intention is to prevent programmers from introducing errors, using a function type that is so difficult to explain and comprehend it has become a meme is an exceptionally bad choice. Simple functors with no fancy name should do. "Monads" should never be used, as they are so bewildering a team larger than 2 is almost guaranteed to get it wrong over and over. And what they do can be done a hundred other ways.

[@AnthonyDentinger]

Using the term "monad" IRL to people who do not know the term definitely sounds like showing off and not very practical, at least to me at the moment. However, from experience using these functions is definitely cool and quite useful. If you’ve ever used Java8’s Stream API, it includes a bunch of monadic operations like flatMap(). It takes time to get used to, and it’s pretty hard to read once you’ve written the code (I tend to split up complicated Streams into multiple variables for clarity), but dang if it’s clean and quite error-free! I don’t use them too often with Optionals, but with iterable types (the Java equivalents of C++’s STL containers) it’s really fantastic. You have a hard time going back once you’ve tasted it, let me tell ya! 😮 This talk goes into quite a bit of details and goes through a lot of information very fast, but in practice this stuff is not too hard to use; even less-experienced workmates figured Java Streams out on their own just by looking at existing code.

[@yannikmuller2876]

I learned functional programming in university in about 2 month. I am profiting from it for the rest of my life. I don't think this is an unreasonable investment to make. Wheter it's python c++ or java,I regularly find they miss great concepts that f.ex. Haskell already has nailed down. Sometimes a few years down the line these concept are now part of the core language. But there is still lot's of thing left to learn. F.ex. type class are just way superior interfaces in my opinion.

[@Axman6]

C++ Ranges: Reinventing Haskell from 20 years ago, but this time it’s ugly!

[@ZahrDalsk]

(And fast, unlike Haskell.)

[@AGeekTragedy]

But with less iterating through linked lists, which is not *nothing* in the contexts where C++ is used

[@anon_y_mousse]

@@ZahrDalsk Not if you write it like the examples as shown. Processing each entry three different ways across three different loops is bad. And please don't try to justify writing it that way with "but the compiler will optimize away my poorly formed code".

[@wizardy6267]

Back to my university time, I enrolled in Haskell paper. I forget most of the things I learned from that paper since that was like 20 years ago. But I remembered at the end of the semester, after all assignments are done. One student asked the lecture to show a "practical and real world" app written in Haskell.Then the demo I saw is an app draws 2d cycles and rectangles. I passed the paper with a good score but never touched Haskell after that.

[@yannikmuller2876]

​@@ZahrDalsk Actually, Haskell can be equally fast. However, in this case, Haskell becomes equally ugly. That's just a trade-off that you have to decide upon.

[@anon_y_mousse]

I personally hate all of the constructions shown here, but especially the "for" versus weird lambda garbage. Both are awful. I don't see why you can't just have a template class that has an explicit conversion operator for bool and the type being stored as well as a dereference operator for the type being stored. Yeah, I know, you couldn't store a bool in that way, but it honestly makes no sense to ever use an optional for a boolean value. In fact, the only time it really makes sense for a primitive type is for 2's complement integer types, because you don't have an explicit error value. For complex types, it should be enough to use it as a pointer and check for null. In either case, an optional type that had an explicit type conversion to bool and to whatever type is being stored should suffice, with a specialization on bool as the type being stored to explicitly generate a compile error. If you structure your code so you need an optional to return a bool, then I hate you. As for all the rest of the talk, with regards to using monads at all, I find them neither easier to understand than an actual for loop, nor do I care for the performance implications if they're structured wrong, and they're nearly always structured wrong by bad developers. Error handling can be a pain, but we shouldn't make it harder on ourselves by hand waiving away all errors into a single point preventing us from determining where the failure is happening, and we shouldn't write slower code on purpose. Feel free to ignore all this, because it's mostly just for catharsis that I write it since usually what I write gets ignored anyway and I think 99% of developers suck.

[@stefanalecu9532]

"and I think 99% of developers suck" Nice, having a superiority complex believing you're in the 1%, Dunning-Kruger would like to have a talk with you