Patronizing Language Design?

[Nick Sabalausky]

"Sean Kelly" <sean at invisibleduck.org> wrote in message 
news:h3ntqk$qmv$1 at digitalmars.com...
> == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
>> 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?
>
> The same as yours.  As project complexity and team size increase, 
> modularity
> and isolation become increasingly important.  Varying design style between
> team members alone can substantially affect the comprehensibility of the
> design, not to mention varying skill levels and plain old workplace 
> problems.
> The more the design can be statically constrained by the design tools
> (programming language and toolchain, in this case), the less chance there 
> is
> for such problems to occur.
>
> I'd be interested in hearing whether there are any genuinely large 
> projects
> out there that are written in dynamic languages, and whether 
> maintainability
> is an issue with them.  Are bugs easy to find?  etc.

I recently worked on a upgrading a small Python/Django/Apache/Linux webapp 
from an older version of Django to a newer one. While there's a lot about 
using Django that's really nifty, I found debugging to be an absolute pain, 
even for that small app.

For instance, a lot of times when something was changed (though not always), 
the only indication was some obscure error that only pointed to a symptom. 
Plus, I would typically get no indication of certain errors until that 
particular section of code was actually executed (In these regards, it 
reminded me very much of the pains of dealing with PHP or Classic ASP.) 
There were a few other issues too.

However, in all fairness, it was my first experience with both Django and 
mod_python, and I'm not exactly an expert with Python, Apache or Linux 
(although I am familiar with them and have used them before), so that may 
have been a factor in making things worse than they normally would be.

FWIW, A couple of the problems I would probably have to attribute to 
unfamiliarity are:
- Temporary test code and temporary commenting-out accidentally screwing up 
the allmighty indentations (resulting in weird errors that didn't remotely 
seem to indicate an indentation problem)
- Certain objects apperently persisting even after changing the code, 
resulting in a number of incrediby bizarre errors such as a complaint that 
line X was calling non-existant function Y even when there was absolutely 
*no* reference to function Y on that line or any other (Ended up working 
around these sorts of issues by obsessively restarting apache after most 
changes, even though some changes *did* seem to work fine without restarting 
anything).

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.