I don't think that's what the blub paradox is. I think the parent comment is arguing the opposite. People who believe in the blub paradox are usually so smug and full of themselves that they don't pursue simple solutions.

The parent commenter is dismissing generics, and various other features, as something that "bogs people down" and makes them write worse code.

This is the essence of the blub paradox, thinking that people who use a feature are simply misusing it, after all in blub you don't have generics and things are fine. They're just making things more complicated than they need to be.

The blub programmer isn't necessarily smug, they just make excuses to dismiss more powerful language features that they are not sufficiently familiar with.

The problem with the blub argument is that it heavily relies on the existence of an undisputed power hierarchy among programming languages. Only s/he who is an expert in the most powerful language is in a position to pass judgement on all other languages.

I don't know how to resolve disputes over the relative power of programming languages on that basis. Are dynamic languages more or less powerful than static languages with advanced type systems? I don't know. What's the definition of power?

But I think what we can take from blub is that familiarity with one language or set of features is an insufficient basis for dismissing other, unfamiliar, languages or features.

Having used trait-based generics, I think that trying to piece together what's going on in typenum, the GAT stabilization process, https://hirrolot.github.io/posts/rust-is-hard-or-the-misery-..., num-traits, and variance and https://github.com/rust-lang/rust/issues/25860 is absolutely bogging me down. I feel (and observe as people try modeling contracts in traits) that trying to build code which plays well with open-ended type parameters is inherently more difficult than building a correct solution for a single type. Generally I'd prefer a more focused less generic solution which corresponds to a single function in the generated machine code (modulo inlining), except in cases where generics (over a small or open set of types) provide a clear benefit (collections are a clear example, IMO point-free .iter().map().sum() style is usually a regression in readability).

I'm not dismissing generics or object orientation or orthogonal addressing modes or 'a x 'a -> 'a functions. I am observing that there's a trap that a lot of people fall into, where they spend inordinate amounts of time making everything as generic as possible at the expense of time-to-market, and understandablity.

A good class or generic is hard to beat. Unfortunately the understanding of the details that make something a good class requires experience and experiments. Maybe I am talking about premature optimization, writ larger, or in design.

Same thing happens in the other direction too e.g. Rust coders trying to use Python without familiarity with dynamic scripting languages and dismisses the whole language as a footgun (despite Rust’s learning curve being harder, for instance).