▲ | beders 2 days ago | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
In many (but not all) scenarios "Make illegal states unrepresentable" is way too expensive to implement. Especially when dealing with a fast changing domain, having to support different versions of data shapes across long time periods: dynamic data definitions are more economic and will still provide sufficient runtime protection. "Errors as values" - what is an error? I see this pattern misused often, because not enough thought was put into the definition of an error. "Disk is Full" vs. "data input violates some business rule" are two very - very - different things and should be treated differently. Exceptions are the right abstraction in the first case. It's not in the second case. "Functional core, imperative shell" - 100% agreement here. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
▲ | 7h3kk1d 2 days ago | parent [-] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
""Make illegal states unrepresentable" is way too expensive to implement." This has not been my experience. The speed increase in development not having to worry about the unrepresentable cases have been very valuable. In addition as requirements change migrating old data hasn't been a huge concern. For code changes refactoring the types helps address new cases as well. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|