People are getting lost about your example as they don't see the analogy as it sounds like validation of input. The point is still there if people are willing t

People are getting lost about your example as they don't see the analogy as it sounds like validation of input. The point is still there if people are willing to look past the confusion, that making a type hierarchy requires you clearly know upfront what different subsets of the data you deal with actually look like and this will change at different stages of the project. This is the reason people ditched c++ and java in 2000 and started hacking in python and js, at least at the beginning although things are shifting. The thing is a lot of things are reversed here, the reality is the way evolution is more sensible is to "generalize" from the bottom up, unless you are very sure from the start that certain types categories make sense for your problem. That's how things should always be, you can only generalize once you've worked through a problem and realized certain aspects are actually common in someway and can be connected somehow, and thus you can take a subset of data you have in your program and organize it into a type. The thing is I feel like that is even harder than thinking top-down (which I feel like is where the pendulum is swinging now) because that takes time. The reason top-downers still do their thing is they feel their method is better is selective thinking (sorry, I know this is harsh) because they honestly discount the anger and fury people from the outside have dealing with their code and they ignore the amount of refactoring they need to do when their designs break. In fact, they love the churn really or at least merely accept it as a "part of development."