Which Programming Languages Are Most Prone to Bugs? (i-programmer.info)

An anonymous reader writes: The i-Programmer site revisits one of its top stories of 2017, about researchers who used data from GitHub for a large-scale empirical investigation into static typing versus dynamic typing. The team investigated 20 programming languages, using GitHub code repositories for the top 50 projects written in each language, examing 18 years of code involving 29,000 different developers, 1.57 million commits, and 564,625 bug fixes.

The results? "The languages with the strongest positive coefficients - meaning associated with a greater number of defect fixes are C++, C, and Objective-C, also PHP and Python. On the other hand, Clojure, Haskell, Ruby and Scala all have significant negative coefficients implying that these languages are less likely than average to result in defect fixing commits."

Or, in the researcher's words, "Language design does have a significant, but modest effect on software quality. Most notably, it does appear that disallowing type confusion is modestly better than allowing it, and among functional languages static typing is also somewhat better than dynamic typing."

Comments

2018

[AHuxley]

Rediscovers how great Ada would have been for the consumer.

Mainstream languages, duh

[Anonymous Coward]

" On the other hand, Clojure, Haskell, Ruby and Scala"

Yeah, those are niche languages. Good, autistic programmers seek out niche languages and write clean code since they're the only ones working on it.

The mainstream languages are the ones you do at work, with a couple shitty coworkers, and an endless amount of scope creep and impossible deadlines that creates a spaghetti nightmare.

Complexity

[Anonymous Coward]

Or could it be that the software written in C++ usually tends to be large complex software where performance is important along with various other complicating factors. While the software written in ruby for example tends to be simpler?

Sounds like this 'study' started with a conclusion already in mind.

Haskell and C++ programmers are different.

[shess]

Something the linked article didn't seem to address it that the population for each language will differ. The average Haskell programmer is going to be very different from the average C++ programmer, or, god forbid, the average Python programmer.

Also, while they did try to address problem domains, I don't think they addressed systemic issues. For historical reasons, there are many projects which use C or C++ simply because of what they need to interface with to get the job done. For instance, there simply aren't going to be that many browser projects which aren't written in C++.

Personally, I think the interesting take-home is not the difference between languages, it's how small the number of commits for security and memory issues was.

Python

[_merlin]

I know I'll get flamed for this, but Python is really error-prone in a particular area, and that's its ridiculously weak name resolution rules. In a language like C, Perl, or even PHP, names are resolved during the compile phase. The compiler knows which definition of a name is going to be used at any point. Python doesn't have this - when it runs across a name, it walks up the scope hierarchy looking for a candidate.

This means that code can run happily for months or even years, until it just crashes with an undefined name error. This could be because of a rarely-used code path with a typo in it, botched refactoring of a rarely-used code path, or a particular set of rare circumstances where a global name isn't set before the code gets to a certain place.

The usual response is that unit tests should catch this. But let's face it, 100% unit test coverage is pretty rare, particularly for the kind of fast turnaround stuff that Python's frequently used for. Also, unit testing isn't necessarily going to simulate a corner case where a global doesn't get set before code that uses it executes. It also makes refactoring more risky because there's no point where the compiler can tell you you're referencing a name that's no longer defined, or no longer has a certain method/field.

This is the kind of area where it's really useful if the compiler can help you, and Python's ridiculously weak name resolution rules make that completely impossible.

Re: In before Fractal of Bad Design

[jeremyp]

Which is hardly surprising, since C is just PDP11 assembler tidied up a bit.

Nope.

http://csapp.cs.cmu.edu/3e/doc...

The i386 architecture is not a close copy of the PDP11. You might be thinking of the 68000 which is a more plausible candidate.

C has been ported to most recent processors mainly because it was needed. The fact that it is relatively easy to port gives the lie to your assertion that it is "Macro-11 tidied up".

And, by the way, RISC sort of has displaced CISC. Modern CISC processors like the x86 and later tend to be implemented on top of a RISC core.