4 ms·
Great article. This is really about a mental shift. When given a problem like "dormant customers should be charged", it's natural to model the problem as verbs:
by munificent 6y ago
Great article. This is really about a mental shift. When given a problem like "dormant customers should be charged", it's natural to model the problem as verbs: "find the dormant customers and charge them".
However, that description relies on implicit state: it assumes a world where all dormant customers have not been charged. As we all know, relying on hidden implicit state is the source of all evil. When you describe your problem using verbs, you are essentially modeling it in terms of a diff between how the world is and how you want it to be. But that diff is only correct if you have a perfectly correct description of how the world currently is.
It's better to take a step back and think of your problem purely in terms of the world you want to end up in as a result: "all dormant customers have been charged". Framing it that way makes questions like "which dormant customers have already been charged?" more obvious to consider.
- musingsole 6y ago> think of your problem purely in terms of the world you want to end up in as a result Great framing! Isn't this the difference between imperative and declarative statements/code/systems?
- zambal 6y agoA declarative programming language should indeed allow you to think mostly about the result you want and not much about the how, but I'd say GP's comment is more about the design phase. The actual implementation could still be highly imperative.
- Wistar 6y agoYour summary is the second application of understanding paint: the clarity coat, the second view into the problem space.
- Rule35 6y agoPerhaps the rule is "charge all customers - active at rate X, dormant at rate Y". And then the question adds state, "as of yyyy/mm/dd, which customers were more than $30 into credit?"