Let me tell a horror story about what is definitely bad modularity: something that happened in the old PHP app.
(I might pick on PHP a lot, but that's just because it is the language I have the most professional experience in so I've seen a lot of its horrors first hand. That, and it is a godawful language!) So I had to add a function to one of the project's includes to enable new functionality. I didn't even get very far into it before a mysterious error came up across the site: PHP Fatal error: Cannot redeclare bar_foo() (previously declared in my file) in completely unrelated file on line x. WTF. I coincidentally picked the same name for my function as my predecessor did for another function a long time ago, in a file far, far away! And it broke things scattered throughout the program. C does this too, but at least there's a compile step to save you. The sad part: that's the best case scenario with PHP! If it hadn't broken the entire site, I might not have caught it so early and then there'd be a real mess on the one page that just happened to include both files at once, hidden, lurking... But hell, at least if you coincidentally pick the same name as your predecessor it doesn't *overwrites* one of your functions at runtime like some languages! I kid you not, some popular languages actually do that. It blows my mind. Anyway, that's bad modularity and a couple of bug prone behaviors coming from it. Using a strict naming convention with long, fully qualified names (like familyname_functionname convention) might be a good thing in those languages, to reduce the odds that two team members pick the same name and break code elsewhere in the app. In D, however, such things are not necessary. The compiler makes it Just Work or fail early and fail meaningfully in the exact place where there actually is a problem and nowhere else. Such problems cannot occur, so the logic that goes into protecting yourself in other languages don't necessarily apply to D.
