I feel like this article is missing the point by a country mile. FP proponents very much know that requirements can change and wreak havoc with their type systems forcing them to change large numbers of likes. What the author is missing is that this is be welcomed and vastly preferable to the situation we find ourselves in with Python codebases where those lines still need updating but the code will happily run incorrectly if you fail to find them all. Switching off the alarm doesn’t stop the fire spreading.
I don't agree with that assessment. The problem is that, staying with your analogy, the fire alarm goes off every time someone has to use the toilet. Plus it's not just the alarm going off, it's the entire fire department showing up and doing a forced rearranging of the furniture throughout the entire building each time.
And no, requirement changes don't have to cause that to happen and they don't have to wreak havoc throughout your application due to poor design decisions.
It's fine to encode rules directly into the type system, but only for rules that are known to be fixed (or at least not likely to ever change) throughout the lifetime of the project. For many business rules, however, this unfortunately doesn't apply.
I'm sorry if this is rude, but your analogy is completely off the mark.
Rules that are not fixed but still are a requirement for code to work/make sense still merit an explicit encoding in the type system. You can have an interpreter somewhere that makes sense of unstructured data and delegates to the right functions once it's able to parse and slap a type on it, which will be better than a function that has a bunch of conditionals laying around which at some point either force you to duplicate them or make assumptions you're calling the right functions in the right order.
> It's fine to encode rules directly into the type system, but only for rules that are known to be fixed (or at least not likely to ever change) throughout the lifetime of the project.
But then you lose the benefits a type system offers during refactoring. When business logic does change, if it's linked to the type system, then the logic is forced to change consistently throughout your system.
Of course, you don't want to be forced to change all your code whenever any business logic changes. But you never are. Basic separation of concerns should ensure that different pieces of logic are coupled to different types, such that the blast radius of any type change is limited.
Consider the example from the article, where the PaymentStatus type winds up with a whole bunch of variants. Code that deals with the status of a payment really needs to know all the different statuses a payment could have. If you add a PendingApproval variant to PaymentStatus, your refund workflow should break, because it needs to know to cancel the approval process without issuing a payment when the order is still pending approval. Meanwhile, code that doesn't deal with payments directly can treat that type as a black box.
