== Quote from Unknown W. Brackets (unkn...@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.