3 ms·
Don't waste your time. These are neither puzzles nor convincing. What they do is exploit the ambiguity of the word "dependence" to provide illustrations vaguely
by jvanderbot 4y ago
Don't waste your time. These are neither puzzles nor convincing. What they do is exploit the ambiguity of the word "dependence" to provide illustrations vaguely from tech you'd understand that somehow tease out the various context-dependent definitions of "dependence".
"If a depends on b, but falls back to c if b isn't available, does a really depend on b?"
Come on, we're not context-free parsers. Ambiguity and subtlety may be an annoying part of communication but they aren't all that important to focus on like this.
- morelisp 4y agoA lot of programmers today do read some bad summary of SOLID or GoF or whatever and then get confused or angry when things don't follow the models they're aware of. (It's not a recent phenomenon, you can see it with MVC 15-20 years ago too, but a lesser percentage of programmers today have the fundamental grounding to break out of it.) In particular I see new programmers struggle with the "shared format" puzzle (they want an answer, and there isn't one), and especially Java developers today are deep on the wrong side of the "inversion puzzle" continually mistaking DI for loose coupling and sound architecture. Does this article help? I'm not really sure. But does elevating shallow mostly-wrong lessons like Clean Code hurt, and we need to address that somehow? Absolutely.
- IshKebab 4y agoYes exactly. There are various ways in which something can depend on something else. This article just conflates the different types of dependency to make confusing questions. All this did is convince me that I understand dependency better than the author!