Solid Relevance

- make it easy to extend (lets's call it SOLID in this context)

- make it easy to rewrite (let's call it KISS)

OO developers think that the first approach is The Only Way but both can be right, especially with high-level declarative languages and with tasks small enough (relative to the language expressive power).

SOLID makes it easier to modify programs (in predetermined directions) without understanding the whole.

KISS makes it easier to understand the whole program.

SOLID accumulates inefficiencies over time because people program with tunnel vision.

KISS takes longer to modify as it grows and eventually exceeds the capacity of human brain.

SOLID is mostly OO, KISS is mostly declarative.

If you want to feel safe changing code unit tests are nice, best practices and design patterns are nice too, good architecture is appreciated. But the best is just to understand everything that happens. Only then truly fearless programming is possible.

Once you go big enough you have to use SOLID but before that it's a cost.

Agreed, but unless you have written all the code yourself then this is hard to do. We have to be able to black-box things in order to manage complexity and make progress quickly. For this SOLID helps but if it is applied a too fine a granularity then it can make things worse (and I think micro testing things with mocks etc can cause this)

"There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. That, and duplication."

https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

That seems an extremely narrow view of modern programming. But then isn't this the same man who made the claim about there not being any new programming languages left to find?

Either way SOLID are arbitrary rules of thumb. Grouped together arbitrarily to spell out SOLID and kind of maybe sort of right depending on your opinion.

   1. SRP. Gather together the things that change for the same reasons. Separate things that change for different reasons.

You should also separate all things that "change" and all things that don't "change" and try to keep the things that "change" as small as possible.

All logical modules in your program should be separated as much as possible at the lowest layer, nothing should be grouped... and higher layers should be compositions of lower layers. But the basis of your program at the lowest layer: everything should be separated and nothing should be grouped.

In other words use combinators as MUCH as possible. OOP's promotion of methods that operate on shared mutable external scope actually prevent you from doing this.

  2. A Module should be open for extension but closed for modification.

So basically OOP practitioners can never modify an addOne method into addTwo. They can't even add an addTwo method into the object as that constitutes modification. What they can do is inject that entire object into another object. Either do this or use inheritance which OOP says is just bad.

Instead. Use combinators. You have an addOne combinator? Create an addTwo combinator. Recompose your combinators to form the higher level logic you wanted.

  3. A program that uses an interface must not be confused by an implementation of that interface.

  4. Keep interfaces small so that users don’t end up depending on things they don’t need.

If you defined the logic as I said above separating state changes away from combinators you'd have even smaller interfaces. One for changing state. And the other logic is stateless.

  5. Dependency inversion principle.

The better way to program is to have all your methods follow the dependency inversion principle. You can't do this if methods are modifying external scope shared by another method. Use combinators and by definition every sector of your program is following this principle not just "modules"