I haven't seen much of this myself, although I can imagine it happening.
From what I've seen, bloated code tends to be code that is copied (either literally or in style) from somewhere else, which doesn't fit the task at hand. So you have functions that have lots of options, but only ever get called once with one set of parameters. The fix is to rewrite everything so that the abstractions are taylored to the task at hand.
What you are describing is a kind of excessive elegance. But this is fairly independent of the problem I described (and the article is describing).
I'll also say that there is a limit to bloat, and LOC is often a good guide to functionality. E.g. if I'm interesting in re-implementing something, I'll first look at the weight of the code. If I thought something would be a half hour job and the code is 5000 lines, I'll probably re-evaluate. Sometimes I've pondered reimplementing certain libraries, only to find they weigh in at a million lines of code.
From what I've seen, bloated code tends to be code that is copied (either literally or in style) from somewhere else, which doesn't fit the task at hand. So you have functions that have lots of options, but only ever get called once with one set of parameters. The fix is to rewrite everything so that the abstractions are taylored to the task at hand.
What you are describing is a kind of excessive elegance. But this is fairly independent of the problem I described (and the article is describing).
I'll also say that there is a limit to bloat, and LOC is often a good guide to functionality. E.g. if I'm interesting in re-implementing something, I'll first look at the weight of the code. If I thought something would be a half hour job and the code is 5000 lines, I'll probably re-evaluate. Sometimes I've pondered reimplementing certain libraries, only to find they weigh in at a million lines of code.