"Hmm, what are some examples of languages with design holes, or language mechanisms that help programmers manage design holes?"
Design holes are one part of a venn diagram: They're not a part of the program's design, and yet it's possible to encounter them in the program's behavior.
If a specification document says a behavior is unspecified--I think the C spec is notorious for this--then that's where you'll find a concrete example of a design hole. The design is concrete, and any implementation is concrete, so their difference is concrete.
Personally, I see design holes whenever I want to run my program without finishing it. The unfinished parts are gaping holes.
---
"Lower down you suggest that an error when adding a string to a non-string is a design hole."
It's an example of a design hole if the designer doesn't care what happens.
---
"Any language designer would say that at least some of his errors are 'designed in'."
I'd say if the language designer really wants people to avoid a certain design hole, they can put a little fence around it. The fence is part of the design, but on the other side, there's still a hole.
---
"Like I said privately, I disagree that exceptions are always discouraged."
Inasmuch as they're not discouraged, they don't count as an error mechanism. This a gray area.
I know this is a slippery response to give, but this is about the way I set up my terminology, rather than the purposes I have for talking this way.
