Have language researchers gotten it all wrong?

[dsimcha]

== Quote from Unknown W. Brackets (unknown at simplemachines.org)'s article
> Well, I think it's more simple than that.  Suppose I have a problem.
> In Python, JavaScript, PHP, or some other similar language, I can solve
> the problem in 1,000 lines of code.
> In C++, etc. I can solve the problem in 5,000 lines of code.
> Which is likely to have the most bugs?  1,000 lines or 5,000?
> Obviously, compiler checking helps.  But, there are logical bugs that
> cannot be caught no matter what.  You will have 5 times as many in this
> example.  And those are the harder ones to find/fix anyway.
> The best of both worlds is the answer: 1,000 lines with the compiler
> finding some bugs.  This results in the best code and least bugs.
> Having the compiler do this fast is even better.
> D is, in my opinion, moving in the correct direction - toward this
> crossroads.
> -[Unknown]

Yes, I personally find that, while they may not be the majority of the bugs I
create, the majority of *time* I spend debugging is on high-level logic
errors--things like incorrect algorithms, input cases I hadn't considered, bad
assumptions about the way stuff I'm interacting with works, etc.  This is why I
tend to be skeptical of "safety" features in D and to push more for features that
make it easier to write good libraries.  The only way I feel a language can help
with high-level bugs like these is to make it easy to write reusable code with
clean abstractions so you're more inclined to write a general high-level library
to do something once, meaning you only have to debug it and get it right once.