Jon Pretty

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.

It really has to be a balancing act: how reusable can you make the first implementation? How likely is it that you'll need it? How difficult is it? How opaque will the implementation be?

And that is precisely what I meant by premature optimisation: as soon as I know I need a function to be polymorphic, I make it polymorphic. Not before - not because it's hard to *write*, but because it piles up to something that will eventually be hard to *read*

That's the problem, though: you may have to change the call site in another (unrelated) location now. You may have to make a breaking change to an API which would not have been necessary if you had written the generalized version from the outset.

This is too often a hypothetical benefit, IME, and leads us open to claims of YAGNI. I find arguments for maximal polymorphism and/or abstraction on the grounds of precision much more compelling (and more useful in practice too!) <insert-Dijkstra-quote-here>

I certainly endorse those grounds. ;) But I think that being able to claim YAGNI confidently requires a lot of experience (or reading of tea leaves). There is a cost (in terms of technical debt) of being wrong...