5 ms·

I'm not fighting, only offering an opinion. We simply disagree at a fundamental level. My first and main point is that 80% of software developers, the silent m

by fleddr 4y ago

I'm not fighting, only offering an opinion. We simply disagree at a fundamental level. My first and main point is that 80% of software developers, the silent majority of so-called "bread programmers", do not grasp these concepts. So even if the concept is great, it doesn't matter. Second, and this is purely based on experience, I do not subscribe to the idea that your envisioned way of writing a new business feature is very realistic or useful. It leads to dependency hell, difficult to understand code, which is difficult to debug. I don't even subscribe to the idea (anymore) that if you're asked to implement a business feature, that it is implied that you should write it as if it can be torn apart and used for some imagined other feature. Nobody asked for that, we just made that up. One can say that I've become a DRY infidel. I don't expect you to agree, very few would agree. Yet I've arrived here for a reason: 20 years of headaches looking at "best practice" codebases.

girvo 4y ago
> My first and main point is that 80% of software developers, the silent majority of so-called "bread programmers", do not grasp these concepts. So even if the concept is great, it doesn't matter. Right… but is that not the point of these articles? To teach those programmers these concepts so they can get the benefits the GP commenter is talking about? Your comment there seems to presuppose that they can never learn, unless I’m misunderstanding!
john_the_writer 4y ago
I too have become a DRY infidel. You are not alone, and I don't think few would agree. There is nothing I love more when editing a feature than having 10 files open. :) Or having to later "de-nomalise" previously DRY work because feature X doesn't need what feature Y now does, but they share code, so now I've got to dance.
hnfong 4y ago
> very few would agree I, for one, would agree. IMHO, DRY is only useful when the underlying problem structure has a fundamental overlap with an existing problem. Incidental overlaps should be kept separate. That's where the premature abstraction problem comes from. Often in times of changing requirements, you can't predict where things will lead to. I suspect it's something to do with how OOP is taught. Universities start with abstract concepts and apriori principles (eg. encapsulation, polymorphism, etc.). So juniors fresh out of school tend to feel compelled to make up abstractions to be a "good citizen" so to speak. OTOH I actually started by encountering issues with duplicate code and repeated patterns (which was a problem mainly because I had to copy and paste and retype too much code), and only afterwards I learned about how OOP techniques could help solve these problems. For me personally they were just practical tools to solve practical problems, instead of a moral imperative. I happily write very specific code to do specific things instead of pretending there's some apriori abstraction waiting to be discovered. IMHO there's a humility in admitting that there's more than one way to look at (i.e. perceive in abstract manner) things.

by fleddr 4y ago

girvo 4y ago

> My first and main point is that 80% of software developers, the silent majority of so-called "bread programmers", do not grasp these concepts. So even if the concept is great, it doesn't matter. Right… but is that not the point of these articles? To teach those programmers these concepts so they can get the benefits the GP commenter is talking about? Your comment there seems to presuppose that they can never learn, unless I’m misunderstanding!

john_the_writer 4y ago

I too have become a DRY infidel. You are not alone, and I don't think few would agree. There is nothing I love more when editing a feature than having 10 files open. :) Or having to later "de-nomalise" previously DRY work because feature X doesn't need what feature Y now does, but they share code, so now I've got to dance.

hnfong 4y ago

> very few would agree I, for one, would agree. IMHO, DRY is only useful when the underlying problem structure has a fundamental overlap with an existing problem. Incidental overlaps should be kept separate. That's where the premature abstraction problem comes from. Often in times of changing requirements, you can't predict where things will lead to. I suspect it's something to do with how OOP is taught. Universities start with abstract concepts and apriori principles (eg. encapsulation, polymorphism, etc.). So juniors fresh out of school tend to feel compelled to make up abstractions to be a "good citizen" so to speak. OTOH I actually started by encountering issues with duplicate code and repeated patterns (which was a problem mainly because I had to copy and paste and retype too much code), and only afterwards I learned about how OOP techniques could help solve these problems. For me personally they were just practical tools to solve practical problems, instead of a moral imperative. I happily write very specific code to do specific things instead of pretending there's some apriori abstraction waiting to be discovered. IMHO there's a humility in admitting that there's more than one way to look at (i.e. perceive in abstract manner) things.