
Good design and type safety in Yahtzee - nuriaion
http://h2.jaguarpaw.co.uk/posts/good-design-and-type-safety-in-yahtzee/
======
skybrian
Although I don't think it applies in this example, it might be worth pointing
out a trade-off: the more constraints you encode into parameter or return
types in a API, the more specialized it is and the more likely that a change
will be backward incompatible.

~~~
firethief
Let's consider two types of constraints: incidental constraints, and necessary
constraints that would also exist when latently-typed. Having much of the
former is a design smell. The latter force you to address problems at compile
time that might otherwise be hidden crashes, security flaws, logic bugs... I
think the trade-off is that designing with types is hard, and without a lot of
experience in a statically-typed language types can create more problems than
they solve, as in the original code this blog post corrects.

------
z3t4
In a program that has like 20 bits of data, eg. the complexity of a hello
world. you shouldn't be worrying about things like performance, safety, etc.
Just allow yourself to write stupid ugly code and be done with it.

~~~
dcsommer
Learning to "do it right" in a simpler setting is how we learn to apply the
lesson in the real world. It's a lot more mental effort, at first, to write a
program this way. But over time, the exercise pays off and you find it natural
to write more readable, correct, performant, etc. code as a result.
_Appropriate_ laziness is good engineering, but subject mastery comes from
avoiding laziness and intentionally practicing. The trick is to figure out how
much of this intentional practice you can get away with on the job ;)

