Comment by ajuc | Hacker News Reader

Comment by ajuc | Hacker News Reader

Parent Full thread

There's 2 approaches to programming:

- 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.

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

In my experience, in predetermined directions is almost never the direction the piece of code needs to evolve. Maybe I'm bad at reasoning about the future changes, but I'd guess that most people are utterly bad about this.

This makes OCP more like an ideal to be aspired to, and beaten with when one inevitably fails.

If you look at it objectively. There's a very clear reason why OOP inevitably fails.

Maybe a better way to put it is that SOLID is an ideal that OOP aspires to be but fails.

Either way SOLID is a bad set of axiomatic design principles. It's sort of an arbitrary group of rule of thumb principles picked to spell out SOLID.

I look at it with the rubrik: KISS is for coding. SOLID is for system design.

There is overlap obviously but SOLID becomes even more important when you have N+2 systems that interoperate. KISS is one way to help ensure you have a SOLIDly designed system when you are coding it. But it helps to understand the principles in SOLID when you are designing a monolith or a set of microservices.

> But the best is just to understand everything that happens.

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

I disagree with Martin very much. Programs can be made easy to change without introducing complex OOP abstractions.

There is a simple rule that Martin fails to ever mention.

Use combinators as much as possible and segregate as much logic as possible from IO. That's it.

> There's 2 approaches to programming

Written like a programmer! And therein lies the bug. Unless SOLID is the negation of KISS, the world tends to have more than two options. How about DRY, for instance? Off by at least one.

I can see how SOLID and OOP seem to be related, but the principals of SOLID can (and IMO should) be applied to FP as well. In fact one of the clarifications in Uncle Bob’s letter hints at this, by expressing that substitution is about subtypes, not inheritance.

This is of course common in statically typed FP languages like Haskell (or FP approaches in statically types imperative languages like TypeScript, Swift, so on). But even in dynamic languages like Clojure, substitution of subtypes of a given interface is pervasive; I would even say it’s foundational to the language’s core concepts.

I’d even go further to say that FP languages and approaches are much more likely to guide developers toward SOLID naturally than imperative languages and approaches.

I feel that SOLID doesn't even work well with OOP. Overall it's just saying "be more modular" in a programming paradigm that's one of the least modular styles ever created.

Agreed, though I also feel that even OOP doesn’t work well in OOP.

Reply on news.ycombinator.com