5 ms·

> I have yet to encounter a single mutable variable. > However, it is constantly poking at a database, and different modules communicate with each other asynch

by Twisol 6y ago

> I have yet to encounter a single mutable variable. > However, it is constantly poking at a database, and different modules communicate with each other asynchronously over a message queue. I think you found your mutable variables... No, I agree, functional programming on its own is not a panacea. Every program has state, even functional programs. FP promotes modeling state implicitly, by representing it in the program text itself (or more precisely, the "continuation" of the program). The evaluator of the program is responsible for managing that state, rather than the program author themself(^). The problem is that, since the state is implicit, it becomes hard for multiple modules of the program to collaborate over that state. There are ways around this -- for instance, have each module supply descriptions of the changes they want to apply, and have a central authority manage the actual state -- but you ultimately end up with some way to "address" the state, either explicitly or by reference to an entity that owns it. In either case, you have the "address" of some thing that may change over time, and so you've got yourself a mutable cell. All this to say that FP is indeed not a panacea -- every system needs to have a clear data model. Not only the structure of the data needs to be understood, but also the ways and means in which it is allowed to evolve over time. (Something something Linus Torvalds and Fred Brooks something flowcharts vs. tables something data vs. code.) It sounds like the system you're grappling with has a very loose data model -- I'm not surprised it isn't navigable. But the core idea I at least take away from FP -- that explicit state should be avoided -- is still vitally valuable, even if you approach it differently in different environments and for different problems. "Out of the Tar Pit" is a wonderful exegesis of the idea. [1] (^) Does singular "they" become "themself" or "themselves"?... [1] https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf https://github.com/papers-we-love/papers-we-love/blob/master...

tel 6y ago
I find your depiction of FP state interesting as I think of it as the opposite. In my practice of FP, it tends to force me to make state explicit and and available. I follow what you’re saying as well with regard to the continuation of the code, but there’s something that feels very distinct between static and runtime state.
- Twisol 6y ago
  > In my practice of FP, it tends to force me to make state explicit and and available. Ha, I think I get what you mean. The state that you do have is generally called out more visibly. I do think that's a product of defaulting to state avoidance, since the thing you're avoiding becomes more visible whenever it is present. I think FP does a good job of pushing as much state as possible into the "state in the continuation" category, but there seems to be a hard kernel of mutable state that doesn't dissolve so easily. On the bright side, that makes for a bright, shining target to aim research at (LVars, CRDTs, logic programming). > there’s something that feels very distinct between static and runtime state For what it's worth, I'm only thinking about runtime state here. Can you call out where it seems like I'm referring to static state?
  - mumblemumble 6y ago
    > The state that you do have is generally called out more visibly. You see, this is the exact opposite of what I was discovering in this codebase. Sure, in Haskell, you have an IO monad that effectively puts bright blinking lights and klaxons over all the state, and a compiler that forces you to use it. But the vast majority of functional-style code is not written in a language like that. It's written in a language like Scala or Clojure or JavaScript that allows you to sneak a side effect into any portion of the call tree. And, by being several layers deep in the call tree, it's not visible. It's hidden, and, when it's being done in the context of a generally functional idiom, it's downright pernicious. You hit the nail on the head in your comment further up. I did find my mutable variables. My epiphany after seeing this code is that, in a language where the only thing that can enforce true purity (as opposed to simply trying to avoid mutable variables as a general rule) is programmer discipline, the natural equilibrium point is code that still every bit as riddled with state. It just delegates the management of that state out to Redis or whatever. Discipline is a good enforcement strategy for small individual projects. It's possibly also a good one for open source projects. I don't believe it can work for corporate team projects, because social factors at play generally won't allow it to work. There will always be some business constraint that prompts people to take shortcuts.
    - 6y ago
lasfter 6y ago
I still say "themselves" with singular "they", in western Canada
jcora 6y ago
It's the other way around. State (and side effects) are explicit in pure programs, and implicit in impure programs.
- Twisol 6y ago
  'tel said the same thing, and I can see it both ways. But I don't think it helps me much to simply state the opposite position -- you don't give me much to reply to :)
- mumblemumble 6y ago
  They're generally explicit in both, albeit in different ways. They're first class (which isn't quite the same thing) in pure programs.

by Twisol 6y ago

tel 6y ago

I find your depiction of FP state interesting as I think of it as the opposite. In my practice of FP, it tends to force me to make state explicit and and available. I follow what you’re saying as well with regard to the continuation of the code, but there’s something that feels very distinct between static and runtime state.

Twisol 6y ago
> In my practice of FP, it tends to force me to make state explicit and and available. Ha, I think I get what you mean. The state that you do have is generally called out more visibly. I do think that's a product of defaulting to state avoidance, since the thing you're avoiding becomes more visible whenever it is present. I think FP does a good job of pushing as much state as possible into the "state in the continuation" category, but there seems to be a hard kernel of mutable state that doesn't dissolve so easily. On the bright side, that makes for a bright, shining target to aim research at (LVars, CRDTs, logic programming). > there’s something that feels very distinct between static and runtime state For what it's worth, I'm only thinking about runtime state here. Can you call out where it seems like I'm referring to static state?
- mumblemumble 6y ago
  > The state that you do have is generally called out more visibly. You see, this is the exact opposite of what I was discovering in this codebase. Sure, in Haskell, you have an IO monad that effectively puts bright blinking lights and klaxons over all the state, and a compiler that forces you to use it. But the vast majority of functional-style code is not written in a language like that. It's written in a language like Scala or Clojure or JavaScript that allows you to sneak a side effect into any portion of the call tree. And, by being several layers deep in the call tree, it's not visible. It's hidden, and, when it's being done in the context of a generally functional idiom, it's downright pernicious. You hit the nail on the head in your comment further up. I did find my mutable variables. My epiphany after seeing this code is that, in a language where the only thing that can enforce true purity (as opposed to simply trying to avoid mutable variables as a general rule) is programmer discipline, the natural equilibrium point is code that still every bit as riddled with state. It just delegates the management of that state out to Redis or whatever. Discipline is a good enforcement strategy for small individual projects. It's possibly also a good one for open source projects. I don't believe it can work for corporate team projects, because social factors at play generally won't allow it to work. There will always be some business constraint that prompts people to take shortcuts.
  - 6y ago

lasfter 6y ago

I still say "themselves" with singular "they", in western Canada

jcora 6y ago

It's the other way around. State (and side effects) are explicit in pure programs, and implicit in impure programs.

Twisol 6y ago
'tel said the same thing, and I can see it both ways. But I don't think it helps me much to simply state the opposite position -- you don't give me much to reply to :)
mumblemumble 6y ago
They're generally explicit in both, albeit in different ways. They're first class (which isn't quite the same thing) in pure programs.