Jon Pretty

This might be true, but you probably have to revisit such code less frequently, and have less of it.

Not sure which code you mean. I do have less maximally polymorphic code than just plain bad code. My argument is not against maximal polymorphism, but against unnecessary maximal polymorphism. Why abstract over something that is always going to be concrete?

Because often the cost of developing the polymorphic version isn't high. When you write the concrete version, and you discover you need similar functionality again, you have a choice between generalizing the first one & updating its call site and writing a new concrete version.

Both of those are less desirable than simply using the polymorphic version you wrote the first time. That's not to say premature generalization is always a good idea: it certainly isn't. But it's not a universal truth that you should do the minimal that solves today's problem.

I didn't mean to argue that doing the strict minimum to solve today's problem is always the best way to go, but that always making things as abstract as possible because it might be useful later isn't. It's possible I got lost on the way though.

Yeah, I didn't want to make a strawman out of that, because I saw your original point was about "maximally-polymorphic" code. But I wanted to take the opportunity to argue against "doing the minimum possible".

Yeah my tweets can clearly be understood to imply that. In a way, I do imply that, it's just that definition of "minimum" might not be the same as yours in this instance :)

I know that I prematurely generalize most of the time. I build things for reusability. One thing I think I've got better at with experience is knowing when to do it (and how), and when not to.