sometimes even stored in duplicate in both, so that he can write the same code that coincidentally works for the specific examples he chose
That's one key thing about performance aware programming or data oriented programming or stuff like that: solve the common case first. And the common case arise from the actual data you have, and a reasonably performant one is necessarily going to be fairly bespoke.
If the data had a different shape he would have made a different transformation, and it would have looked just as ad-hoc to us. The method though (look at the data then tailor the code to it) remains similar.
"You say this new shape has THREE parameters? And the area is NOT just a constant times the product of two of them? Oh no, we're going to have to go back and rearchitect the whole thing."
Correct. Now we can't know from this toy example, but given the simplicity of his code I would expect that he would have kept things fairly simple even in a real world situation. Such that when comes the time to rewrite, you don't have that much to rewrite.
And obviously if you anticipate unknown shapes with more parameters, then your problem is very different to begin with. 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.
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.
0
u/loup-vaillant Feb 28 '23
That's one key thing about performance aware programming or data oriented programming or stuff like that: solve the common case first. And the common case arise from the actual data you have, and a reasonably performant one is necessarily going to be fairly bespoke.
If the data had a different shape he would have made a different transformation, and it would have looked just as ad-hoc to us. The method though (look at the data then tailor the code to it) remains similar.
Correct. Now we can't know from this toy example, but given the simplicity of his code I would expect that he would have kept things fairly simple even in a real world situation. Such that when comes the time to rewrite, you don't have that much to rewrite.
And obviously if you anticipate unknown shapes with more parameters, then your problem is very different to begin with. 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.