3 ms·

Hmm... it's not quite addressed here (they address generality as the size of the scope of the solution), but I have a slightly different take: I love generaliz

Hmm... it's not quite addressed here (they address generality as the size of the scope of the solution), but I have a slightly different take: I love generalizing things. If I need to remove a couple of prefixes from a list of strings, I don't hard code those strings in a function. I make a general string prefix removal and pass those prefixes in. I find that I write more correct and stable code by switching from special cased code to generalized code. One can take this to extremes of course. I think the article is against generalizing solutions that shoehorn things together that normally don't go together. E.g. hal for handling disparate hardware abstractions. Its a forced abstraction to gain certain things. I guess it's abstract vs generalize. Generalize is good, if it doesn't introduce abstractions... that's the thought process I just had anyway.

adrianratnapala 8y ago
Suppose I already had two function functions like: def strip_prefix(prefix, str): ... def name_from_fooid(fooid): return strip_prefix("foo", id) Now is it better to call `name_from_fooid` or to call `strip_prefix` directly? It depends on the high-level semantics we are trying to express. But assuming we really are extracting a Name from a FooId, then the former is probably better. But then if you want a name_from_fooid function, it's just an implementation detail that you happen to implement it on top of a strip_prefix utility.