3 ms·

Sort of surprised how restrictive some of ideas in this article and comment section are to say if you are writing functional code or not. If you are writing pu

Sort of surprised how restrictive some of ideas in this article and comment section are to say if you are writing functional code or not. If you are writing pure functions and total functions, it's functional code. The rest is syntax. And pure functions are probably best tagged with an asterisk because most of the time you have state to manage somewhere, you're just going to jump through some syntactic hoop (monad) to mask it

LeanderK 8y ago
while I agree with your overall argument, i think this is wrong: > And pure functions are probably best tagged with an asterisk because most of the time you have state to manage somewhere purity does not mean there is no state! This is exactly what the monad (and similiar structures) in haskell is for, which you correctly mentioned. But they don't violeate the purity.
- foolfoolz 8y ago
  i think it devolves into semantics at that point. when each line is doing some DB query or remote HTTP call it rarely matters if it's in a monad or not
  - LeanderK 8y ago
    well, i think it does matter! Especially if you're pure (or try to be) it really matters, because you need constructs like monads to remain pure.
  - yogthos 8y ago
    Exactly, whether you use a monad or not is an implementation detail. The high level idea is that you decouple the code that does IO from the code that's responsible for the business logic.
- gh02t 8y ago
  This is kinda debatable. There is still state in Haskell, regardless of how it's compartmentalized. The implementation of the IO monad for example must rely on state to function, because IO is inherently stateful. You may not have to deal with it as much, but under the hood there is still state. And this matters in practice, because sometimes the desired effects of your program are inherently stateful. For example, if you want to have lines of text output to the terminal in a certain order, you have to at least think about state at some level. If Haskell was truly free of any state, this would be impossible to guarantee. What I will agree with though is that it's mostly possible to ignore state in Haskell, and that individual pure functions are truly pure. My point is that those pure functions can't do anything without invoking state at some point.
  - LeanderK 8y ago
    but I don't see how you are debating me! I mostly agree, but that's my argument :) > If Haskell was truly free of any state, this would be impossible to guarantee. I was never claming that haskell was free of state, i was claiming the opposite! That state and purity are not mutually exclusive, they just result in constructions like monad.
yogthos 8y ago
So, I've been working with Clojure professionally and this is simply not the case. Vast majority of the code is pure with side effects and state being pushed to the edges as a thin imperative shell around the functional core. There's a great presentation discussing Pedestal HTTP library for Clojure, and one of the slides notes that Pedestal has around 18,000 lines of code, and 96% of it is pure functions. All the IO and side effects are encapsulated in the remaining 4% of the code: https://www.youtube.com/watch?v=0if71HOyVjY https://www.youtube.com/watch?v=0if71HOyVjY This is a completely typical situation when you're working with a functional language.
- foolfoolz 8y ago
  this is typical is any paradigm. even something like active record its possible to isolate all the actual DB interaction to just one file.
  - yogthos 8y ago
    It's not just about isolating DB interactions. Any code that deals with IO or creates side effects lives at the edges of the application. Vast majority of the code is written pure functions that can be reasoned about independently of the rest of the application. This is not practical in languages that rely on mutable data because things get passed around by reference. As soon as you pass a reference to an object to a function that's used elsewhere you end up with implicit coupling that's difficult to reason about. Of course, you could use immutable data structure libraries in imperative languages, but then it's completely on you to ensure that you never put any mutable data, such as an object reference, in those. At that point you might as well use a functional language.

LeanderK 8y ago

while I agree with your overall argument, i think this is wrong: > And pure functions are probably best tagged with an asterisk because most of the time you have state to manage somewhere purity does not mean there is no state! This is exactly what the monad (and similiar structures) in haskell is for, which you correctly mentioned. But they don't violeate the purity.

foolfoolz 8y ago
i think it devolves into semantics at that point. when each line is doing some DB query or remote HTTP call it rarely matters if it's in a monad or not
- LeanderK 8y ago
  well, i think it does matter! Especially if you're pure (or try to be) it really matters, because you need constructs like monads to remain pure.
- yogthos 8y ago
  Exactly, whether you use a monad or not is an implementation detail. The high level idea is that you decouple the code that does IO from the code that's responsible for the business logic.
gh02t 8y ago
This is kinda debatable. There is still state in Haskell, regardless of how it's compartmentalized. The implementation of the IO monad for example must rely on state to function, because IO is inherently stateful. You may not have to deal with it as much, but under the hood there is still state. And this matters in practice, because sometimes the desired effects of your program are inherently stateful. For example, if you want to have lines of text output to the terminal in a certain order, you have to at least think about state at some level. If Haskell was truly free of any state, this would be impossible to guarantee. What I will agree with though is that it's mostly possible to ignore state in Haskell, and that individual pure functions are truly pure. My point is that those pure functions can't do anything without invoking state at some point.
- LeanderK 8y ago
  but I don't see how you are debating me! I mostly agree, but that's my argument :) > If Haskell was truly free of any state, this would be impossible to guarantee. I was never claming that haskell was free of state, i was claiming the opposite! That state and purity are not mutually exclusive, they just result in constructions like monad.

yogthos 8y ago

So, I've been working with Clojure professionally and this is simply not the case. Vast majority of the code is pure with side effects and state being pushed to the edges as a thin imperative shell around the functional core. There's a great presentation discussing Pedestal HTTP library for Clojure, and one of the slides notes that Pedestal has around 18,000 lines of code, and 96% of it is pure functions. All the IO and side effects are encapsulated in the remaining 4% of the code: https://www.youtube.com/watch?v=0if71HOyVjY https://www.youtube.com/watch?v=0if71HOyVjY This is a completely typical situation when you're working with a functional language.

foolfoolz 8y ago
this is typical is any paradigm. even something like active record its possible to isolate all the actual DB interaction to just one file.
- yogthos 8y ago
  It's not just about isolating DB interactions. Any code that deals with IO or creates side effects lives at the edges of the application. Vast majority of the code is written pure functions that can be reasoned about independently of the rest of the application. This is not practical in languages that rely on mutable data because things get passed around by reference. As soon as you pass a reference to an object to a function that's used elsewhere you end up with implicit coupling that's difficult to reason about. Of course, you could use immutable data structure libraries in imperative languages, but then it's completely on you to ensure that you never put any mutable data, such as an object reference, in those. At that point you might as well use a functional language.