> If this is such a great approach, why are some people moving away from it?
My answer is because forcing a type hierarchy, and having to declare where every type belongs in it, is a PITA. Duck typing is far more flexible and good enough imo
sure, but if you want to use virtual methods, you have to declare ahead of time what types you implement, instead of the compiler looking to see if your type satisfies an interface. Its these little things that make the DX difference
Merging data and behaviour into a single unit (the core idea behind OOP) is literally impossible to do in practice.
Just imagine "sending a message to an int to send a copy of itself to a HTTP server" or "send a message to an array of colors to raytrace itself" or "send a message to a file asking it to sort itself and render itself in 3D".
The problem is that everything will literally end up depending on everything. A perfect implementation of the ultimate spaghetti code.
In contrast, split the code into Data, Dumper, Reader, Writer, Verifier, Renderer, Editor etc. modules (or classes used as modules) and the code is simple to understand with zero circular dependencies. And it works for any language including non-OO languages.
6 comments
[ 6.0 ms ] story [ 72.3 ms ] threadMy answer is because forcing a type hierarchy, and having to declare where every type belongs in it, is a PITA. Duck typing is far more flexible and good enough imo
I happily work in typed languages and nobody is forcing me to create any type hierarchies.
Just imagine "sending a message to an int to send a copy of itself to a HTTP server" or "send a message to an array of colors to raytrace itself" or "send a message to a file asking it to sort itself and render itself in 3D".
The problem is that everything will literally end up depending on everything. A perfect implementation of the ultimate spaghetti code.
In contrast, split the code into Data, Dumper, Reader, Writer, Verifier, Renderer, Editor etc. modules (or classes used as modules) and the code is simple to understand with zero circular dependencies. And it works for any language including non-OO languages.
They clearly do support OOP, the only difference is that it isn't the traditional class based OOP from Smalltalk and Java.
I have coded the Peter Shirley's raytracing tutorial using Rust with exactly the same OOP architecture as the tutorial, based on traits.