> Kindly cite a problem with admitting mistakes and growing and learning from them.
Nothing against this.
> Then explain how consistency is a bad thing.
This is a really boring conversation, because if I give a good example you'll just define consistency for that example not to apply. For example, picking the token case of naming functions in such and such way, it occurs to me that I don't really care if you break rules are long it's done in a way that doesn't affect the interface. If something can be considered an implementation detail, I don't care that it doesn't follow the same rules, as long as the interface doesn't allow you to see it. But then you'll just say something like "oh but 'consistency' doesn't mean a rule applies under any and all circumstances, there's always caveats" bla bla bla.
It's a boring conversation, my point is that you had a dogma, and now you have a different dogma. You think you're evolving, I think you're changing but not evolving in a bigger way.
Nothing against this.
> Then explain how consistency is a bad thing.
This is a really boring conversation, because if I give a good example you'll just define consistency for that example not to apply. For example, picking the token case of naming functions in such and such way, it occurs to me that I don't really care if you break rules are long it's done in a way that doesn't affect the interface. If something can be considered an implementation detail, I don't care that it doesn't follow the same rules, as long as the interface doesn't allow you to see it. But then you'll just say something like "oh but 'consistency' doesn't mean a rule applies under any and all circumstances, there's always caveats" bla bla bla.
It's a boring conversation, my point is that you had a dogma, and now you have a different dogma. You think you're evolving, I think you're changing but not evolving in a bigger way.