> You gotta stick the state somewhere. This is true, and it’s the primary reason I’m not finding some way to work in Haskell. But it’s also kind of a cop out.

> You gotta stick the state somewhere. This is true, and it’s the primary reason I’m not finding some way to work in Haskell. But it’s also kind of a cop out. The issue isn’t just that state exists and will do well beyond our extinction. It’s not even just about how you manipulate state or how many restrictions you put on mutability. It’s also about the visibility of state and stateful processes, how that’s signaled, and the conventions that fall out. This isn’t something I fully understood until I worked with Clojure. Immutable-by-default was a fantastic constraint. But more valuable to me was that where state is accessed or changed, you can tell immediately. Just having that gives you several insights: - This code is more likely to be impacted by outside behavior - This code has additional concurrency requirements - This code may be unnecessarily complex - This code may be hard to understand a week or more later - This code is documenting its implicit dependencies Since I’ve moved on from Clojure I’ve mostly worked in TypeScript, and I’ve done my best to apply the same principles. In some ways it’s a loss: you can’t signal stateful access with @ or ! or *. But that’s all convention. In other ways it’s a huge win: if you’re trying to write functional code in TS, you eventually end up with the idiom that async/await and Promise types are generally signals of state. And the type system calls that out much more reliably. All of that said, you do gotta stick the state somewhere. But where and how you do is the difference between eternal pain and eternal much-less-pain. And coupling state with functions on objects is definitely more likely to produce more eternal pain.