We've isolated the console log and variable mutation side effects to the boundaries of our program by defining them in their own functions logCalledWith, incNumCalls, and logNumCalls
That's not the way you handle side effects in functional programs, you should never have impure functions.
The simplest way to make that program pure is by having incNumCalls return the new state, having the logNumCalls be lazy, meaning functions that return the effect of logging, but don't log.
Logging in functional programs is hard to implement and generally leverages the Writer monad, which, differently from your example, truly keeps the effect outside the boundary.
That's not the way you handle side effects in functional programs, you should never have impure functions.
Says who? Why am I never allowed to have impure functions?
The simplest way to make that program pure is by having incNumCalls return the new state, having the logNumCalls be lazy, meaning functions that return the effect of logging, but don't log.
This doesn't sound very simple to me. I don't see how returning an effect of logging but not actually logging makes my life any easier. Is it not simpler to just log when you want to log?
Logging in functional programs is hard to implement and generally leverages the Writer monad, which, differently from your example, truly keeps the effect outside the boundary.
Logging in functional JavaScript programs is easy if you don't leverage the Writer monad. Maybe in Haskell the definitive way is to use a Writer monad, but in JavaScript you can just console.log. It's quite straightforward.
Your program is still not pure.
I never said my program is pure. The final add10 is pure, and the other functions are effectful. I said "the final program is a composition of side effecting functions and a pure function". I was never trying to make my entire program pure in the first place. You can't just make your side effects go away. At some point you have to deal with them. Why not deal with them at the boundaries of the same program?
It seems to me you are prescribing the practices you picked up in Haskell onto JavaScript. That is not sensible. Different languages have different boundaries for effects. In Haskell, you straight up declare your effects with the types, so it seems like the rest of your program is pure (which it is, in Haskell). In JavaScript, the effects are implied in the syntax and global functions, for example, console.log very specifically has the effect of writing out to the console.
I don't see how this belongs here. I don't need Monads to do what I need to do. I especially don't need them to program functionally in JavaScript. In fact, I started my library rubico to double down on functional composition and rebuke the complex hierarchy of effectful types of "traditional" functional programming as prescribed by zealots such as yourself.
Lazy Pure Static Functional Programming isn't "functional programming". It's a weird corner of FP introduced in the 80s that has few inherent advantages.
Almost all the ideas Haskell introduces are to solve problems Haskell creates, ie., those due to lazyness.
In a language with a semi-colon you do not need a monad.
"Functional Programming" as in Programming with Functions can only be pure because a non-pure function is simply NOT a function (it is a procedure). It might be argued that the lazyness is optional, and in fact it is but as soon as you write a side effect inside one of your "functions" and that gets executed you will transform by definition your program to be procedural given the composition of a function with a procedure is a procedure.
There is a misunderstanding, the definition of function is a binary mapping between sets. The interpretation from MDN is strictly related to the world of programming languages where the term function is improperly used to represent any procedure. It is not the meaning used in "functional programming" where functional refers to a classic function. Sometimes in programming we like to add the term "pure" to denote when a function (from the language perspective) is actually a function.
One thing to note is that all of the nice properties of "pure" functions that are leveraged in FP are almost never respected when functions are not "pure" (or better, not functions)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your program is still not pure.
That's not the way you handle side effects in functional programs, you should never have impure functions.
The simplest way to make that program pure is by having incNumCalls return the new state, having the logNumCalls be lazy, meaning functions that return the effect of logging, but don't log.
Logging in functional programs is hard to implement and generally leverages the Writer monad, which, differently from your example, truly keeps the effect outside the boundary.
kseo.github.io/posts/2017-01-21-wr...
Says who? Why am I never allowed to have impure functions?
This doesn't sound very simple to me. I don't see how returning an effect of logging but not actually logging makes my life any easier. Is it not simpler to just log when you want to log?
Logging in functional JavaScript programs is easy if you don't leverage the Writer monad. Maybe in Haskell the definitive way is to use a Writer monad, but in JavaScript you can just console.log. It's quite straightforward.
I never said my program is pure. The final
add10is pure, and the other functions are effectful. I said "the final program is a composition of side effecting functions and a pure function". I was never trying to make my entire program pure in the first place. You can't just make your side effects go away. At some point you have to deal with them. Why not deal with them at the boundaries of the same program?It seems to me you are prescribing the practices you picked up in Haskell onto JavaScript. That is not sensible. Different languages have different boundaries for effects. In Haskell, you straight up declare your effects with the types, so it seems like the rest of your program is pure (which it is, in Haskell). In JavaScript, the effects are implied in the syntax and global functions, for example, console.log very specifically has the effect of writing out to the console.
I don't see how this belongs here. I don't need Monads to do what I need to do. I especially don't need them to program functionally in JavaScript. In fact, I started my library rubico to double down on functional composition and rebuke the complex hierarchy of effectful types of "traditional" functional programming as prescribed by zealots such as yourself.
Well, you can do what you want, but you shouldn't be calling it functional programming, as it's not really.
Lazy Pure Static Functional Programming isn't "functional programming". It's a weird corner of FP introduced in the 80s that has few inherent advantages.
Almost all the ideas Haskell introduces are to solve problems Haskell creates, ie., those due to lazyness.
In a language with a semi-colon you do not need a monad.
"Functional Programming" as in Programming with Functions can only be pure because a non-pure function is simply NOT a function (it is a procedure). It might be argued that the lazyness is optional, and in fact it is but as soon as you write a side effect inside one of your "functions" and that gets executed you will transform by definition your program to be procedural given the composition of a function with a procedure is a procedure.
I would just like to point out this interesting take from the MDN web docs on functions. (link)
It sounds like they're saying a function and a procedure are the same. Is there a misunderstanding here?
There is a misunderstanding, the definition of function is a binary mapping between sets. The interpretation from MDN is strictly related to the world of programming languages where the term function is improperly used to represent any procedure. It is not the meaning used in "functional programming" where functional refers to a classic function. Sometimes in programming we like to add the term "pure" to denote when a function (from the language perspective) is actually a function.
One thing to note is that all of the nice properties of "pure" functions that are leveraged in FP are almost never respected when functions are not "pure" (or better, not functions)