4 ms·

Sure, but what happens, once you want to start supporting other shapes other than basics? Because clean code assumes code will be changed/maintained. Then you

by Ygg2 4y ago

Sure, but what happens, once you want to start supporting other shapes other than basics? Because clean code assumes code will be changed/maintained. Then you get people writing their own horrible hacks. Both clean code and performance oriented design have their extremes. Clean Code has Spring with Proxy/Method/Factory monster... and hyper performance has the extreme in the story of Mel (i.e. read-and-weep only code).

TeMPOraL 4y ago
> Sure, but what happens, once you want to start supporting other shapes other than basics? Because clean code assumes code will be changed/maintained. You get to push back and ask, is it worth the developer time and predicted 1.5 - 5x perf drop across the board (depending on shape specifics)? In some cases, it might not be. In others, it might. But you get to ask the question. And more importantly, whatever the outcome, you're still left with software that's an order of magnitude faster than the "clean code" one. Clean code "assumes code will be changed/maintained" in a maximally generic, unconstrained way. In a sense, it's the embodiment of "YAGNI" violation: it tries to make any possible change equally easy. At a huge cost to performance, and often readability. More performant code, written with the approach like Casey demonstrated, also assumes code will be changed/maintained - but constraints the directions of changes that are easy. In the example from video, as long as you can fit your new shape to the same math as the other ones, the change is trivial and free. A more complex shape may force you to tweak the equation, taking little more time and incurring a performance penalty on all shapes. Even more complex shape may require you to rewrite the module, costing you a lot of time and possibly performance. But you can probably guess how likely the latter is going to be - you're not making an "abstract shape study tool", but rather a poly mesh renderer, or non-parametric CAD, or something else that's specific.
pkolaczk 4y ago
> Sure, but what happens, once you want to start supporting other shapes other than basics? Sure, but what happens, once you want to start supporting more operations on the shapes?
- Ygg2 4y ago
  Add more abstractions of course.

by Ygg2 4y ago

TeMPOraL 4y ago

> Sure, but what happens, once you want to start supporting other shapes other than basics? Because clean code assumes code will be changed/maintained. You get to push back and ask, is it worth the developer time and predicted 1.5 - 5x perf drop across the board (depending on shape specifics)? In some cases, it might not be. In others, it might. But you get to ask the question. And more importantly, whatever the outcome, you're still left with software that's an order of magnitude faster than the "clean code" one. Clean code "assumes code will be changed/maintained" in a maximally generic, unconstrained way. In a sense, it's the embodiment of "YAGNI" violation: it tries to make any possible change equally easy. At a huge cost to performance, and often readability. More performant code, written with the approach like Casey demonstrated, also assumes code will be changed/maintained - but constraints the directions of changes that are easy. In the example from video, as long as you can fit your new shape to the same math as the other ones, the change is trivial and free. A more complex shape may force you to tweak the equation, taking little more time and incurring a performance penalty on all shapes. Even more complex shape may require you to rewrite the module, costing you a lot of time and possibly performance. But you can probably guess how likely the latter is going to be - you're not making an "abstract shape study tool", but rather a poly mesh renderer, or non-parametric CAD, or something else that's specific.

pkolaczk 4y ago

> Sure, but what happens, once you want to start supporting other shapes other than basics? Sure, but what happens, once you want to start supporting more operations on the shapes?

Ygg2 4y ago
Add more abstractions of course.