6 ms·

1. Watching the tech community over a really long time, please guys, don't swing violently from "A is all good!" to "A is all bad!" It was good for something, e

1. Watching the tech community over a really long time, please guys, don't swing violently from "A is all good!" to "A is all bad!" It was good for something, else so many people wouldn't have successfully used it for so long. Work more on discrimination functions and less on hyperbole please. Future generations will thank you for it. 2. "...coupled with the way most developers conflate subtypes with subclasses..." Speaking as somebody who both likes SOLID and could write this essay/present the deck, I think there's a lot of confusion to go around. There are a lot of guys coding classes using rules better suited for types. There are a lot of guys applying OO paradigms to functional code and vice-versa. In general, whenever we swing from one side to the other on topics, it's a matter of definitions. There is no such thing as "code". There's "thinking/reasoning about code" and there's coding. You can't take the human element out and reason abstractly about the end product. Whatever the end product is, it's a result of one/many humans pounding away on keyboards to get there. 3. My opinion, for what it's worth: as OO took off, we had to come up with heuristics as to how to think about grouping code into classes, and do it in such a way that others might reasonably get to the same place ... or at least be able to look at your code and reason about how or why you did it. That's SOLID and the rest of it. Now we're seeing the revenge of the FP guys, and stuff like SOLID looks completely whack to them, as it should. It's a different way of thinking about and solving problems. ADD: Trying to figure out who's right and who's wrong is a (philosophical) nonsense question. It's like asking "which smell is plaid?" Whatever answer you get is neither going to provide you with any information or help you do anything useful in the future. (Shameless plug: Just submitted an essay I wrote last week that directly addresses reasoning about types in a large app)

cghendrix 6y ago
+1 on the hyperboles. You see so many articles with titles like “Never use a singleton unless you want to lose your marriage like me”
- deleted 6y ago
  [deleted]
elric 6y ago
> don't swing violently from "A is all good!" to "A is all bad!" Indeed. This clickbaity style of laying out arguments is not terribly constructive. Software is not black/white. It's entirely grey. And there's a lot of room for contextual nuance everywhere. Principles like SOLID (and DRY, and YAGNI, etc) are principles. They are not laws. Principles are guidelines which can help you make solid (heh heh) decisions. They are subject to context and judgement. If good software design were as easy as memorizing a couple of acronyms, we'd all be out of a job. But it's not. It takes practice and experience. Writers and academics can make things easier by presenting accumulated experience in principles and guidelines, but there are no silver bullets. It's unfair and pointless to expect SOLID (or anything else) to apply in any and all cases.
- dvlsg 6y ago
  > It's unfair and pointless to expect SOLID (or anything else) to apply in any and all cases. I think that's a big part of the problem, and how we end up with articles like this. A lot of developers do expect SOLID to apply to every case, and I've seen fine code get rejected in reviews because it wasn't SOLID enough.
  - no-s 6y ago
    >>A lot of developers do expect SOLID to apply to every case, and I've seen fine code get rejected in reviews because it wasn't SOLID enough. Prescriptive principles without informed discretion. That is the problem, and it's not just software. "A foolish consistency is the hobgoblin of little minds." It's terrifying how easily a reasoned and seeming sensible polemic may be interpreted into a foolish oppression, even by otherwise rational folk...
  - deleted 6y ago
    [deleted]
- cratermoon 6y ago
  > Software is not black/white. It's entirely grey entirely? There aren't parts that are black/white? That's seems a bit black/white.
youerbt 6y ago
Agree. Programming is just too vast of a field to have universal principles. It is also changing to fast for most principles to remain relevant. We just like mental shortcuts. We ask should we use SOLID/whatever, instead of asking why was SOLID/whatever used and does this why apply to us.
lostcolony 6y ago
"It was good for something" The post does seek out where the SOLID principles came from. And it's not really debunking them; just saying they're not absolutes. Which, yes, the title is click-baity, but I've certainly found people who treated them as absolutes, or tried to talk about code from SOLID perspective, and I've certainly never found that useful. In fact, I've not found -any "best practice" to ever be absolute in a generalizable sense, and it's never been useful rhetoric to bring them up in a design discussion because of that. In fact, they sometimes run counter to each other. "DRY would say we should combine these together" - "Yeah, but Single Responsibility; while the code is mostly the same, they fundamentally are dealing with different things in different contexts". Learn the heuristics, then deal with the subjective realities each project brings; anyone who tries to treat a given codebase as having an objectively correct approach, rather than a nuanced and subjective series of tradeoffs, is not someone worth talking or listening to.
- dllthomas 6y ago
  > "DRY would say we should combine these together" - "Yeah, but Single Responsibility; while the code is mostly the same, they fundamentally are dealing with different things in different contexts" As originally coined, DRY speaks of ensuring every piece of knowledge is encoded once. If pieces of code are "dealing with different things" then those are two pieces of knowledge, and DRY (per that formulation) does not recommend combining them. I agree that there is a prevalent notion of DRY that is more syntactic, but I find that version substantially less useful and so I try (as here) to push back on it. Rather than improving code, it's compressing it; I've joked that we should call it "Huffman coding" when someone tries to collapse unrelated things in ways that will be unmaintainable. Note that it's not just that syntactic DRY sometimes goes to far - it also misses opportunities where the original DRY would recommend finding ways to collapse things: if I'm saying "there's a button here" in my HTML and in my JS and in my CSS, then I'm saying the same thing in three places (even though they look nothing alike) and maybe I should find a way to consolidate. There are, of course, still tradeoffs - maybe the technology to unify the description isn't available, maybe deepening my tech stack makes things less inspectable, &c.
  - 6y ago
