this post was submitted on 04 Aug 2024
21 points (100.0% liked)

Programming

17443 readers
203 users here now

Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!

Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.

Hope you enjoy the instance!

Rules

Rules

  • Follow the programming.dev instance rules
  • Keep content related to programming in some way
  • If you're posting long videos try to add in some form of tldr for those who don't want to watch videos

Wormhole

Follow the wormhole through a path of communities !webdev@programming.dev



founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[โ€“] key@lemmy.keychat.org 3 points 3 months ago (1 children)

That makes no sense. If you join b' and b'' into b then the external interface of b is the union of the external interfaces of b' and b''. The risk of conflicts between those two interfaces is minimal in the situation they described so no need for namespacing.

I expected the argument to be based on total effort to split then join the internal code compared to the context switching cost of splitting and then splitting again (with an appeal to agile vs waterfall). But this argument feels like they were either dealing with a language/stack with a broken module system that lacks an explicit separation of internal vs exposed or were just joining things strangely.

Expressing a general rule based solely on a specific situation is a disservice (irony intended).

[โ€“] Kache@lemm.ee 2 points 3 months ago* (last edited 3 months ago)

I agree with the author overall, and I think it can be more straightforwardly stated. IMO it's the idea that wrong abstractions are even worse than other ills like duplication or god classes/modules. It's also reminiscent of "modules should be deep".