Clay language

[Adam D. Ruppe]

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.