Patronizing Language Design?

[BCS]

Reply to Nick,

> Here's another thought on this recent "non-patronizing language" push:
> AIUI, One of the design ideals behind C's type system was exactly the
> same as these newer languages: to trust the programmer to "be an
> adult" and always know what they're doing. Well that didn't quite work
> out did it? Even the *experts* who make the C std lib *still* messed
> up and planted the seeds for thousands of buffer overflow
> errors/exploits. And then there's the troubles C coders have to deal
> with even today as a result of being trusted to not accidentally do a
> destructive implicit cast. The way I see it, these newer
> "non-patronizing" languages are walking down the exact same road which
> can only lead to the same old result: rediscovery of the need to *not*
> place blind trust in the programmer.

I think (and it would seem Walter does as well) the answer here is to trust 
the programer, but only when they ask to be trusted. Make it so they have 
to explicitly do something (like do a cast) to get out of the safe feature 
set. Then try and set up social construct to prevent them, when possible, 
from needing to do the unsafe thing.