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

[@k17101989]

Transform followed by a join

[@majohime]

I like how this talk explains std::ranges from functor & monad point of view in nice and simple way. But to the end of it stuff gets exponentially more complex now talking about proposals and concurrency and other potential stuff which is whole new world and that's too much for person who just learned monad at the start of the presentation, but probably good content for those who came to talk already knowing all basics.

[@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)

[@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.

[@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.

[@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.

[@AGeekTragedy]

yay views::nullable

[@bart9522]

Why are you using std::function? Seems not needed.

[@PixelThorn]

Tagging this one

[@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.

[@cppforeveryone]

So, you don't aim at having code that can be compiled, and you don't aim at providing a good definition of the main topic you want to explain. There is some value in the talk... but it's not wortth the time.

[@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