spaetzleesser 6y ago
In politics and in tech consulting there is a lot of money and fame to be made by going to the extremes and not allowing the middle ground. I just wish people wouldn't constantly fall for this, be it in politics or in tech. Wait another 10-20 years and FP will suffer the same fate.
chrisseaton 6y ago
> It was good for something, else so many people wouldn't have successfully used it for so long. I don't know - some ideas just turn out to be completely mistaken and any success while using them to be actually down to something else entirely.

cghendrix 6y ago

+1 on the hyperboles. You see so many articles with titles like “Never use a singleton unless you want to lose your marriage like me”

deleted 6y ago
[deleted]

elric 6y ago

> don't swing violently from "A is all good!" to "A is all bad!" Indeed. This clickbaity style of laying out arguments is not terribly constructive. Software is not black/white. It's entirely grey. And there's a lot of room for contextual nuance everywhere. Principles like SOLID (and DRY, and YAGNI, etc) are principles. They are not laws. Principles are guidelines which can help you make solid (heh heh) decisions. They are subject to context and judgement. If good software design were as easy as memorizing a couple of acronyms, we'd all be out of a job. But it's not. It takes practice and experience. Writers and academics can make things easier by presenting accumulated experience in principles and guidelines, but there are no silver bullets. It's unfair and pointless to expect SOLID (or anything else) to apply in any and all cases.

dvlsg 6y ago
> It's unfair and pointless to expect SOLID (or anything else) to apply in any and all cases. I think that's a big part of the problem, and how we end up with articles like this. A lot of developers do expect SOLID to apply to every case, and I've seen fine code get rejected in reviews because it wasn't SOLID enough.
- no-s 6y ago
  >>A lot of developers do expect SOLID to apply to every case, and I've seen fine code get rejected in reviews because it wasn't SOLID enough. Prescriptive principles without informed discretion. That is the problem, and it's not just software. "A foolish consistency is the hobgoblin of little minds." It's terrifying how easily a reasoned and seeming sensible polemic may be interpreted into a foolish oppression, even by otherwise rational folk...
- deleted 6y ago
  [deleted]
cratermoon 6y ago
> Software is not black/white. It's entirely grey entirely? There aren't parts that are black/white? That's seems a bit black/white.

youerbt 6y ago

Agree. Programming is just too vast of a field to have universal principles. It is also changing to fast for most principles to remain relevant. We just like mental shortcuts. We ask should we use SOLID/whatever, instead of asking why was SOLID/whatever used and does this why apply to us.

lostcolony 6y ago

"It was good for something" The post does seek out where the SOLID principles came from. And it's not really debunking them; just saying they're not absolutes. Which, yes, the title is click-baity, but I've certainly found people who treated them as absolutes, or tried to talk about code from SOLID perspective, and I've certainly never found that useful. In fact, I've not found -any "best practice" to ever be absolute in a generalizable sense, and it's never been useful rhetoric to bring them up in a design discussion because of that. In fact, they sometimes run counter to each other. "DRY would say we should combine these together" - "Yeah, but Single Responsibility; while the code is mostly the same, they fundamentally are dealing with different things in different contexts". Learn the heuristics, then deal with the subjective realities each project brings; anyone who tries to treat a given codebase as having an objectively correct approach, rather than a nuanced and subjective series of tradeoffs, is not someone worth talking or listening to.

dllthomas 6y ago
> "DRY would say we should combine these together" - "Yeah, but Single Responsibility; while the code is mostly the same, they fundamentally are dealing with different things in different contexts" As originally coined, DRY speaks of ensuring every piece of knowledge is encoded once. If pieces of code are "dealing with different things" then those are two pieces of knowledge, and DRY (per that formulation) does not recommend combining them. I agree that there is a prevalent notion of DRY that is more syntactic, but I find that version substantially less useful and so I try (as here) to push back on it. Rather than improving code, it's compressing it; I've joked that we should call it "Huffman coding" when someone tries to collapse unrelated things in ways that will be unmaintainable. Note that it's not just that syntactic DRY sometimes goes to far - it also misses opportunities where the original DRY would recommend finding ways to collapse things: if I'm saying "there's a button here" in my HTML and in my JS and in my CSS, then I'm saying the same thing in three places (even though they look nothing alike) and maybe I should find a way to consolidate. There are, of course, still tradeoffs - maybe the technology to unify the description isn't available, maybe deepening my tech stack makes things less inspectable, &c.
- 6y ago

spaetzleesser 6y ago

In politics and in tech consulting there is a lot of money and fame to be made by going to the extremes and not allowing the middle ground. I just wish people wouldn't constantly fall for this, be it in politics or in tech. Wait another 10-20 years and FP will suffer the same fate.

chrisseaton 6y ago

> It was good for something, else so many people wouldn't have successfully used it for so long. I don't know - some ideas just turn out to be completely mistaken and any success while using them to be actually down to something else entirely.