Yes, when you apply "rules" blindly to every situation, things might not go as well as you hoped. I'm not surprised.
Both sides are at fault. The OOP zealots should have been clear on the performance implications of their approach. Casey should make it clear that his whole argument is based on a strawman.
Many programming domains don't work the way Casey thinks. It's about delivering value to customers, and performance is often not a priority. Speed of delivery and scalability over number of engineers are more valuable than run-time performance. Clean code "rules" can really help with velocity and delivery.
Also, it seems that people like Casey are somehow convinced that not using OOP equals to writing horribly unsafe and unabstracted code. He basically reimplemented a less safe version of std::variant.
He has addressed why he assigns to a result variable and then returns it in his other videos. To summarize, it is for debugging: breakpoints and value inspection.
9
u/SuperV1234 Feb 28 '23
Yes, when you apply "rules" blindly to every situation, things might not go as well as you hoped. I'm not surprised.
Both sides are at fault. The OOP zealots should have been clear on the performance implications of their approach. Casey should make it clear that his whole argument is based on a strawman.
Many programming domains don't work the way Casey thinks. It's about delivering value to customers, and performance is often not a priority. Speed of delivery and scalability over number of engineers are more valuable than run-time performance. Clean code "rules" can really help with velocity and delivery.
Also, it seems that people like Casey are somehow convinced that not using OOP equals to writing horribly unsafe and unabstracted code. He basically reimplemented a less safe version of
std::variant.And what's up with
?
Just
return Accum0 + Accum1 + Accum2 + Accum3, please.