Hacker News Reader

Comment by qayxc | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com