42:48 - implementing reverse by accumulating into a set of chained function calls & then invoking them all - this what the IO monad does. You take an impure operation, an impure function (getting input or writing output) and wrap it in a monad. Wrapping in a monad: instead of letting the side effects happen, you put the side effects as an additional variant to the original output. Then you do the monoidal composition - chaining together all these monads - and you’re left with an accumulation of how the data will flow through. You’re left with all your yet-to-be-called function calls. Finally, once you’ve built up this structure, you let it rip. You let all the impure IO happen, reading from users and writing to the screen and all that. Super cool!
Good talk. Accumulate has started turning up in my work more and more recently as well. One particular instance I was proud of was a messaging framework that sent messages received from a client to a number of observers. The observers could respond with vectors of messages to send back. Thanks to Boost.Signals2, the "token combiner" function wrapped accumulate to flatten the returned vectors of messages into one vector of messages.
Nice talk. I would have liked, it was a bit more focused and with more real world examples like the improved API mentioned a few times. Also the main (and only) complete example felt a bit off, because there seems to be missed opportunity to use overloading instead of the 6 funcs passed.
The identity for min would be the maximum value of that type, and for max would be the minimum value. You can use +,- inf for floats or the max, min value for ints.
Turning trivial stuff into complicated shit so someone can write a PhD about it. I just can't stand this type of modern programmers anymore. There is no advantage to save 3 lines of very clear code. I had to turn of at the JSON printer. Damit. Thats a stupid API and coding style and i guess 100 times less performant then what i would write.
I disagree: the advantage is expressiveness. Yes, most of the algorithms are simple loop wrappers. But writing a straightforward for-loop tells you nothing more than the fact that you are iterating a collection. A find/find_if tells the reader you are searching a collection. A transform tells the reader that you are performing a mapping operation on a collection. An accumulate tells the reader that you are reducing the collection to some single value. The less a reader has to keep in their head to figure out about your code, the easier it is to grok.
Agreed. Original comment-er doesn't have sufficient experience to appreciate the lack-luster code that re-writing foreach loops over-and-over-again, never specifying intent, does to more "seasoned" programmers.
Using accumulate to do anything like join strings is a performance disaster. See stackoverflow.com/a/18703743/1639256. Because of the way it's specified, the copy assignment in the loop can not be elided without sacrificing readability/clarity of intent. It is defined in not , that should be a clue.
42:48 - implementing reverse by accumulating into a set of chained function calls & then invoking them all - this what the IO monad does. You take an impure operation, an impure function (getting input or writing output) and wrap it in a monad.
Wrapping in a monad: instead of letting the side effects happen, you put the side effects as an additional variant to the original output.
Then you do the monoidal composition - chaining together all these monads - and you’re left with an accumulation of how the data will flow through. You’re left with all your yet-to-be-called function calls.
Finally, once you’ve built up this structure, you let it rip. You let all the impure IO happen, reading from users and writing to the screen and all that.
Super cool!
Good talk. Accumulate has started turning up in my work more and more recently as well. One particular instance I was proud of was a messaging framework that sent messages received from a client to a number of observers. The observers could respond with vectors of messages to send back. Thanks to Boost.Signals2, the "token combiner" function wrapped accumulate to flatten the returned vectors of messages into one vector of messages.
Would it blow your mind if I told you you can use std::inner_product as a zip function? It's even more powerful than std::accumulate.
Yes, I can see where that would be useful. Another function I should keep in my toolbox.
Nice talk. I would have liked, it was a bit more focused and with more real world examples like the improved API mentioned a few times. Also the main (and only) complete example felt a bit off, because there seems to be missed opportunity to use overloading instead of the 6 funcs passed.
Wow, what a fantastic video
Glad you enjoyed it
I always thought type must be the same, is nice
What's the neutral value for min/max?
The identity for min would be the maximum value of that type, and for max would be the minimum value. You can use +,- inf for floats or the max, min value for ints.
TL;DR: C++ programmer discovers the power of functional programming and starts yet another attempt to cram it into C++
Turning trivial stuff into complicated shit so someone can write a PhD about it.
I just can't stand this type of modern programmers anymore. There is no advantage to save 3 lines of very clear code. I had to turn of at the JSON printer. Damit. Thats a stupid API and coding style and i guess 100 times less performant then what i would write.
I disagree: the advantage is expressiveness.
Yes, most of the algorithms are simple loop wrappers. But writing a straightforward for-loop tells you nothing more than the fact that you are iterating a collection. A find/find_if tells the reader you are searching a collection. A transform tells the reader that you are performing a mapping operation on a collection. An accumulate tells the reader that you are reducing the collection to some single value. The less a reader has to keep in their head to figure out about your code, the easier it is to grok.
9:40
Agreed. Original comment-er doesn't have sufficient experience to appreciate the lack-luster code that re-writing foreach loops over-and-over-again, never specifying intent, does to more "seasoned" programmers.
I hate programmers like you
Using accumulate to do anything like join strings is a performance disaster. See stackoverflow.com/a/18703743/1639256. Because of the way it's specified, the copy assignment in the loop can not be elided without sacrificing readability/clarity of intent. It is defined in not , that should be a clue.