4 ms·
Another "academic level" demonstration that doesn't work in practice. It's so simple to say "look how awesome this approach is" on a 50 line program, "just use
by OneGuy123 6y ago
Another "academic level" demonstration that doesn't work in practice.
It's so simple to say "look how awesome this approach is" on a 50 line program, "just use pure functions everywhere".
In real life things get very complex because there are 200 working parts interconnected. And not because "it's bad design". But because that is the requirement.
Soon you get pure functions with tons of parameters or parameters that are complicated classes/structs themselves because the work that needs to be performed is very complicated.
Then you get to the issue of "this function gets the entire class as the input param but it only access a small amount of members in that class".
"Yo bro just split the class into multiple smaller ones".
Sorry bro can't do, those separate classes will need to be acccessed as a whole sooner or later in another part.
People act as if there will ever be a thing such as a "perfect programming design". There won't because things will always evolve & change. Real life programs are simply too complex.
- danuker 6y agoSure, real life programs are very complex. But that doesn't stop you from testing and refactoring whatever local point you need to touch, so that you can get the job done easier. My hunch is that moving pure-functions and pure-objects out of the spaghetti will gradually eat away at the spaghetti.
- andrewjl 6y ago> In real life things get very complex because there are 200 working parts interconnected. And not because "it's bad design". But because that is the requirement. These sorts of things are always better discussed in terms of specific cases instead of generalities, but I think one of the key parts of good software engineering is factoring the requirements into the simplest design possible. And even when time or other considerations prohibit creating an extensive design ahead of time, practicing a few well-chosen heuristics like "use composition", "keep functions and methods short", "use clearly defined and consistent terminology in your abstractions" can go a long way to making code less unruly and easier and cheaper to refactor down the road.