Patronizing Language Design?

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:h3g51a$2e3r$1 at digitalmars.com...
> Here's certainly a different take on language design:
>
> http://blog.objectmentor.com/articles/2009/07/13/ending-the-era-of-patronizing-language-design
>
> I'm not convinced. All my engineering experience supports the idea that 
> the larger the project and the more people are involved in it, the better 
> off you are with isolation between modules and better enforcement of 
> interfaces.
>
> Simply relying on programmers being responsible isn't good enough when 
> you've got a high risk application.
>
> What are your experiences?

I've always considered myself a highly responsible coder. But I still make 
mistakes. Hell, the best programmers in the world make mistakes. The article 
seems to assume that safety features are for irresponsible coders. That's 
nonsense. There's always a way to get into some sort of trouble (even if 
it's just creating a pile of unmaintainable code), and irresponsible coders 
are going find it, because they're the ones who think they don't make 
mistakes. What makes a responsible coder responsible is *admitting* that 
they're infallible and responsibly using the appropriate tools to catch or 
prevent any possible mishaps.

Irresponsibility is skating along the edge of a cliff because "It's ok! I'm 
a responsible person!" Responsibility is making sure there's a f*^&* fence 
first.

"You can program safe, secure, high quality applications in dynamically 
typed languages. People do it all the time..." Yea, I'm sure they do. And 
there are a hell of a lot of people who ride motorcycles at 75+ mph without 
a helmet on a regular basis, never get into a single accident and live long 
productive lives. Doesn't mean it isn't stupid.

The whole article seems screwy anyway:

The author seems to be under the impression that whenever a particular 
feature is missing from a language, like metaprogramming or reflection, that 
it must be because it was deemed unsafe. Straw-man, anyone?

Also, maybe I'm wrong, but doesn't Ruby (and Python for that matter) lack 
direct memory access/management, reinterpret casts, etc? If so, then so much 
for the claim that those languages are all about throwing away safety nets 
and trusting the programmer. In fact, so much for the whole idea of placing 
all responsibility on the programmer because (unless I'm mistaken) *even 
those* supposedly "trust-the-programmer" languages know perfectly well not 
to truly trust the programmer.