Discussion
Here is an observation about writing software that may be so general as to be incomprehensible.
When you go from having one of a thing to having two of a thing, it is easier and possibly even more readable to just duplicate the thing instead of creating a generalized system that can handle N things.
Once you get to having three of a thing, it is better in all ways to simply have a generalized system that can handle N things.
But you don't *do* this when N reaches 3. You wait until N reaches 4
@mcc *Looks at spaghetti of ifdef's in our code as we kept adding new slightly different but kinda alike parts* Ok, who leaked our codebase?
So true.
That's why the good practice is to aisle anything you conceivable would repeat into a function and avoid global data like a plague.
If something makes sense in a loop, it is very likely to make sense in a function. Better now than tomorrow.
@mcc i'm in this post and i dont like it.
@mcc (there's a similar thing where you plan ahead and spend a bunch of time making a whole generalizable system for N things and it's super-awesome and neat, but then you never get past 2 things 🥲)
@daniel_gonzalez @peter Java frameworks simply formulate the problem as "Do not design N=1 systems, design for any-N generalization from the start". And that's how you get a FactoryFactoryFactory.
@whitequark In other news, I'm writing C# and getting completely fucked over by a decision James Gosling made back in 1991 that would have made sense at the time.
@whitequark A result of this is that my N just increased from 3 to 4, and I'm considering a refactor, and realizing it may be conceptually impossible to do better for "two parallel copypasted versions of the code, one of which handles exactly one case, and one of which handles the remaining N-1 cases". Because of James Gosling.
Now I want to emphasize I have only the utmost respect for James Gosling,
And doing the "make this work for a generalizable N things" refactor is easier when going directly from 1 to N than it is when you're going from 3 things to N things
@mcc not following this part. I've worked in a number of codebases that introduced N=1 abstractions early on that never really got expanded on, which become a big pain to maintain over time because its never clear exactly *what* you're trying to abstract without multiple concrete examples
@bmartin427 How about this: It's easier to conceptualize the abstraction when you have N=3, but it's easier to perform the code-level refactor when you have N=1, and that means no matter what the value of N is when you do the change someone will be unhappy
@mcc @bmartin427 I usually wait for N=3. I get unhappy with premature generalisation which results in large complex frameworks, holding up shipping for months, for something where ... in actual real life N never ends up getting to be more than 1.
@mcc oh I've heard this before. it is the "3 body problem" right
@mcc
Knowing *what* to generalize is an art.
If you generalize the wrong things too soon, you potentially make the generalizations that matter that much harder.
I won't go quite so far as to say, "premature generalization is the root of all evil," but it's up there.