Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I disagree. Constructing a data type that can be in an invalid state is packing powder in the shells for your footgun. I love a trivial state machine represented with types. Trivial code is wonderful; I have bigger fish to fry than keeping track of states represented implicitly.

That being said, there’s a real tendency to take “make illegal states unrepresentable” the wrong way. I see it used as an excuse for sheer laziness, resulting in code that takes a needlessly narrow view of what constitutes valid input and handles errors in the most graceless possible way. Just because some data isn’t a valid input, doesn’t mean dropping it on the floor is always the right thing to do.

Take handling json as an example. There are at least three layers. 1. Is it syntactically valid json? 2. Is it structurally valid? Objects have the expected fields, arrays are not scalars, and so on? 3. Is it semantically valid? Numbers are within bounds, strings are not too long? For each layer, the appropriate response is different, and for each layer there’s an appropriate representation for failure. That is: failure is a legal state, and it must be representable. Confusion about this has led to some pretty poor software of late.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: