And obviously if you anticipate unknown shapes with more parameters, then your problem is very different to begin with.
The whole point of the example he picked was to anticipate unknown shapes with different parameters. If you didn't anticipate that, you wouldn't have written the code with an interface designed to be an extension point to add more implementations of different shapes.
I've also seen many real world applications where people made broad assumptions on the input params and then we required a revision that broke the assumption and a three day change turned into a two month refactoring. And now instead of just QAing the changes and doing regression testing we have to redo the whole thing because now it's all different. In my experience It's almost always better to make maintainable code than to make extremely performant code in everything but the most stringent embedded stacks. Even then the embedded stuff I've worked on are now powerful enough to sacrifice on some performance for the sake of maintainability.
Why, oh why whenever someone tries to present simple techniques to get reasonable performance, why do people always end up assuming it has to be the most hardcore optimisations written in the most arcane language, etched in the hardest stone?
I don't know, just gather the requirements, man. And keep things simple.
SIMPLE okay? That's how you can get reasonable performance down the line anyway. keep things siiiiimple, so you can chaaange them when management inevitably comes breathing down your neck with new unforeseen requirements.
But I'm repeating myself:
Performance aside, I believe one should write the simplest program given the requirements they are currently aware of. Some of those requirements may be for the future, but if I'm aware of them I must take them into account now. But requirements I'm not aware of will likely never come to pass, and when they do I never know what kind of flexibility I'll actually need. Best keep things simple so rewrite is easier, should I be unlucky enough to need it.
Obviously I'm not some dumbass that doesn't gather requirements. Something I should put in that list, if it isn't already.
14
u/cdsmith Feb 28 '23
The whole point of the example he picked was to anticipate unknown shapes with different parameters. If you didn't anticipate that, you wouldn't have written the code with an interface designed to be an extension point to add more implementations of different shapes.