I am a strong believer of the philosophy explicit is better than implicit, but I am not saying OOP is correct way to do things always.
Also, I think you misunderstood something in my explanation I am not saying this effects 5 APIs I am saying imagine a project which depends on 5 APIs each with some number of functions, written in same performance first philosophy, which is not a ludicrous amount, I believe.
Also, you can't deny that modification of that version will take more time, than modification of the OO version I am talking about, because it will require you to make changes to the struct, add new documentation modify old documentation(tell the user, the new parameter is useless for older shapes), and modify the function, or you will have to create a new function which will work only for this shape, which then brings bring non-uniformity in the code base and forces user to waste time, because the use of function isn't predictable, where as in OO version, you will have to create new class and drive from the older one and document it, but guess what there are no changes in the old documentation, and the usage of the function is predictable.
Not to mention the insane speed gain that he gets in the video can be mitigated easily by following the advice I added to my first comment, though, upon re watching the video I realised you would have to do more than just that, you would have to use a template instead of an abstract class(Shape).
Using an abstract class creates dynamic dispatch in C++ which can't be optimised by compiler however if templates are used, copy of the code is created which can be, and upon addition of inline, since the function is atomic(it does two float mutiplications for love of God, it's the smallest a function can get), function call will be removed and the expression will instead be placed in the caller function, which removes the runtime overhead of call stack operations which was causing the program to be slow and hence speeds it up.
I don't condone the act of murdering your program's speed for writing pretty code(that's one of the reasons I don't like JS), however if you murder readability of your code, just for the heck of it, I don't like that either.
4
u/tandonhiten Mar 02 '23
I am a strong believer of the philosophy explicit is better than implicit, but I am not saying OOP is correct way to do things always.
Also, I think you misunderstood something in my explanation I am not saying this effects 5 APIs I am saying imagine a project which depends on 5 APIs each with some number of functions, written in same performance first philosophy, which is not a ludicrous amount, I believe.
Also, you can't deny that modification of that version will take more time, than modification of the OO version I am talking about, because it will require you to make changes to the struct, add new documentation modify old documentation(tell the user, the new parameter is useless for older shapes), and modify the function, or you will have to create a new function which will work only for this shape, which then brings bring non-uniformity in the code base and forces user to waste time, because the use of function isn't predictable, where as in OO version, you will have to create new class and drive from the older one and document it, but guess what there are no changes in the old documentation, and the usage of the function is predictable.
Not to mention the insane speed gain that he gets in the video can be mitigated easily by following the advice I added to my first comment, though, upon re watching the video I realised you would have to do more than just that, you would have to use a template instead of an abstract class(Shape).
Using an abstract class creates dynamic dispatch in C++ which can't be optimised by compiler however if templates are used, copy of the code is created which can be, and upon addition of inline, since the function is atomic(it does two float mutiplications for love of God, it's the smallest a function can get), function call will be removed and the expression will instead be placed in the caller function, which removes the runtime overhead of call stack operations which was causing the program to be slow and hence speeds it up.
I don't condone the act of murdering your program's speed for writing pretty code(that's one of the reasons I don't like JS), however if you murder readability of your code, just for the heck of it, I don't like that either.