alt Hacker NewsI think you you're missing the point though, he did not say that adding those constraints was a bad idea per se, but they are leading to a bad path. If the path is "just add more guard-rails" then we will get to a point where we lose the "soft" part of "software" and you'll find yourself restarting each time you need to change something because at that point the language you chose was already the first wall of a bad program architecture (ease of change).
I lean on types heavily as my vehicle for change.
My UserService doesn't know that it's talking to a UserDB (ironically I learned this from Uncle Bob).
All UserService knows is it has a dependency which, if passed a UserId, will return a User (+/- whatever the failure mode is .. Future<User>? Promise<User>? ReaderT m User?)
When I change my mind about what UserService requires or what UserDB provides (which I frequently do), I immediately look at all the red underlines that my compiler & static types tell me about.