Functional Programming in C++ (2013) • Hacker News Board

Re: Functional Programming in C++ (2013)

#61

Post by eli_gottlieb » Sun, Jul 26, 2015, 6:26 PM UTC

sago wrote: post #43

eli_gottlieb wrote: post #5

Earlier quoted context omitted.

The monad type-class operations carry the context around for you. You can just write in imperative-seeming do-notation. The difficult part is trying to combine monads.

Here's what I don't get with Monads, why I've not felt the need to create a Monad-like system in my (non Haskell) code. The 'world' is carried on the back of one parameter, right? So if I want to run a function taking two parameters in a particular 'world', which parameter is the Monad? If both of them are, what if they disagree which world is used? Perhaps I haven't reached the fabled epiphany of monads, but they se…

Don't think of "a monad" as a thing. Think of "monad" as "a way you can threat things": you can treat things monadically by implementing the monad operations for them, such that they obey the monad laws.

Re: Functional Programming in C++ (2013)

#62

Post by sago » Mon, Jul 27, 2015, 1:00 AM UTC

eli_gottlieb wrote: post #61

sago wrote: post #43

Earlier quoted context omitted.

Here's what I don't get with Monads, why I've not felt the need to create a Monad-like system in my (non Haskell) code. The 'world' is carried on the back of one parameter, right? So if I want to run a function taking two parameters in a particular 'world', which parameter is the Monad? If both of them are, what if they disagree which world is used? Perhaps I haven't reached the fabled epiphany of monads, but they se…

Don't think of "a monad" as a thing. Think of "monad" as "a way you can threat things": you can treat things monadically by implementing the monad operations for them, such that they obey the monad laws.

So do I. It's a pattern. But you don't create things a particular way for no reason. My point is about being able to see the point.

I get the sense that there are people who think Monads are a fundamentally powerful pattern for structuring software. And I don't get that. And I'd like to, because if I'm missing something, it could mean I improve my code architecture.

Monad's qualify as a 'that's an interesting way to get around its self-imposed restrictions' moment when learning Haskell (which I've not used with any seriousness) for me. So I don't get the fuss. I'm not saying that I don't see the logic of those restrictions, nor that I don't see why you'd want to voluntarily code with similar restrictions in other languages. More than, if you're going to write something that has to work around those restrictions in another language, I've no idea why you'd necessarily chose Monads.

Or, put another way, what use are Monads in non Haskell code?

Re: Functional Programming in C++ (2013)

#63

Post by pekk » Mon, Jul 27, 2015, 2:59 AM UTC

gnuvince wrote: post #50

pekk wrote: post #46

Earlier quoted context omitted.

Are you somehow not in control of how x is being changed? You seem to have said that literally any statefulness is "exhausting".

Anyone, anywhere could modify x, which is what makes reasoning about this code difficult. When your entire program is a collection of mutable state that can be mutated by any piece of code, understanding what's going on becomes really difficult if not impossible. One thing that people are adopting from FP is to limit what is mutable, and when possible make state explicit.

That isn't true. I don't understand why you can't use a language that offers encapsulation.

Re: Functional Programming in C++ (2013)

#64

Post by pekk » Mon, Jul 27, 2015, 3:01 AM UTC

S4M wrote: post #52

pekk wrote: post #46

Earlier quoted context omitted.

Are you somehow not in control of how x is being changed? You seem to have said that literally any statefulness is "exhausting".

What convinced me that avoiding mutations as much as possible was having to deal with code like that (in java): public class MyBigClass() { private int a; private int b; //hundreds of lines of code private int calculateSomething() { //do something a = a+1; return b*b; } //hundreds lines of code private int calculateSomethingElse() { int c = calculateSomething(); return a+c; } //hundreds of lines of code public return…

That demonstrates some design flaws of Java, yeah, because your "private" variables are effectively just globals anyway.

The guy who is not using encapsulation at all this year will be making similar mistakes (massively long bodies, proliferation of unnecessary entities, etc.) if he switches to functional programming next year. It's not a panacea.

I'm afraid this doesn't demonstrate that any tiny bit of statefulness is "exhausting."