4 ms·
I'm not sure what you mean, but with abstraction it's the opposite of what I said. Premature abstraction really is very very bad (I won't go so far as to say i
by hsn915 5y ago
I'm not sure what you mean, but with abstraction it's the opposite of what I said.
Premature abstraction really is very very bad (I won't go so far as to say it's the root of all evil).
The higher level the abstraction, the worse it is.
Unless it's born from experience writing the same kind of program many times. In which case it's not "premature".
"micro abstractions" are actually fine. You notice a recurring pattern in the code so you "abstract" it away into a function.
- taeric 5y agoMy guess is we are talking of different things when envisioning micro abstractions. I have in mind the projects that went from a handful of data structures and functions to dozens of each. Typically in the vein of abstracting away whatever immediate problem was faced in the code. Have a workflow? Make a workflow abstraction that can run any work. Have code that needs to retry? Make a retry facility that can retry for any reason. Than make a grammar to specify what backoff should be used. While doing those, realize you want a rules engine to determine what work and what backoff to use. Then, put in a sat solver. To determine if a plan can be done. ... None of these are really bad things, in and off themselves. Odds are high they would all be poorly done, or themselves a giant undertaking.