this post was submitted on 11 Jun 2023
6 points (80.0% liked)

Programming

3347 readers
1 users here now

All things programming and coding related. Subcommunity of Technology.


This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

This just serves as another reminder that I need to finish reading SICP. But that said, I think this brings up some very interesting points. The example provided of DRY is focused on what is happening on a human/company level, while the abstraction barriers provided focus heavily on what is happening on a software level. This is a differentiation that I feel like is extremely important when programming robust, maintainable software. You cannot let non-software related terminology seep into what is fundamentally, well, software.

When you let non-software terminology work its way into software, the software has to start making assumptions. What is a C level employee? What bonuses do they require? Are these things subject to change? The list goes on. But if you approach the problem with software first and foremost, it is clear that all is happening is a variable bonus is added to an employees compensation. It is not this layers problem what that value is, nor is it this layers problem who is being compensated. That is all concerns for a DB layer (of some form) somewhere up the chain. All the financial layer cares about is applying the calculations.

So I don't feel like this is really a case against DRY, as much as it's a case against using non-software terminology and applying non-software assumptions to what is fundamentally, software. The arguments for maintaining independent layers is also important, but if you're thinking fully in terms of software operation, I feel you can more comfortably determine when layers can be interlinked.

[–] hackeryarn 1 points 1 year ago (1 children)

Yeah, this definitely went deeper. I was really tempted to change the title to be honest. The article started out of a frustration of a code base that was too DRY, and kind of grew into a more general how to create abstractions. The original title just stuck around.

[–] [email protected] 2 points 1 year ago

That absolutely makes sense, still thoroughly enjoyed the article!

Something else interesting to think on, is which terminology helps the average programmer more. If DRY causes habits to form around human/business terminology maybe it should be avoided in favor of abstraction layers! No idea what the answer is in this regard, fully possible theres no difference. But its an interesting thought experiment all the same.