Have language researchers gotten it all wrong?

[Unknown W. Brackets]

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]

bearophile wrote:
> People can talk all they want about the advantages of 'classic' static typing, but sometimes they are wrong. I've programmed in static typed languages most of my time, yet if I write a small but complex (~300-lines long) Python program I am usually able to make it run correctly in a short enough time, shorter than the time to write the same (buggy) program in D, and in the end such D program may even not work correctly and I may lose interest in finding the bug. In some situations this isn't caused by my ignorance of D, or by limits of my brain, or by my laziness, but by the intrinsic less bug-prone nature of Python compared to D programs that use pointers a bit. So while I like to program in D a lot, I don't agree with people that say that 'classic' static typing is able to avoid more bugs. On the other hand, if you refer to the modern type systems of languages like Haskell, then their type system is probably able to actually give you some help to write more correct progr
ams. But in languages with a primitive\simple type system as Java (and D) having a static type system isn't so important in reducing bugs in my small programs.