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 I think you do it usually well after N=4? Like, when the effort of dealing with N individual items becomes (substantially) larger than the effort required to build a generalised system (accounting for the risk of that system being buggy is also sensible).
@mcc Counterpoint: it is a hell if a lot easier to go from “one thing or nothing at all” to “a collection of zero or more of a thing” than “maybe zero, one, or two of a thing”
@mcc We create N "State Machines" to get around N.
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.
@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 this I agree with. I generally am cautious about early abstractions because I've worked on a lot of codebases with programmers who were *heavily* invested into them, and pushed for them to the point where they became leaky and fragile. I think my biases tend to lead towards more readable and self documenting code.
HOWEVER, they indisputably make me spend more time refactoring and make some of my refactors more involved.
@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 I often get the abstraction slightly wrong if I don't wait for 4 so I can see what aspects vary.