I tend to distinguish between two uses of the word "generic": code can be "generic" by providing hooks/parameters to override every decision, which leads to complexity and bloat, as you mention.
On the other hand, code can also be "generic" by avoiding decisions, parameters and special-cases. An example of this is Lisp's use of cons cells to represent data: regardless of the contents, and what it's meant to represent, we can always use `car` and `cdr`; they're "generic".
Compare this to a typical OO approach, like a `Customer` object with a `name` and `dateOfBirth`: we can't access those fields without either writing those particular strings (`name` and `dateOfBirth`) in our code; or use some complicated reflection approach to look up the names then use those to look up the data.
Of course, it depends completely on the context whether to use special-purpose datastructures (e.g. custom classes to model a domain) or generic ones (pairs, lists, maps, etc.), but generic doesn't always imply bloat and complexity.
Except using only car and cdr does imply complexity—linear complexity; instead of being a constant-time operation, access to an arbitrary element in a list is O(n) with respect to the length of the list.
Ah yes, I didn't mean "complexity" as "computational complexity"; I use is but rather as how sprawling and difficult to understand the code must be (we could regard this formally using something like Kolmogorov complexity, but I meant it informally).
One advantage of "specific" (as opposed to "generic") code, like explicit constructor/destructor pairs (e.g. named properties and accessors), is that by forcing client code to choose one particular, specific accessor, we have a lot more static information to use for optimisation; i.e. we've encapsulated the implementation behind an opaque interface, which we're free to implement in whichever way makes most efficient use of the resources we care about.
On the other hand, code can also be "generic" by avoiding decisions, parameters and special-cases. An example of this is Lisp's use of cons cells to represent data: regardless of the contents, and what it's meant to represent, we can always use `car` and `cdr`; they're "generic".
Compare this to a typical OO approach, like a `Customer` object with a `name` and `dateOfBirth`: we can't access those fields without either writing those particular strings (`name` and `dateOfBirth`) in our code; or use some complicated reflection approach to look up the names then use those to look up the data.
Of course, it depends completely on the context whether to use special-purpose datastructures (e.g. custom classes to model a domain) or generic ones (pairs, lists, maps, etc.), but generic doesn't always imply bloat and complexity.