4 ms·

> If you have an Order type and a PaidOrder type, the compiler can enforce that you won't use an Order that hasn't been paid in places you shouldn't. First pro

> If you have an Order type and a PaidOrder type, the compiler can enforce that you won't use an Order that hasn't been paid in places you shouldn't. First programmers make Order and PaidOrder classes to enforce static type checks, then they tell you that the system absolutely cannot support credit card chargebacks because PaidOrder becoming unpaid would ruin everything in the architecture, and you should teach the clients to never charge back.

Zababa 5y ago
I could also make a strawman about Clojure not working at all because you can never differentiate between paid orders and orders but I didn't because it would add nothing to the discussion. Adding features and refactoring statically typed code is feasible and has been done by lots of people, your point is invalid.
- cutler 5y ago
  (def order {:amount 5.45 :currency "dollar" :paid true})
  - Zababa 5y ago
    Which is why I called this a strawman. The tradeoff is that you have to check yourself for the ":paid true" instead of having the compiler checking that you're taking a PaidOrder type.