This seems, I could have missed something, more to be about the loose coupling in Object Land. Not about loose coupling in software land.
Some sentences seems more or less taken out of context from any Haskell book (pure vs IO).
Some seem, again, taken out of context from the OTP Design principle.
More annoying is the fact that there is a code example of How Not Todo It but nowhere any How Todo it. I would have liked if the article had some indication on what direction the Author thought on some way to do loose coupling.
Yeah, to me this article basically sounds like some guy heard you shouldn't tightly couple your software, and wrote a blog post about it to sound smart. That may not be the case, but giving an example of how not to do it, and then NOT giving an example of how to do it just seems silly to me.
I agree. To say loosely coupled software is better is just restating the Law of Demeter. The tricky part is figuring out where the interfaces should actually go. Every abstraction comes with overhead, so it only makes sense if it eliminates some emergent complexity from the whole system. Now I guess given the choice between the copy and paste code monkey and the architecture astronaut I'd choose the latter, but I'm pretty sure I'd rather work with someone who is smart and gets things done.
I think it's all too easy to look at old code with today's perspective, and assume the original programmers were idiots without considering what the code base looked like at the time or what were the requirements and time constraints given to them.
More annoying is the fact that there is a code example of How Not Todo It but nowhere any How Todo it. I would have liked if the article had some indication on what direction the Author thought on some way to do loose coupling.