A lot of Uncle Bob's advice come from a time and a place where they actually had merit. There is a sort of enterprisey Java code that was very common in the '90s. OOP and Gang of Four was incredibly trendy, but few people were actually all that good at it. So now your code had a AbstractFactoryFacadeDelegatorImplBuilderVisitorVisitor. Methods were often extremely long, hundreds of lines. The code was complex in a lot of ways, lots of static instances being accessed from every which way.
In this context, Uncle Bob's style was compelling, it felt like a breath of fresh air. His opinionated attitude was also compelling. In general, associating a term like 'clean' to your methodology seems to be a good zealot recruitment strategy. 'Pure functions' is similarly brilliant marketing.
That said, a lot of his supposed solutions actually cause problems of their own if you let the pendulum swing too far. It creates its own kind of complexity. Books like these also tend to sort of get their own momentum, if you look back you see a lot of big names praising them. Surely they must be good, right? Well they were. Clean Code made sense when it was published. It's for the most part not good advice today.
Ironically, on mobile at least, applying Uncle Bob's ideals into the VIPER framework creates proliferation of classes, interfaces, and functions that are often as byzantine and names as unwieldy as stereotypical J2EE spaghetti code.
I'm curious why you think clean code is for the most part not good advice today. I read the book recently. What is different today compared to in 2008?
You can easily end up with another sort of complexity, where the code is difficult to reason about because it is so decoupled and the methods are so short (but the call stack very long) and modules so small (but many). You can end up with unnecessary code that's difficult to spot because the logic is so spread out that the big picture is clouded.
Because lots of small functions increase the system complexity by creating interdependencies. You also don't have context in each function to understand the big picture and very small functions can be meaningless on its own. You have to jump through many functions just to figure out what is being done.
Code is a non-linear medium, depending on the path one takes thought the graph and the scale one operates at clean might mean a very different thing. Take a long look at the history of ideas, it might be obvious looking back that thing should be the way they are, but no one just knows them as if they are a prophet. Even if there are sign of something being ugly or a hack this does not give any guidance as what direction to take next.
I haven't seen anything much better than SOLID from Clean *Architecture in terms of organizing large projects into lots of small discrete interfaces. I guess globally declared pure functions are being pushed a lot today, but I find this approach organizationally wanting, particularly in promoting tight coupling (with all its drawbacks).
*Edit: Updated: I had forgotten this was not from "Clean Code".
I meant "globally declared" in contrast to instance-oriented (i.e. methods) rather than whether or not a function exists within a namespace, which is what I think you're implying.
I often wonder what would currently be a way to work in a more enterprisey environment and actually make stuff a little bit more fun and not all "abstract factories" etc. I'm talking TypeScript/C#/.NET Core type of stuff, maybe with Vue. What's the "new Clean Code"? Might just learn Go next or something.
I don't think it's sensible to liken Pure Functions with "clean code". The former, while no panacea, is strictly defined in a way that the latter could never hope to be.
In this context, Uncle Bob's style was compelling, it felt like a breath of fresh air. His opinionated attitude was also compelling. In general, associating a term like 'clean' to your methodology seems to be a good zealot recruitment strategy. 'Pure functions' is similarly brilliant marketing.
That said, a lot of his supposed solutions actually cause problems of their own if you let the pendulum swing too far. It creates its own kind of complexity. Books like these also tend to sort of get their own momentum, if you look back you see a lot of big names praising them. Surely they must be good, right? Well they were. Clean Code made sense when it was published. It's for the most part not good advice today.