5 ms·
Part of his point seems to be that you can manipulate data with code, but you can't manipulate your app's typings with code. Expressing your business domain in
by mpalmer 5y ago
Part of his point seems to be that you can manipulate data with code, but you can't manipulate your app's typings with code.
Expressing your business domain in types makes it more likely that a given change of requirements demands a lot of by-hand, non-abstractable changes to the code.
- nightski 5y agoI'd argue on the contrary, having the business domain in the type system allows the compiler to help you ensure the changes are made correctly instead of relying purely on tests (which are still valuable, but I'll take guarantees where I can get them). The type system also makes it easy to reduce the state space of the program. For example, if a method takes an int as a parameter you have a pretty large state space. But if it takes a strongly typed enum which can only be of 3 values, now you have restricted the surface area for which you have to test. If you exploit the type system to this effect it is very powerful.
- mpalmer 5y agoI agree with both your points! I didn't make a value judgment, and in fact I think our comments aren't mutually exclusive, we're just describing the pros for each side of what ends up being a trade-off. The problem I call out is less of an issue for the parts of the domain that are unlikely to change often, or that touch fewer parts of the system.
- myrryr 5y ago"Part of his point seems to be that you can manipulate data with code, but you can't manipulate your app's typings with code." You can do both you know.