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

Honorable Mention

[Ukab the Great]

Brainfuck

Re:Honorable Mention

[El_Muerte_TDS]

I have never heard of a large scale production problem happening in a application written in brainfuck. So by that metric it is not really error prone.

Re:Honorable Mention

[K. S. Kyosuke]

Interestingly...

Re:Honorable Mention

[Anonymous Coward]

Brainfuck

INTERCAL

Re: Honorable Mention

[Anonymous Coward]

GO AWAY

Re:Honorable Mention

[Anonymous Coward]

I have never heard of a large scale application written in brainfuck.

Re:Honorable Mention

[Anonymous Coward]

indeed, consider that statically typed languages, are more likely to have errors, because a compiler, checks them.

and you get this type of garbage.

In before Fractal of Bad Design

[Waccoon]

You already have to be a genius to understand functional languages, so of course those people make fewer mistakes.

I love it when functional fans insist it's more analogous to how the brain really thinks. That's why so few people can figure out how to do things that way.

Re: In before Fractal of Bad Design

[shm]

I don't know about that. As originally an assembly language programmer, I had greater difficulty with Pascal than with Scheme.

I think the concept of code and data being equivalent was an easier transition from assembly to Scheme.

Assembly to C was quite easy as well.

Re: In before Fractal of Bad Design

[Anonymous Coward]

LOL. Pascal and C are very similar. So your statement, "Pascal Hard, C easy" makes no sense. Pascal is just a stricter version of C. It also has a sane/simple object model compared to C++. There's a lot irrational hate towards Pascal whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".

Functional languages are convoluted and hard to read because they do simple things like "assigning a variable, like in a procedural language," by making a recursive function call.

Also, why is Java not mentioned in the summary? This is exactly the type of topic where we get to prove that a safe, statically typed language like Java can drastically reduce cost of "dangerous C/C++ bugs" that bring down services, help hackers steal data, or gain root access.

Re: In before Fractal of Bad Design

[_merlin]

Pascal and ANSI C are very similar, but pre-ANSI C is a completely different beast, far more similar to BCPL. In fact, ANSI C could almost be described as Pascal with C syntax.

Pre-ANSI C didn't have prototypes - it assumed any undeclared name was an external function. It didn't automatically convert int to long if the function expected it, etc. - you had to explicitly cast. You had to be careful to cast results of functions correctly, too. All it had was a set of rules for how argument types were stacked, and it was up to you not to pass something a function wasn't expecting. This is closer to assembly language programming than Pascal or ANSI C.

Re:In before Fractal of Bad Design

[angel'o'sphere]

Functional programming is not more complicated then other imperative programming styles.
But unfortunately functional languages like Haskell often have a strange syntax, that is all.

Re: In before Fractal of Bad Design

[Joce640k]

... Pascal, whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".

ROTFL!

http://www.lysator.liu.se/c/bw...

Re: In before Fractal of Bad Design

[Anne Thwacks]

Assembly to C was quite easy as well.

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

Which is interesting considering the PDP11 was "a hardware Fortran machine", and the i386 architecture is a close copy of the PDP11 - the 286 even copied the early (variable page size) PDP11 memory management scheme that was the fashion before people figured out it was not really good for virtual memory, and then the 386 copied the later (fixed page size) PDP11 MM which is needed for virtual page based memory. The PDP11 was designed on the assumption that memory bandwidth was the bottleneck in throughput.

The fact that C has been successfully ported to almost all more recent processors is largely because the concepts of what a CPU is and does have been developed by people who grew up on the PDP11 architecture. RISC architecture may be different, but, in reality, the RISC architecture is mostly just used to simulate CISC anyway. RISC was designed on the assumption that instruction decode was the bottleneck - which has not really been the case since the 1980's - hence the failure of RISC to displace CISC.

I am writing this on a Sparc64 (RISC) machine - the story is more complex that I describe here.

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.

Re: In before Fractal of Bad Design

[Anonymous Coward]

I think he meant intrinsically convoluted. Focusing on a concise way to achieve an output, then chaining those together, turns out to be horrible for readability and maintainability. Most people need unnecessary small changes in program flow with copious context, and preferably description in intermediate variables and functions. This was at the heart of the Perl exodus and Lisp excommunication. For the median intellect and practical needs of business, you want to mutate code quickly with limited information. Yes my 500 line Erlang program is more elegant and concise than my 5000 line java version, but that java is a lot cheaper to maintain.

Re: In before Fractal of Bad Design

[Anonymous Coward]

Compared to how horrible the original C compilers were (no type checking of parameters), Pascal is a huge improvement.

Let's look at the issues discussed in the paper:

2.1. If one declares

          var arr10 : array [1..10] of integer;
                          arr20 : array [1..20] of integer;

then arr10 and arr20 are arrays of 10 and 20 integers respectively... Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both.

Delphi "open arrays" allow you to process both arr10 and arr20 arrays using the same procedure/function.
Section 2.5 repeats the array issue and the solution in modern pascal is to use open arrays.

2.2. There are no static variables and no initialization

Turbo Pascal and Delphi have static variables and initialization.

2.6. There is no way to override the type mechanism when necessary, nothing analogous to the ``cast'' mechanism in C.

Type casting is available in turbo pascal/delphi.

3. There is no guaranteed order of evaluation of the logical operators 'and' and 'or' - nothing like && and || in C. This failing, which is shared with most other languages, hurts most often in loop control:

          while (i <= XMAX) and (x[i] > 0) do ...

is extremely unwise Pascal usage, since there is no way to ensure that i is tested before x[i] is.

TP/Delphi allow 'i <= XMAX) to be evaluated before x[i] > 0 if 'short-circuit' compilation is enabled.

The 'case' statement is emasculated because there is no default clause.

TP/Delphi have the default clause. And their case statement is less error prone than the horrible 'fall-through' semantics of C's switch statement.

Similarly, most issues the paper mentions have been solved in TP/Delphi. The only issue that remains is the "begin/end" thing. That's why Java's syntax reminds me of Pascal. Other than the superficial C-like syntax things like "{ }", method arguments like C, Java's syntax is mostly copied from Pascal, including the "import statement" (Pascal's 'uses' statement), single inheritance OOP similar to Object Pascal etc.

Pascal had the 'Boolean' type very early on and programming in C is painful because you have use non-zero values to simulate the boolean types. Pascal also has array bounds checking, no accidental assignment like in C's 'if' statement etc.

In short, there was a lot of bad-mouthing of pascal to destroy its reputation, when in reality it kicks C's ass 9 ways till Sunday.

Re: In before Fractal of Bad Design

[Entrope]

That is very much like saying that because Microsoft Visual Studio lets you write in C++.NET, there has been a lot of unfair badmouthing of C++. Pointing to one vendor's proprietary extensions (which essentially make a new language) doesn't make the general complaint wrong.

Re: In before Fractal of Bad Design

[Entrope]

And my 50 line Perl version is much more concise than both of those, but my co-workers keep complaining that it's actually modem line noise!

Re: In before Fractal of Bad Design

[Z00L00K]

Different languages allow for different language-specific bugs.

However the worst bugs aren't the language specific bugs - it's system design bugs where the designer don't understand the business case that shall be solved.

The programming language bugs are usually found either by hand or by tools like FindBugs, Splint and other similar tools. But system design bugs are all in the brain of people - and some people have a very strange brain wiring resulting in "perfect solutions on non-existing problems".

Re: In before Fractal of Bad Design

[Z00L00K]

And one way around it was to declare the function before it was used - that did help a bit sometimes. Not always, but sometimes - and depending on compiler.

But Pascal, C, Java, C++ and Ada all belong to the same programming paradigm, with or without the object orientation twist.

Then we have Basic and Fortran which sometimes have the paradigms from Pascal et.al. but also other ways not related to them.

Cobol is in turn an animal of itself.

And then you can turn to Erlang, Haskell and Prolog for yet another way to do things.

Re: In before Fractal of Bad Design

[K. S. Kyosuke]

Most people need unnecessary small changes in program flow with copious context, and preferably description in intermediate variables and functions. This was at the heart of the Perl exodus and Lisp excommunication.

Not sure about Perl but Lisp thrives on intermediate variables and functions. You most likely don't want to write large expressions in Lisp without intermediate variables, unless those expressions are auto-generated (which, admittedly, is a programming style in itself).

Re: In before Fractal of Bad Design

[Anonymous Coward]

Pointing to one vendor's proprietary extensions (which essentially make a new language) doesn't make the general complaint wrong.

Yeah, because C has not changed at all since the '80s, right? You still use the K&R C spec compilers to publish software, right? LOL.

Turbo Pascal and Delphi are the de facto standard compilers for Pascal. There are a few other toy OSS pascal compilers other than the Borland stuff, but their market share is tiny.

Re: In before Fractal of Bad Design

[K. S. Kyosuke]

C++ is probably understood to be the C++ standard. Whether anyone thinks of Standard Pascal today when Pascal is being mentioned seems much more unlikely.

Re: In before Fractal of Bad Design

[Anonymous Coward]

Because being concise in a programming language is a secondary benefit of maintaining software. The primary benefit is the ability to come back and modify it, without having to start an effort as great as that of creating the software new. Perl is fast in the wrong parts (the typing) and slow in the wrong parts (thinking). That's why it sucks, and when you get tired of code golf, you too can join the rest of the software developers.

Re: In before Fractal of Bad Design

[Entrope]

That was the joke. If you were less of a humorless scold, maybe you would have realized that the bit about co-worker complaints was a flag to indicate where the costs of that tradeoff come in.

One occasionally does have use for write-only source code, where the source code is small enough that changing the purpose of the program would inherently require rewriting such a large proportion of the code that it is just as efficient to start from a blank file, but that is seldom going to be the case for even a 500-line program.

Re: In before Fractal of Bad Design

[Entrope]

So you are saying that the years since BWK wrote that article have given us even more reasons to dislike Pascal, such as the fact that the only versions that are useful are either dead for 20+ years (Turbo Pascal) or need vendor-proprietary extensions (Delphi)?

Re: In before Fractal of Bad Design

[Anonymous Coward]

Deserves a mod up.
What I can't understand is that CODE REVIEWS - never happen these days.
Use to have 2 other senior expert programmers (native assembler heads who read dumps) picking holes in my code and a red marker- after an 'observer' or witness to some outsourced work..
These days it is promote and done - nobody looks. I also state compiler options to save problems later are rarely used or taught.
I learned strong typing saves you over and over. But hey now we have these visual programmers who cant program but drag and drop etc, demand others write SQL.

I have also learned code reuse has failed to happen for Java - and nobody gets in trouble for writing a function already available elsewhere.

Re: In before Fractal of Bad Design

[K. S. Kyosuke]

Actually, I just found out that even Standard Pascal has conformant arrays, so it's more like that this article gives us even more reasons to dislike BWK. Although, the proper way to use Pascal is to use Modula-2/3 or Oberon, given that Pascal has limitations (that C++ shares) that made Wirth abandon it anyway.

Re: In before Fractal of Bad Design

[Anonymous Coward]

there has been a lot of unfair badmouthing of C++

Any badmouthing of C++ is quite earned and fair. C++ is a frankenstein's monster of mismatched parts in a hodgepodge of follies. Sure, they've managed to kinda clean it up in the last decade, but that's more in line with "less bad" than "actually good". It has all the flaws that C does built right into the core. And for all the chest beating loud bleating "good programmers" out there, we're still constantly finding flaws in pretty much anything written in C/C++ that's of any size.

C/C++ are error prone languages and should probably be relegated to very limited subsections of programming that actually need them. Do to C/C++ what C did to ASM.

I know C/C++ are never going away, but they shouldn't be used for new code. Go, Haskell, D, Rust, plenty of other options for languages that make it at least slightly harder to make basic but easily overlooked mistakes.Why not let decades of computer science automate the boring stuff?

Re: In before Fractal of Bad Design

[Entrope]

ISO 7185 ("Standard Pascal") defines conformant arrays to be an optional feature, which gives us another -- entirely redundant -- reason to dislike K. S. Kyosuke, because K. S. Kyosuke either lies or is willing to make definitive, but wrong, claims out of ignorance.

Re: In before Fractal of Bad Design

[Joce640k]

Pascal, whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".

...most issues the paper mentions have been solved in TP/Delphi.

There have been several attempts to fix the "flawless" language, yes.

(despite even it's creator abandoning it for something better).

Re: In before Fractal of Bad Design

[Anonymous Coward]

We should let decades of computer science automate the boring stuff. That still isn't sufficient to make D or Go compelling, much less Rust or Haskell.

Witness the rare publications where Haskell fans are delighted when they find something that runs almost as fast as a C or C++ version of the same algorithm, or the fact that Rust people spend most of a decade developing Rust and then declare victory when they make one particular part of one application faster, but less energy-efficient, than the "legacy" C++ version (which took far less time to develop).

Re: In before Fractal of Bad Design

[Tenebrousedge]

You didn't understand what was said. No one was suggesting that the PDP-11 instruction set is similar to i386, and it's irrelevant. There are a number of features of C which map directly to PDP-11 instructions, and to some degree it was also informed by how the PDP's registers work.

Re: In before Fractal of Bad Design

[Tenebrousedge]

What I'm hearing is that you're an idiot who can't handle more than a basic level of abstraction. I suppose those who prefer Java deserve what they get.

Re: In before Fractal of Bad Design

[Anonymous Coward]

I can't agree with this comment of yours:

"I have also learned code reuse has failed to happen for Java - and nobody gets in trouble for writing a function already available elsewhere."

In my experience, it is to the other extreme where every Java programmer insists on dragging in some library or framework rather than write a single function. Then they get to put the library name on their resume.

Unless what you meant was programmers sharing code across projects within the same company, or possibly within the same project for use by different team members. In that case, I don't see Java programmers per se as being worse than others, but it is definitely a problem that increases with team size.

I've been at this for over 20 yrs and I have never seen "code reuse" as being done much or even being a worthwhile goal in itself. (Idea reuse is another thing, or "re-use" of entire large services as-is, but I think you meant re-use on a finer scale than that.) The reason is that it is more costly to make the code generally useful than it is to leave it special purpose most of the time, and the documentation, packaging, and publicizing of said code adds a NON-TRIVIAL cost.

Re: In before Fractal of Bad Design

[Anonymous Coward]

I agree to some extent, but C++ does a pretty good job at making general purpose code easy to write. Maybe why it's so sucessful.

Re: In before Fractal of Bad Design

[redmasq]

Maybe that Perl of humor was the straw that broke the camel's back. That said, at the very least, Perl is still easier to read than Whitespace and easier to pronounce than INTERCAL.

Re: In before Fractal of Bad Design

[Entrope]

You just don't see innovations like the "COME FROM" statement in modern languages. Now there's a language feature with a noteworthy impact on defect density.

Re: In before Fractal of Bad Design

[imnotanumber]

So you are saying that the years since BWK wrote that article have given us even more reasons to dislike Pascal, such as the fact that the only versions that are useful are either dead for 20+ years (Turbo Pascal) or need vendor-proprietary extensions (Delphi)?

No. You have fallen prey to the common hype.

There is, the GCC of Pascal world, that is Free Pascal https://www.freepascal.org/ : an Open Source version with a modern syntax and concepts. The complaints on the article seem someone complaining about Linux arguing that you have to compile the Kernel to add mouse support.

Also, Lazarus https://www.lazarus-ide.org/ is a modern Open Source IDE that picked where Delphi stop and you can develop and compile applications for Windows, Linux and OSX.

Re: In before Fractal of Bad Design

[imnotanumber]

Pascal, whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".

...most issues the paper mentions have been solved in TP/Delphi.

There have been several attempts to fix the "flawless" language, yes.

(despite even it's creator abandoning it for something better).

No. That branch is the fix for the original Pascal, the one that earned the outdated critique.

TP/Delphi and then Free Pascal/Lazarus are another branch that solved the earlier problems and do not have the original flaws.

Re: In before Fractal of Bad Design

[Entrope]

So there is a hodgepodge of mutually incompatible dialects of Pascal that are available, some of which are useful?

This is not helping Pascal's case, and makes it look more and more like my C++.NET analogy was accurate.

Re: In before Fractal of Bad Design

[Anonymous Coward]

Putting Prolog in the same category as Erlang and Haskell makes zero sense to me.

Re: In before Fractal of Bad Design

[rnturn]

``Pre-ANSI C didn't have prototypes - it assumed any undeclared name was an external function. ... This is closer to assembly language programming than Pascal or ANSI C.''

Interesting you would note that. I still recall a comment made by a co-worker back in the early '80s that "C was like assembly language without the handcuffs".

Re: In before Fractal of Bad Design

[redmasq]

Especially since the GOTO statement is considered harmful.

Re: In before Fractal of Bad Design

[Anonymous Coward]

"COME FROM" is one of the most brilliant things I've come across in IT. It should be taught in schools.

Re: In before Fractal of Bad Design

[kanly]

Which C++ standard? It really matters. They really are completely different languages.

C++98 was only a few steps past "C with Classes". Compare some C++98 code (which at this point looks like somewhat portable object-oriented assembly in terms of abstraction level) to some modern idiomatic C++14 code. Idiomatic C++14 is often closer to a functional language with compile-time computation than anything a C programmer would recognize. No raw pointers anywhere, first-class function objects, implicit dependency ordering on multithreaded computations with continuations, there's a lot to love there. (There's a lot of legacy baggage too, but the core language is actually becoming quite beautiful.)

Re: In before Fractal of Bad Design

[imnotanumber]

So there is a hodgepodge of mutually incompatible dialects of Pascal that are available, some of which are useful?

Practically, Delphi and Free Pascal (with Lazarus being the IDE that uses Free Pascal as a compiler) have the majority of mind share in the Pascal World, and they are mostly compatible. A few years ago Delphi used the Free Pascal Compiler to target iOS. Of course, those who sell Delphi are not very keen to advertise the Open Source competitor...

This is not helping Pascal's case, and makes it look more and more like my C++.NET analogy was accurate.

Most criticisms come from people that are completely out of touch with the modern Pascal Compilers/IDEs. Just take a look at http://newpascal.org/assets/mo... to learn its current state.

Re: In before Fractal of Bad Design

[K. S. Kyosuke]

What?

Re: In before Fractal of Bad Design

[Anonymous Coward]

>> ... Pascal, whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".

>ROTFL!

Well, you should not ROTFL.

Not to bad mouth Mr. BWK, and it is a given but he's got a lot of work to back his opinion; also, he would not write that text just to express an opinion of his, but most certainly to discuss the flaws he saw in Pascal at that time. Such flaws, regardless of how they have been mitigated afterwards, possibly really deserved his attention. I understand that article to be a service to the CS community and indirectly a helping hand for Pascal itself. So, no bad feelings.

With that out of the way. C and Pascal once competed for the same niche and C won.

But they came from very different origins. C was a sensible progress over using assembly; people escaped from a sad destiny in which they would be painting pictures with small brush strokes. C proved to be a new and very useful tool to make sophisticated applications, enabling full use of processor and other hardware features. Many of what was possible, was made possible by C.

Pascal came from the vision that ideas come first. I don't really know what people did prior to coding in C, maybe there was the need for some pseudo-code; but Pascal was meant to be itself the pseudo-language, a way for communication and a tool for teaching.

That difference in opinion would be not too different from the discussion about compilers x interpreters. We now know interpreters won and Java prevailed. But in the C x Pascal discussion, big projects would choose C because of performance and Pascal was abandoned.

I really don't know how much of those discussions were influenced by C being invented in the US while Pascal came from Europe; in a way, this has a taste like the modern Gnome x KDE fights... people don't like KDE because apps were mostly written with an initial "K". This is somewhat dumb...

In my case, such fight meant the end for my life as a programmer. I loved that profession back then and still love it, this is partly why I'm here, entertaining ideas of doing something to return to that area... one day, but age already makes that a tad harder.

And yes, I'd like an option to use not just "{" and "}" instead of begin/end, but rather to have Pascal work the same way as Python -- delimiting logical blocks thru indentation.

If you don't like Pascal and have preferred C all these years, sorry to make you lose your time. Who knows, one of these days I may find the time to program again and then you'll get something under the GPL to play with... Have a good night.

Re: In before Fractal of Bad Design

[Anonymous Coward]

GO AWAY

posted above

Re: In before Fractal of Bad Design

[pezezin]

Erlang syntax derives from Prolog. Other than that, they don't have much in common.

Re: In before Fractal of Bad Design

[Wootery]

But Pascal, C, Java, C++ and Ada all belong to the same programming paradigm, with or without the object orientation twist.

But there are very significant differences regarding how bug-prone the languages are. Unlike C and C++, Java has no concept of undefined behaviour, and does a far more complete job of insulating the programmer from platform-specific quirks. It's night and day.

Unlike C/C++, Java enforces left-to-right evaluation order, always uses 2's complement arithmetic (not target-platform specific), always uses big endian (not target-platform specific), always initialises to zero (never UB), always performs array bounds checking (never UB), always checks for null when dereferencing (never UB), always checks for invalid casts at runtime (never UB), the list goes on and on.

Yes, both C++ and Java have object-orientation, but their philosophies are completely different. (Perhaps I'm just talking past you here though - you're right of course that they're both procedural/OO at the end of the day.)

Re: In before Fractal of Bad Design

[Alioth]

Well, except RISC did end up doing overwhelmingly well: ARM (which originally meant 'Acorn RISC machine') is now the most popular architecture, and ARM ships more cores in a year than x86 variants have in all time.

Re: In before Fractal of Bad Design

[thogard]

There's a lot irrational hate towards Pascal whose sole flaw is using verbose keywords like "begin/end" instead of the concise "{ }".

There is a deeper problem than the names that is related to that in the early days of C, "{" was "create a new stack frame", where "begin" in Pascal was "create a new name scope block" as C keeps its local variables on the hardware stack and Pascal used to keep them in what would now be called heap memory because the real hardware stacks were very small.

Re: In before Fractal of Bad Design

[Duhavid]

They were referring to being descendants of the algol programming language line, I believe.

"Unlike C and C++, Java has no concept of undefined behaviour, and does a far more complete job of insulating the programmer from platform-specific quirks."

    Very true. Java, benefiting from the experience of the languages that came before it, does a better job of insulating.

"Unlike C/C++, Java enforces left-to-right evaluation order, always uses 2's complement arithmetic (not target-platform specific), always uses big endian (not target-platform specific),"

    From the standpoint of error prone, I'm not certain on these.
        "left-to-right", I presume you mean left to right within an operator's precedence level.
            As long as the calculation result is correct, does this matter?
            W.R.T. overflow/underflow and calculation precision, I would think strict l to r within a precedence level could
                give worse results.
        "2's comp arith"
            As long as the calculation result is correct, does this matter?
            On a machine that did not do 2's comp arith, ( assuming it did the arithmetic correctly ), I would think
                that forcing 2's comp would lead to poor performance.
        "big endian"
            As long as the calculation result is correct, does this matter?
            Forcing the internals to be big endian on a little endian machine would seem to lead sub-optimal calculations.
            For stuff heading "off machine", converting to a common endian-ness would be good, but seems like a
                handled problem

"always initialises to zero (never UB), always performs array bounds checking (never UB), always checks for null when dereferencing (never UB), always checks for invalid casts at runtime (never UB), the list goes on and on."

        For the enumerated items, for most programmers, for most applications, these are all good things,
        but they do have a cost.

Re: In before Fractal of Bad Design

[Duhavid]

I think another flaw, the one that I recall as being "the showstopper" was the need to declare string lengths.
If you were writing code that needed to handle arbitrary length strings, having to declare a very long string or other workarounds seemed the biggest real complaint of the day.

Re: In before Fractal of Bad Design

[Anonymous Coward]

Lazarus/FPC has always been slower and more unstable than Delphi. I have used it for many years before switching to C#.

Re: In before Fractal of Bad Design

[Anonymous Coward]

If they *just* drop the BEGIN/END stuff. At least this and I might come back to Pascal, some day.

Re:In before Fractal of Bad Design

[Anonymous Coward]

You already have to be a genius to understand functional languages, so of course those people make fewer mistakes.

And yet some of the loudest proponents of functional programming I've known have been some of the worst programmers I've known ... though I'm sure they'd try to tell me that in a functional language their code wouldn't be un-maintainable shit.

I started to tune out the people who say "ZOMG, we should code in teh functional". Those people don't seem to understand that code is meant to actually do stuff and do real things, not just be some static and elegant thing which doesn't really do anything.

Elegant in theory, useless in practice.

2018

[AHuxley]

Rediscovers how great Ada would have been for the consumer.

Re:2018

[romiz]

Perhaps if one day we get a compiler that does not require you to choose between an expensive license or coding only GPLv2 projects. Until then, all those GCC efforts only serve as an advertisement for GNAT Pro, and the only users will continue to be those avionics companies that are used to pay a lot.

Re:2018

[serviscope_minor]

Is that really the case? GNAT is part of GCC isn't it, which allows you to use the output and the libraries without counting as a derived work.

Re:2018

[romiz]

It seems that I was confused: you don't have the same standard libraries when you use AdaCore's GNAT Libre, GNAT Pro, or Ada support in GCC. And the Ada support integrated into the GCC mainline supports the linking exception. There is a better explaintation, but all this is quite confusing...

Re:2018

[Anonymous Coward]

Rediscovers how great Ada would have been for the consumer.

#MAGA - Make Ada Great Again!

Re:2018

[HiThere]

The first problem I had with Ada was that strings of different lengths were of different types. That could be solved with bounded or unbounded strings, but then you couldn't compare against literals. There were other problems, and there were always ways around them, but I had to used unchecked conversion too often for things that were perfectly safe. The entire thing was a mess due to over-concern with simple type conversions. Dynamically allocated storage is also a mess, though, given the original ideas, quite reasonable. Follow an Ada program through a simple addition of a node to a tree and you should see what I mean.

Another part of the problem was that the optional annexes couldn't be used as they usually weren't implemented. It's great to not have to load them if you don't need them, it's not so great if they aren't available when you need them.

There are lots of other minor design flaws. In a way you can forgive them, because this was being designed at about the same time as C++ was being written, and, unfortunately, it was designed by a committee. So the kitchen sink got thrown in. But they did design everything in a way that enabled maximal security...even where it didn't make any sense. (Why can't I compare two literal strings of different lengths? They've probably changed that by now, though.)

Re:2018

[Anonymous Coward]

There was a study done in a US government project, which did two control software implementations, one in C and one in Ada (starting from the same requirements and general high level design). It turned out that the two pieces of software cost the same amount to develop and had the same bug frequency. They did find out that Ada developers spent more time in the development phase (fighting the language?) than the C developers, but the C-developers made that up by spending more time on testing.

So, the moral of the story. It probably doesn't matter which of them you chose, but I suspect that it is easier to find competent C-programmers than competent Ada programmers. Also, this was before we had access to tools like the clang static analyser without having to pay ridiculously high license fees, so today I suspect that we have an improvement in productivity on the C-side.

Re:2018

[TVmisGuided]

There's absolutely nothing wrong with writing GPLv2 code in Ada. I can think of one major issue that could have been avoided entirely had Ada been the language of choice for a GPL application: the Heartbleed bug in OpenSSL.

"If software is safe, it cannot harm the world. If software is secure, the world cannot harm it." -- John Barnes, author of several Ada programming texts

Re: 2018

[Zero__Kelvin]

What drugs are you on?

Re:2018

[Tom]

It would actually be a good idea to rediscover some of the advances of the past that have been lost to history. My domain is information security, and in many areas we are worse than our ancestors in the early days of computing were. Updating some of the academic research that has fallen by the wayside could do wonders for us.

Re:2018

[Anonymous Coward]

There was never any issue like you describe with string types, nor is there much/any need for use of unchecked conversion, nor is strong typing a mess, nor was the language designed by committee... Why would you just go on the internet and tell lies?

Re:2018

[david_thornley]

The Heartbleed bug would not have existed if the authors had used the safety features present in C. It relied on having access to memory allocated but not initialized, and so keeping the previous contents. If the authors had used calloc() instead of malloc(), or thrown a memset() in, Heartbleed would not have happened. In security software, letting what happens to be in memory stay there with a new allocation is a Bad Idea. Zeroing out the memory on free() would have been a better one, but you can't easily do that with standard C functions.

Given that the authors couldn't use obvious C safety features in their desire for execution speed, I have to think they'd have found some way to introduce bugs into a more hand-holding language.

Re:2018

[Anonymous Coward]

The first problem I had with Ada was that strings of different lengths were of different types. That could be solved with bounded or unbounded strings, but then you couldn't compare against literals. There were other problems, and there were always ways around them, but I had to used unchecked conversion too often for things that were perfectly safe. The entire thing was a mess due to over-concern with simple type conversions.

I remember this being an enormous headache when I was learning Ada in college.

I recently got to rediscover the pain when writing VHDL, a language based on Ada - with exactly the same type issues. It's a huge nuisance to work with strings, with lots of overhead that more sensible languages avoid.

I have to admit that not everything about VHDL is horrible - there are a few ways in which it is superior to modern Verilog (being able to pass arrays as arguments to modules is really nice). But on the whole modern Verilog (with it's C-like constructs) is a far better language, and the high quality of tool support - far better than we find in the VHDL world - makes up for a lot of the remaining problems in Verilog.

Having said that, I dream of being able to work in a language that combines the best features of VHDL, SystemVerilog, and Ruby - but it will probably never happen.

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.

Re: Mainstream languages, duh

[Dausha]

I know this is /. and RTFA is simply not done, but if you read the sample, you would see that Ruby was 2nd in developer count (after C), 4th in project counts (JS, python, C) and 5th in commits. Ruby represented 9.6k of the 28k developers; about a third. So, not so niche. In fact, C and Ruby together represented 22.4k of the 28k.

Java had about a third as many developers as Ruby with the same project count.

What is interesting is that Typescript had a 0.15 coefficient compared to Javascript's 0.03, meaning it is more error prone--tying Objective-C for first place in error-proneness. More error prone than C.

I was amazed at how well Go fared in all categories, with a high developer count and lowest coefficient.

Re:Mainstream languages, duh

[vtcodger]

Yep, that was my thought when I read the article. Software used by a wide audience will generally require a lot more bug fixes than similar software used by only a few. Users find the damndest ways to use and abuse software. The more users, the more things they want changed and the more actual bugs they identify.

Face it -- most of the world runs on C, C++ and, increasingly, Python. Of course there are lots of bug fixes. And BTW I loath C++. IMO C++ code is almost always unreadable except possibly by its author. And C isn't that much better. I'm not defending my favorite languages here.

Re:Mainstream languages, duh

[Anonymous Coward]

Worse, what if the programs are just as buggy, but the fixes aren't happening (for reasons, mostly the personality of people who write projects in uncommon languages).

Re:Mainstream languages, duh

[david_thornley]

I've worked on large C++ codebases, the products of many people over time, and it's generally nice and readable. If you find it unreadable, you may be looking at bad code.

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.

Re:Complexity

[Pseudonym]

That was my first thought. It turns out that they ranked popularity by number of stars.

When you think of popular pieces of open source written in each language, what do you think of? Here are the ones from the paper:

C projects: Linux, git, php-src.
Python projects: Flask, django, reddit.
JavaScript projects: Bootstrap, jquery, node.
Java projects: Storm, elasticsearch, ActionBarSherlock

If you didn't know, ActionBarSherlock is a piece of Android infrastructure. Given that, these all seem very reasonable.

How about C++? What do you think would be the most popular C++ open source projects? Here they are:

C++ projects: node-webkit, phantomjs, mongo

Mongo seems reasonable, but... those other two! There's no Mozilla, no Boost, no tensorflow, no LLVM... not even webkit, just two webkit clients, both of them javascript bindings.

Re:Complexity

[AuMatar]

ActionBarSherlock is a replacement for a piece of Android Architecture to backport functionality that existed in 4.0+ to 2.2+ (or thereabouts). Its been deprecated for years, as nobody writes for those old versions, and Google has been releasing their own backporting libraries for years. So no, its not reasonable.

Re:Complexity

[Anonymous Coward]

You use C and asm if performance is important. C++ doesn't make the cut there, large and complex software yes.
Truth is I've seen very few projects where using C++ actually resulted in decent code in the end and quite a few where it wasn't at all helpful.

Re:Complexity

[Pseudonym]

Fair enough, I didn't know that. Still, as Meat Loaf said, 2/3 ain't bad.

Re:Complexity

[Joce640k]

1993 just called and wants it C vs. C++ flamewar back.

Re:Complexity

[Pseudonym]

Be fair. The argument still made sense before C++11 or so.

Re:Complexity

[Carewolf]

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.

Yeah. Another possible conclusion from this data is that C++ is more commonly or easily debugged, and thus more bugs are found and fixed, where they are left unfixed in the other languages.

Re:Complexity

[Carewolf]

C++ is generally faster than C these days, though ofcourse you can fuck it up like anything in C++ if you don't know what you are doing, or do and are just trying to "prove" your incorrect point.

Re:Complexity

[Anne Thwacks]

Truth is I've seen very few projects where using C++ actually resulted in decent code in the end and quite a few where it wasn't at all helpful.

Probably because a huge amount of C++ code is in massive embedded systems which are closed source and you can't see the code. I can't either in the general case, but in the cases I have seen, the quality of code is roughly what you would expect from the quality of the team. (In all probability, larger teams will need one or more specialists to do the more complex debugging).

Are there any large Open Source projects in Cobol? No. That is mostly because Cobol is not fashionable with the OSS crowd. My point is fashion is the biggest factor in language selection for OSS. Not so much for closed source (where the prejudice of the CTO is the biggest factor). I doubt actual performance of the language is relevant to language selection in more than 1% of projects - and those are mostly academic experiments, rather than commercial work.

Re:Complexity

[K. S. Kyosuke]

a huge amount of C++ code is in massive embedded systems

You mean the systems that use "C++" instead of C++? As in, with significant restrictions? I'm reasonably sure the quality of those has more to do with the discipline of the programmers than with anything else.

Re:Complexity

[Entrope]

No one else has pointed out the old saw that there are three kinds of lies (lies, damned lies, and statistics)? Or that one could -- and someone actually did -- literally write a book on "How to Lie with Statistics"?

Re:Complexity

[Anonymous Coward]

Another thing is that compiled programs typically get bug reports and fixes.
"A script on the page you are visiting have stopped working" just makes the user hit F5. It doesn't get fixed and doesn't show up in their statistics.

Re:Complexity

[Joce640k]

It seemed to me like he was about to play the "'Hello, world' is bigger in C++ than C" card.

(and I'd like to see some evidence that C++ rarely results in "decent code" or where it's "not at all helpful").

Re:Complexity

[jeremyp]

Mongo seems reasonable, but... those other two! There's no Mozilla, no Boost, no tensorflow, no LLVM... not even webkit, just two webkit clients, both of them javascript bindings.

Do any of those projects use GitHub as anything other than a mirror? LLVM, for example, is hosted in its own SVN repository. I imagine most people who want the source go direct to the source, as it were.

Re:Complexity

[HiThere]

Sorry, that hypothesis doesn't fly. It may be harder to debug C or assembler than C++, but most other languages provide more usable debugging facilities than does C++, and most of them are easier to write unit tests for. The unit testing for C++ is basically an add-on. Even assert statements in C++ are crippled, unless you use an extension. (Assert statements should include an optional message that is printed with the error, and which can dump variables of interest in a formatted way.)

So C++ is more difficult to debug. There *are* more external tools that you can use to do the debugging, but that's because they are needed.

Re:Complexity

[Pseudonym]

Oh I'm certain that there is a lot of C++ code out there that would be better written in some other language. And on github it probably isn't too hard to find.

But this is also true of your favourite language, assuming your favourite language has a critical mass of people who think they know how to use it.

Re: Complexity

[tigersha]

Are there any large Cobol projects out there? I mean this as a question, not sarcasm.

Re:Complexity

[Pseudonym]

Fair point. It's also true that a lot of these projects don't have that many people working on them.

LLVM and tensorflow are good examples of software projects where you need to have a minimum level of knowledge of the problem domain to make any meaningful contribution. So while a lot of people use those projects, not very many contribute.

Boost, of course, has a very strict code review policy before it accepts new functionality.

Re:Complexity

[Anonymous Coward]

Even assert statements in C++ are crippled, unless you use an extension. (Assert statements should include an optional message that is printed with the error, and which can dump variables of interest in a formatted way.)

C++ asserts are a feature for the debug build, on sane systems that dump core files you get the complete program state at the time of the crash ready for insertion into any compatible debugger, not just a subset of variables the original developer thought of that are ultimately useless, it amounts to printf based debugging.

The unit testing for C++ is basically an add-on.

They are in most languages I know of. The only issues I have with my C++ unit tests is that the project I work on is written around a god object.

Re:Complexity

[david_thornley]

No, it didn't. Any C program could be fairly trivially ported to C++ (C++ isn't quite a proper superset of C90, but it's close), and the C++ compiler would compile it pretty much as the C compiler would. The first C++ compiler used cfront, a C++ to C translator, and the C code would go through intact.

C++ has always been at least as fast as C, since it can always do what C does.

The C++ libraries were not necessarily as fast as the C ones (iostreams vs. stdio, for example), but that's a different matter.

Re:Complexity

[david_thornley]

By Darrell Huff, back (IIRC) in the 50s.

Re:Complexity

[Pseudonym]

I was specifically responding to the claim that C++ wasn't helpful. There is an argument that there was less of an advantage before Modern C++.

Re:Complexity

[ebvwfbw]

Used to be the C++ compiler was simply a pre processor to C. Therefore you clearly could go to C, going to C++ was a lot more problematic.

Side note, I found I could take my C code and end up with 1/3 the lines in Perl. It ran in every case but one without a difference in speed while the perl code was way more readable and maintainable. I still run some code in perl that was moved over from C in 1995.

Re:Complexity

[david_thornley]

while the perl code was way more readable and maintainable

I just have to quote this, since it's something I'm not sure I've read on the net before.

Any reasonably aged language

[Anonymous Coward]

Despite every example online... it is possible to write clean perl. That said, I've not seen any reasonable dbi example. It's all the same bad garbage over and over. This led all the Python followers to declare there is no good perl and no bad Python.

Several years later, indeed there is now lots of bad Python in existence! As time marches on there are even more examples of this behavior.

I would argue any language of sufficient age will have an equally large sum of poor examples.

Languages can sing and it takes work to make them so so.

Re: Any reasonably aged language

[Anonymous Coward]

Yes exactly!

Presently I feel the Python library (and pip and eggs and all the crap) is a real mess. So much half finished, bad code.

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.

Re:Haskell and C++ programmers are different.

[serviscope_minor]

Also, while they did try to address problem domains, I don't think they addressed systemic issues.

I don't think they do: none of them have things like zero overhead abstractions, zero cost memory allocation and so on. And some of them (like go) lack the kind of abstractions present in many modern languages.

For instance, there simply aren't going to be that many browser projects which aren't written in C++.

Of the three remaining extant enignes: Firefox, Webkit/Blink and Edge and Trident all except firefox are written in C++. Firefox is partly Rust now.

Rust I think is one of the very very few languages aimed a the same problem domain as C++ by people who understand enough C++ to know what the problem domain was. Look for example at Pike's rants on GO and how was designed to replace C++ and didn't: many C++ programmers sikmmed the features and said something like "oh that'll make my program slowe, more verbose, buggier and harder to write". Rust on the other hand is the same machine model as C++ but with a very very different type system.

It's never going to replace C++ across the board that's for sure but it's proven capable of replacing C++ in a niche where formerly there were no contenders.

Re:Haskell and C++ programmers are different.

[Anonymous Coward]

The only niche that Rust is particularly appropriate in is "SJW-dominated cult language".

Re:Haskell and C++ programmers are different.

[SwashbucklingCowboy]

I'd venture that the small number of commits for security issues is because many developers 1) don't mark issues as security issues (security not being foremost in their mind) and 2) many developers can't recognize issues as affecting security (which is even scarier).

Re:Haskell and C++ programmers are different.

[Anonymous Coward]

Except the Rust people completely messed up by making Rust look like perlesque line noise, so most C++ developers take one look and vomit. I'm certainly not going to replace C++ with a language that is uglier than C++.

Re:Haskell and C++ programmers are different.

[Anonymous Coward]

The Code of Conduct can only be enforced on their official channels. Go make #asshole-rust if you're too much of a knob to act like a respectable person long enough to ask questions. They won't stop you. And they can't stop you from using their language while being an asshole either. Stick it to 'em and make a Rust program that breaks every rule in the CoC! That'll show those SJWs!

Don't get me wrong, I think the CoC should read "Don't be an asshole" and be done with it. Maybe "Be Excellent to Each Other. Party On". But I don't give a shit who is helping me, as long as they've got their shit together. I refuse to pass on Rust because the CoC isn't catered specifically to me, I put on my grownup pants when I'm in their official channels and then when I leave it's business as usual. The language is too promising to bitch about something so minor.

Re:Haskell and C++ programmers are different.

[Wookie Monster]

Where are Pike's rants on Go? I tried a simple search but didn't find anything interesting.

Re:Haskell and C++ programmers are different.

[swillden]

The only niche that Rust is particularly appropriate in is "SJW-dominated cult language".

The only thing worse than SJWs are anti-SJWs.

Re: Haskell and C++ programmers are different.

[tigersha]

Same here

Re:Haskell and C++ programmers are different.

[Anonymous Coward]

Most likely meant his rants on C++ on his command center blog: https://commandcenter.blogspot.de/2012/06/less-is-exponentially-more.html .

Basically C++ is evil because it has feature bloat and things like exceptions^5 and manual memory management. For that reason Pike threw out the last 30 years of progress in language research and produced Go as replacement for c++ (as used by Google)^1. If you think I joke with that 30 year number just look at which languages inspired Go.

^1 Google has no issues with GC pauses in its realtime or embedded applications^2 ^3 ^4

^2 At the time Pike claimed possible support of embedded platforms in an interview Go still ran out of memory on anything with less than 64 bit address space.

^3 It also had a stop the world conservative GC.

^4 Just guess how many embedded CPUs it supported ( x86, x64 )

^5 Go added panic/recover after the fact to serve as exception like error handlign mechanism. Its style guide even makes it perfectly clear that you shouldn't panic unless its for an error you "cannot handle" and to "always handle" any panic internally as its not supposed to pass library boundaries. So its a near copy of exceptions right down to how schizophrenic some developers are about their correct use for error handling.

Re:Haskell and C++ programmers are different.

[serviscope_minor]

There:

https://commandcenter.blogspot...

Basically he's throwing a bit of a strop because C++ programmers didn't flock to go.

html

[Anonymous Coward]

html and javascript, by very far, because of the sheer quantity and rush to publish. css too.

Conclusions only valid on Open Source Projects?

[mykepredko]

This is an interesting study, but I don't know if the results can be extrapolated to include closed source software.

My problem with this is that I don't see any evidence of:
a) Projects in the study have a published project plan with somebody managing it at a high level (I would think the Linux Kernel could be thought of as having a plan with strong central management ). I tend to believe that projects in which multiple individuals (with varying levels of understanding of the software, the app's background and issues experienced during development) would be at a much lower quality level than something managed by a strong, continuous team - this doesn't seem to be a consideration when I RFTA (popularity of projects seems to be a bigger issue).
b) Different development tools used by different developers. In terms of the C/C++ typing issues, Windows software developed and built in Visual Studio, Eclipse Text Editor with MinGW or something like Komodo Edit with Cygwin and user written make files will identify different typing issues and may generate code that works differently, especially in regards to identifying and handling typing issues. I would like to know how many bug fixes are the result of something that isn't flagged and works fine on VS and doesn't work when built in MinGW, leading to a fix.
b.1) I'm not 100% sure of the methodology used in this study, but wouldn't a file that originally had tabs for indentation that an editor automatically changes it into spaces be misidentified as a "fix" if it's uploaded back into the repository? This is a combination of b) and c).
c) Different coding styles. I know of several Open Source projects in which a developer has re-formatted code simply because they don't think it's in the "correct" style and they have difficulty reading it resulting in them changing it so they can follow it better. To be fair, I'm sure a lot of us have done that because some people have very different and strongly felt ideas about how code should be formatted.
d) Lack of formal testing methodologies. I don't think many Open Source projects have strong, automated regression testing processes and methodologies before allowing a new release.
e) Difference in functional use of different languages. I would think that methods written in C, C++ and Objective C would be providing more low-level functionality than Clojure, Haskell or Scala. Ruby probably fits somewhere between the two groups.

Comments?

Re:Conclusions only valid on Open Source Projects?

[Anonymous Coward]

"re-formatted code" - the format can be changed with a little program called indent. There is no need to reformat code manually. Many projects run code through indent automatically, before it is checked in.

*Difficulty of task*

[Anonymous Coward]

More like difficulty of task.

If your coding in C, you can pretty much guarantee you're doing something low level, complex threaded and difficult.
C++ and it could be some major app.
If you're using a nice fluffy wrapped language, it will often be used for some office 'form' style application.

The idea that bugs stem from the programming language and not from the complexity of the task being tackled is bogus.

The actual problem languages

[Anonymous Coward]

A good try, but not quite. The actual top 5 languages that are used to produce the most buggy products:
1) Javascript
2) C++
3) PHP
4) Javascript-based fameworks
5) Anything used to write an Excel or Word macro by the HR department

Re:The actual problem languages

[Anne Thwacks]

1) Javascript
2) C++
3) PHP
4) Javascript-based fameworks
5) Anything used to write an Excel or Word macro by the HR department

This is an unfair comparison: PHP specifically targets producing buggy products, and in the unlikely event that an HR compartment gets anything to work, it is even more unlikely to involve a computer.

Re:The actual problem languages

[vtcodger]

Do javascript problems actually get fixed? Based on my experience with our ever deteriorating Internet, bugs in javascript "programs" live on forever.

Re:The actual problem languages

[Anonymous Coward]

You sound like someone who doesn't know anything about JavaScript. Never used the language to develop an app. Maybe you haven't developed anything. You've just got experience with "the Internet".

They's all equal

[Anonymous Coward]

The only difference is when,or if, the bugs are found.

Re:Which Prisons are prone to Trump associates?

[Anonymous Coward]

At the end of a noose, hopefully.

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:Python

[vtcodger]

I don't think Python's name resolution is a major source of bugs. But I don't disagree that its name resolution sucks. At least for me using Python 2. I've always assumed that the problem is that I'm too damn dumb to understand whatever brilliant scheme underlies its name resolution/namespace logic.

Re:Python

[Just Some Guy]

In Python, static checkers like pylint and flake8 are astoundingly useful for finding the low hanging fruit you've described. I have both wired into Emacs so that potential errors are syntax highlighted. If you're writing Python and not doing the same, you're doing yourself a disservice.

Re:Python

[Anonymous Coward]

Isn't that by design? Something something late binding

Re:Python

[phantomfive]

There's another study that backs up your point, and finds that it could cause up to 15% bugs.

Re:Python

[Anonymous Coward]

That "brilliant scheme" is that it's fully dynamic. If you see "class Foo", what do you think? I hope you don't think "class definition", because it's actually a statement that is executed at run-time to define a class. Yes, it's crazy like that. This is also why you don't need a precompiler; for example, you just wrap this "class Foo" in an if, and lo presto, your precompiler. Same for import statements, they're executed at run-time.

You cannot have smarter name resolution without sacrificing this dynamicity/dynamicness/whatchamacallit :D

Re:Python

[Walter White]

The first time I tried `pylint` it produced gobs of messages that all seemed to relate to style more than potential problems. That was the last time I tried pylint. There are probably settings/flags/options that make the output more useful but at the time I didn't have the patience to research that at the time. My usage of Python is best described as 'light scripting.' I don't know if it warrants the effort to use some of these tools.

I just tried it again on a 64 line script. Either I'm really bad with white space or `pylint` authors are obsessed with white space. But it looks like the output has been reformatted and it might be useful. (15 comments about white space and style for constants before the first real warning.)

Re:Python

[Just Some Guy]

You can safely turn off the style stuff. That said, it's there for a few reasons:

• It's nice when everyone formats their stuff similarly. You can open a file from Joe Stranger and expect it to look a lot like something you've personally written. This reduces the cognitive overhead of coming up to speed with new code.
• Although it's generally not possible for Python formatting bugs to invisibly change the code's meaning, it's easy enough to be consistent.

Re:Python

[Sniffy2]

all dynamically-typed programming languages have this 'flaw', not just python

age of code

[jarkus4]

Did they control for age of code? For older code you are likely to get more bugs as it becomes more likely no one exactly remembers how it works and the person modifying it introduces some logic error for a weird corner case. Theoretically tests should prevent this, but most projects lack this kind of comprehensive testing and usually just have main case scenario covered with perhaps some common special cases.

Re:age of code

[chrism238]

True, but equally true that older code has been exercised for far longer, and may have been reviewed by many different people.

Re: age of code

[Dausha]

FTFA:

"Project age is included as older projects will generally have a greater number of defect fixes; the number of developers involved and the raw size of the project are also expected to affect the number of bugs and finally the number of commits is bound to."

Short Answer

[Anonymous Coward]

Why, ALL of them!

APL Still A Write Only Language

[Crashmarik]

source http://wiki.c2.com/?AplLanguag...

[6] L(L':')L,L drop To:
  [7] LLJUST VTOM',',L mat with one entry per row
  [8] S1++/\L'(' length of address
  [9] X0/S
  [10] LS((L)+0,X)L align the (names)
  [11] A((1L),X)L address
  [12] N0 1DLTB(0,X)L names)
  [13] N,'',N
  [14] N[(N='_')/N]' ' change _ to blank
  [15] N0 1RJUST VTOM N names
  [16] S+/\' 'N length of last word in name

As mangled as the above if you look at source link with it properly formatted with the correct characters it isn't any better.

Re:APL Still A Write Only Language

[Crashmarik]

Actually thinking about it, it was always easier to just code a new function than try to read someone else's old stuff.

Obviously

[Anonymous Coward]

The ones that attract crap programmers

Line to line, ...

[Anonymous Coward]

INMHO, the NASA needs 0-bugs applications.

None of the current programming languages is optimal to provoke 0 bugs.

Languages aren't error prone. Programmers are

[aglider]

The base concept is bulls**it on its own.

It's more like spoken or written human languages to me:
You need to study, learn and practice before being proficient.

If you think that you need a fast solution, then the language you know the best is among the right solutions.
Assembly isn't more error prone than English.
It just depends whether you are or not an idiotic programmer or a easy-going speaker.

Re:Languages aren't error prone. Programmers are

[TemporalBeing]

The base concept is bulls**it on its own.

It's more like spoken or written human languages to me: You need to study, learn and practice before being proficient.

If you think that you need a fast solution, then the language you know the best is among the right solutions. Assembly isn't more error prone than English. It just depends whether you are or not an idiotic programmer or a easy-going speaker.

Correct. No one language over another is more prone to bugs; it's the maturity of the programmers writing the code. Mature programmers won't have memory issues in C, C++, etc; immature programmers will have all kinds of bugs in any language - even memory errors in Java.

"Errors should never pass silently"

[munch117]

Python program can be very self-diagnostic. Something goes wrong, it presents as an exception traceback from an uncaught exception.

A lot of bug reports I get go like this: Someone sends me a screenshot with a traceback, I look up the line of the error, find that the error is obvious, fix it, commit the fix, and I still have time for a cup of coffee before 5 minutes have passed. The reporter may not be happy because they can't get on with their work until I cut a new version, but other than that this sort of bug is of very little consequence: no data files have been corrupted or anything like that.

Then there's the other kind of bug, the subtle kind where everything seems to be working fine, but someone checked the output and it just isn't right: the totals on the report don't add up or something. These are the hard ones. And then you have to dig in and hypothesise and experiment and bisect and so on. Of course those bugs happen in Python programs as well.

But I bet the kind of bugs that put Python over average are the first kind, and that Python is below average on the second kind. Which is a good tradeoff.

Re:"Errors should never pass silently"

[Anonymous Coward]

You're right that when a program doesn't do what it is supposed to do the bug is somewhat more severe than when you simply get hit by an uncaught exception. The latter kind can be attributed to mere sloppy coding, the first can be attributed to sloppy thinking and a severe lack of understanding of the problem domain.

For the user, both bugs result in the same conclusion: The program is broken. This has nothing to do with the language you use. Tracebacks are not exclusive to python, maybe the lack of compile time checks is, but that doesn't make a lot of difference.

A good programmer can handle his tools and solve problems correctly.

Re:"Errors should never pass silently"

[Ihlosi]

Then there's the other kind of bug, the subtle kind where everything seems to be working fine, but someone checked the output and it just isn't right: the totals on the report don't add up or something.

Even worse are horrid bugs (think "buffer overflow") that in practice result in minor performance degradation (still well within the requirements).

Or, my favorite so far - using an unitialized variable that by complete coincidence is always zero at this point in this compile run, and zero is the value that it was supposed to be initialized to. It's an obvious bug in the source code that completely fails to manifest in any way - at least in this binary.

Re:"Errors should never pass silently"

[Entrope]

No, that is a shitty tradeoff. If easily spotting a bug when someone tells you where to look is the most common situation, you are writing too much obviously bad code, and you should look at every line you write as a possible bug and write more (or better) unit tests.

In the group I work with, if you look at code that gets committed to shared repositories, the most common Python errors involve runtime detection of errors on code paths that only run in uncommon situations: in particular, use of undefined function or variable names, and putting a string-typed value where a number-typed value is expected (or vice versa). Statically typed languages avoid both of these problems, and loosely typed languages mostly avoid the second problem. Type confusion errors are often hard to trace their origin because the wrong-typed value can be passed through a long chain of function calls and storage.

Particularly annoying is a functional-style programming habit where my coworkers use tuples to hold strongly structured data, apparently mostly to avoid defining a class. They seem to think it is overall cheaper to write foo(1) than to write foo.job_id.

Re:"Errors should never pass silently"

[Anonymous Coward]

Mod up. The GP is obviously not writing unit tests, or ones that have very low coverage.

So at face value the GP's post is definitely not insightful. But it is insightful insofar as it's a good indicator for programming newbs. If they see that trend happening with their programming, they must change how they do things if they want to become a professional programmer.

Re:"Errors should never pass silently"

[munch117]

In my line of work, silently computing the wrong value could easily cost my company millions. A minor production stop is manageable, but delivering bad product unnoticed is a disaster. So for me it's a good tradeoff. YMMV.

Statically typed languages often have some sort of default value system, e.g. default-construction in C++. I see that as an unacceptable risk: If I ever try to use the value of a variable that has not been explicitly assigned, then I want an error trap. I do not want the number zero, the empty string or an empty container object to be quietly and misleadingly supplied.

That's what a lot of the AttributeError's in Python are: Indicators of bugs that might have passed silently in a different language. Including some (but not all) statically typed ones.

As for NameError's, that's a tooling issue if you get those.

Re type confusion: yes, that can be annoying, and if you are dealing with undisciplined Python writers who never specify types in interfaces, then I understand how that can be a problem for you.

Re:"Errors should never pass silently"

[_merlin]

A mistake in my line of work can cost millions in seconds. If you want a program to blow up on accessing an uninitialised member in C++, use boost::optional (or std::optional if you're using C++17), or a dynamically allocated object so it'll fault on a null pointer access. In python, an attribute error could be caused by a typo, incomplete refactoring, or an API change that you didn't deal with properly, besides a value being used before it's initialised.

At any rate, this is the kind of thing that you should be capturing in unit tests, and if you're getting it in production, you're not the kind of person I'd want working on software where mistakes cost money/lives.

The problem with relying on disciplined developers to specify types in interfaces is that it breaks down in the real world. Everyone's subject to time pressure, stress, and other reasons to compromise. There's also nothing enforcing the types specified in the interface, and there's nothing enforcing the interface provided by those types. You really need 100% unit test coverage to ensure every code path accepts/yields the specified types. C++ at least ensures you can't inadvertently supply/return an unexpected type before you even get as far as running the unit test.

Re:"Errors should never pass silently"

[munch117]

If you use boost::optional for every single declaration you make, then you get the same type of runtime errors as in Python. Except with lower quality tracebacks. I expect you don't, and my point stands.

Re:"Errors should never pass silently"

[_merlin]

You can't see past the limitations of your favourite tool. In C++ or other sane languages, a lot of things can be scoped so they can't be used before they're initialised. You get an error at compile time rather than having it blow up when code path is hit in production. You actually get tools to reduce mutable state, which allows for better optimisation as well as identifying a whole class of errors at compile time. Functional languages (e.g. Erlang or F#) do this even better. Your whole point seems to be that you use Python's exception tracebacks (which are no better than Java or C++ with symbols) to compensate for inadequate unit testing and not being able to control scope.

Re:"Errors should never pass silently"

[munch117]

Having tools so that you could in theory do something is not the same as actually doing them.

Are you telling me that in your programs there are never any variables that are default-constructed, pending later acquisition of the proper value?

If that is so, then you are remarkably ... disciplined. Like it or not, you are relying on disciplined developers. But then I knew that as soon as you mentioned "C++".

Your whole point seems to be [...]

No, my whole point is that I believe that a relatively large proportion of the Python bugfixes measured in the article are for bugs that are relatively innocuous. That's all. Then you took the opportunity to attack my competency, because apparently someone can't disagree with you on the internet without being incompetent, but that's your problem, not mine.

Perl?

[Anonymous Coward]

Perl is in there on the low side with the strictly typed languages. I guess this is because in perl no one can actually read the code in order to work out the bug later - hence a win for minimizing bug fixes.

Re:Perl?

[OzPeter]

Perl is in there on the low side with the strictly typed languages. I guess this is because in perl no one can actually read the code in order to work out the bug later - hence a win for minimizing bug fixes.

Nah .. its' because even if you pound on the keyboard with sheer frustration at Perl EG %&%^@$#&%^&(* you still produce a valid program that solves a problem.

Rust

[Anonymous Coward]

Add the Firefox code base to the study and you will see that the correct answer is Rust.

Re:Rust

[Anonymous Coward]

Rust is very quickly becoming THE answer. Competitive in speed with C/C++, relatively readable as long as you understand basic coding concepts being used, compiler that keeps track of the tedius stuff humans are most likely to fuck up, and safety as the baseline where you have to use extra keywords to explicitly request less safety rather than trying to tell programmers to use best practices. It can even use anything that has a C ABI.

Honestly the worst part about the language is the Code of Conduct, and that only applies in their official channels. Oh no, I can't be a dick when speaking in public.

Stupid comparison.

[Qbertino]

Comparing PHP with Scala is like comparing "Game of Thrones" with "Ulysses".
Any n00b can program something useful in PHP within an hour. That's the whole point of PHP. That's why we have such amazingly feature complete systems like WordPress. Given, the architecture of these PHP systems is so bizarre any reasonably seasoned programmer will not believe his eyes when he looks at the actual code - but it does work (most of the time) and it is useful.

Scala is a programming language that forces you to know what you are doing. Yeah, no shit it has less bugs. If I don't know what a JVM and what bytecode is, there is little chance I'll even get started with Scala. Only an experienced Programmierung will get the point of Scala in the first place. Thus Scala code has less bugs. No surprise here.

My 2 cents.

Re: Stupid comparison.

[Anonymous Coward]

To mention PHP an amazing in the same sentence speaks to the level of insanity in the author. OMG

Re: Stupid comparison.

[Anonymous Coward]

You even have bugs in your 1 sentence comments. Maybe you should calm down kid.

Re:Stupid comparison.

[Tenebrousedge]

You apparently know little about PHP. That may or may not be a terrible thing, but holding up WordPress as a piece of the PHP ecosystem is unrepresentative, even disingenuous. It was obsolete when written and it can never be meaningfully improved. It's its own self-sustaining ecosystem that has nothing to do with anything written in PHP in the 15 years since then.

Modern PHP looks a bit like JavaScript, actually, and the frameworks are all very boring MVC. It's also (somehow) one of the faster scripting languages out there. You should update your prejudices.

Re:Stupid comparison.

[iggymanz]

You know little about the real world, the majority of web frameworks that use PHP such as drupal are badly written garbage. It is the language of the careless, the language used by builders of sites that get infected and that spread malware and cause identity theft.

PHP developers are like those that join the school band and want to play the triangle, blocks or cymbals.

Re:Stupid comparison.

[Tenebrousedge]

Mentioning Drupal can be taken as an indication that you know nothing about PHP frameworks. You are simply displaying your prejudices.

Re:Stupid comparison.

[iggymanz]

take it as an indication that I have to deal with their incompetent code, the security breeches, data corruption, and resource problems they cause every fucking working day

Re:Stupid comparison.

[Tenebrousedge]

If you work in an organization that used obsolete frameworks like Drupal, then you deserve what you get.

Re:Stupid comparison.

[iggymanz]

uh huh, but make a list of the top CMS systems and you find the top three and their market share is 60% Wordpress, 6% Joomla, 4.5% Drupal.

Re:Stupid comparison.

[Tenebrousedge]

Weren't we talking about frameworks a minute ago? Joomla and Drupal are dead projects. I don't know why you're crying up a 4.5% market share. Well, except that you seem to be an idiot with an axe to grind.

Re:Stupid comparison.

[Anonymous Coward]

Huh? Joomla and Drupal have hardly lost any market share in the last year, and they're both near the top - Wordpress is still far and away the biggest contender.

https://w3techs.com/technologies/history_overview/content_management

Re:Stupid comparison.

[Tenebrousedge]

Framework != CMS, and I don't know how you can look at the clear downward trend for both of those and say, "Looks fine to me!", but the leaders of both of these projects are pretty well aware of the ground they've lost, and neither has the manpower to modernize their codebases. Search around for, "Jooma/Drupal dying" if you like, or you can take my word for it on the technical issues. I don't care to explain in detail because they're terrible and no one should even think about them.

Re:Stupid comparison.

[Anonymous Coward]

Yeah, but market share is not a good measure in an expanding market. If Joomla and Drupal add 1000 sites each but Wordpress adds 10,000, their market share can decline whilst the installed sites increase.

Anyway, I don't see any evidence that they are "dead projects" unless you count the 90% of smaller systems dead as well.

It's pretty clear nothing has a chance against Wordpress, and that won't change until someone clones it with another technology that's 1) F/OSS, 2) as easy to set up and use, and 3) has an army of developers readily available.

One poster replied to me once saying there's no excuse to use Wordpress/PHP when Django is freely available. Don't make me laugh.

Re:Stupid comparison.

[Tenebrousedge]

By whatever measure you want, they're dying. Ignore the writing on the wall all you like. And like I said, I really don't want to get into their technical issues, but neither project is particularly compatible with the rest of the PHP ecosystem or with modern workflows, and they're not likely to ever become so.

Now if we're done saying ignorant things about PHP, I have to go do some ritual cleansing and atonement for defending it.

Re:Stupid comparison.

[Anonymous Coward]

> By whatever measure you want

You're pointing to how many questions are tagged on SO as if that's a relevant measure?

Re:Stupid comparison.

[Tenebrousedge]

No, I said pick your favorite. Being willfully dense is just going to get you ignored.

Re:Stupid comparison.

[Anonymous Coward]

> No, I said pick your favorite.

You said "whatever measure you want" and then linked to one YOU picked.

Drupal's own metrics show it holding pretty steady, not on the decline. It's under active development and active use, so I don't see any obvious reason to say it's dead/dying.

Joomla I don't use, so I don't really care about it.

Re:Stupid comparison.

[Tenebrousedge]

Holding steady meaning no new installations? Gotcha. We'll ignore those little downward trends too.

Re:Stupid comparison.

[Anonymous Coward]

Obviously some new installs, some going away... but once they passed a million they never dropped below it.

No Bugs, Only Features

[Anonymous Coward]

I do not believe in bugs because software is never finished. Now, on your knees Earthling !!

Invalid conclusions

[Anonymous Coward]

Every child knows that PHP projects are prone to security issues like no other language. The study however concludes otherwise. This alone shows the study's methods are flawed and the conclusions invalid.

Re:APL Still A Write Only Language

[vtcodger]

For whatever reason APL always reminds me of Arthur C Clarke's classic story "The Nine Billion Names of God." If anyone ever writes a readable APL program perhaps the stars in the sky will, without any fuss, go out.

C, Perl, PHP, JavaScript, C++

[ReneR]

$subject says all, in that order, Not counting auto* script clusterf*ck ;-)

Re:C, Perl, PHP, JavaScript, C++

[serviscope_minor]

Not counting auto* script clusterf*ck ;-)

Are you complaining about the auto keyword or is "auto script clusterf*ck" some sort of distributed brainfuck?

Re:C, Perl, PHP, JavaScript, C++

[gwjgwj]

Not counting auto* script clusterf*ck ;-)

Are you complaining about the auto keyword or is "auto script clusterf*ck" some sort of distributed brainfuck?

automake and friends, I suppose.

Re:C, Perl, PHP, JavaScript, C++

[serviscope_minor]

Oh I see.

I rather dislike automake. Gnu Make plus autoconf is fine though. Mostly autoconf gets a bad rap from very badly written scripts.

typing

[KeithConover]

As a long-time but hobbyist programmer (started with machine code before moving to A86 assembler), I found the discussion thoughtful and illuminating. I will therefore offer a snide comment that may contain a grain of truth, based on something I heard when I first began to code, but updated a bit. "Strong typing is for weak minds. But coders overestimate the strength of their minds."

Re:typing

[f00zbll]

That was clearly spoken by someone that writes "new" code and doesn't have to maintain other people's code :)

Anyone that does integration work and has to glue together a dozen different systems written in a variety of languages will lean towards strong typing. Most of my co-workers that start out favoring weak-typing or duck-typing quickly realize maintaining code written by multiple people in weak-typing is a nightmare. Especially in an enterprise environment where every project "should have been delivered two months back". Quality is at the bottom of the priorities and you get shit code. At least with strong-typing, there tends to be fewer errors and the shit smells slightly better. Not that it ever smells good, but slightly better is still better.

Re:typing

[Jeremi]

I'm pretty sure the "weak minds" quote was making an implicit argument for strong typing, not against it.

Whatever is used by inexperienced programmers...

[Anonymous Coward]

In general, it will be whichever language is used most by new, barely literate programmers.

Language or problem domain?

[Anonymous Coward]

Languages don't exist in a vacuum –they are designed to solve a specific type of problem. Choosing a language unsuited to the problem domain is a highly common programming error, particularly for novices. I would have thought a better question would be the incidence of bugs related to a specific problem domain, e.g. applications, database, web, systems, embedded etc. I think you would find some domains have higher incidence of bugs related to the demands of the problem, hence the language is not really the cause.

High level languages

[Anonymous Coward]

The results of this research can be explained in part by the "level" of the language being studied. High level languages, if designed properly, are less prone to error. Example: SQL. There is less coding involved. Coding details are reduced. Typing is more intuitive. Sometimes a data dictionary is used to relieve the burden of typing, as in the case of SQL.

The problem with high level languages is that you can't do tricky jobs with them.

Linux and gcc could never be written in a high level language. Imagine writing Linux in lisp. Therefore the ultimate result of this research, is that a language is chosen to best suit its task. If you can get away with loose typing go for it. If you want efficiency of execution, write in assembler, but expect more coding errors and more commits in your repository.

Re:High level languages

[K. S. Kyosuke]

Linux and gcc could never be written in a high level language. Imagine writing Linux in lisp.

Ehm...not sure about Linux, but wouldn't GCC in Lisp be merely extending the MELT framework and the RTL syntax into the rest of the compiler?

Re: High level languages

[tigersha]

I have written a compiler in Prolog, and I assure you it was better than writing it in C.

Verifiable testament to Delphi Object Pascal

[Anonymous Coward]

See subject & not 1 bug found in APK Hosts File Engine 10++ SR-1 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/ since it's release in mid 2012 to date!

(Does Delphi have bugs? Maybe - but I haven't seen any to date in MY WORK + neither have my unidentifiable anonymous (or fake name using) 'troll naysayers' here on /. - lol, which I bet BURNS THEM UP to NO END!)

APK

P.S.=> Proven since Delphi's release in 1995 16-bit, thru 32-bit into 64-bit currently across every major platform there is https://www.embarcadero.com/products/delphi/ as it does all the majors & pretty much every kind of development there is (& no C buffer overflows possible in Delphi strings - Delphi doesn't use null terminated strings & has stringlength built-in to strings)... apk

18 years worth of code?

[SpinyNorman]

That in of itself makes the results next to useless.

In particular, considering C++ pre 2011 and after (c++11) as the same language from a prone-to-bugs POV is ridiculous. Sure, since it's backwards compatible you can continue to shoot yourself in the foot like it's 2010 (or 2000 - sheesh!) if you really want to, but if you're using C++ nowadays and having problems like memory leaks or dangling pointers then YOU are the problem, not the language.

I'm sure other languages have similar issues - if you don't use the latest features put there to help you, then who's fault is it?

This summary also makes me question the methdology:

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."

Seems a bit suspicious that it's all the widely used languages, regardless of whether they are low level systems programming languages like C/C++, or high level scripting languages like Python, are per-their-way-of-measurement, more buggy than all the way more obscure ones such as Clojure, Haskell, Scala...

Shit. I think I've been trolled.

Re:18 years worth of code?

[Entrope]

Well, they are using data from GitHub, so even though some of the projects go back 18 years, the projects should all be fairly well-maintained. However, the study's authors give no good reason to think that the kind of linear regression they use is appropriate. Even assuming a linear model is appropriate, their choice of variables seems arbitrary. For example, why is "log of project age" the right parameter to use, rather than some quantized version of age, or the square root of the age? Did they choose those by exploratory analysis (p-value fishing)?

good tinder for a flaming post war

[v1]

This is one of those flamebait topics that is basically pointless to debate. It's too general. There are too many ways to define a bug, and many of them depend heavily on indirect/abstract qualities of the language, such as what sort of people use it or what sort of problems it's most commonly used to solve. It's just impossible to remove enough of the unknowns and side-effects of one sort of bug to give a useful answer on any other.

For example. if you're going to judge a language on the code-to-fix ratio of commits, does that tell you how prone the code is to having bugs in the first commit, or how easy it is to find and commit fixes? Those two alone say very different (and somewhat opposite) things based on the same metric measurement.

I'm only going to scratch the surface here and try to list off a few of the things you could say make a language "more buggy":

- typical user has below-average coding skill in general
- typical user doesn't follow standards well
- poorly defined standards
- hides bugs with coercion, ignoring return values, and other methods of ignoring behaviors which could easily be either a shortcut or a bug
- scope is wide or unbounded (a very relative metric)
- tends to be used to solve more complex problems
- used in new fields where users are less educated in the problem they are trying to solve
- poor debugging feedback
- poor quality crash dumps
- poor quality of available or more commonly used compilers
- compiles directly to target platform rather than using an established post-compiler
- use of optimizers that haven't undergone rigorous testing (edge-bugs in optimizers are a PAIN to debug)
- poor documentation / built-in help
- average reliability of most common target platform

Even with this limited set, I don't see how you could assign weights to be able to get any more than even a rough comparison between two languages. I think I could compare any two languages and make a case for either being better with regard to bugs. (and instead of you suggesting two for me to try, do it yourself... take those two you have already jumped on after reading that last statement and go try for yourself instead of challenging me)

Re:good tinder for a flaming post war

[Anonymous Coward]

The article has real data in it. We can discuss the methodologies, but it is difficult to reasonable ignore the results without some data. Feel free to ignore posters who don't have facts to back up their claims.

It's fair to look the data and methodologies and provide an alternate interpretation, but that's hardly a flamewar.

third party libraries...

[Anonymous Coward]

I'd say any that use third party libraries you have limited control over. Last several sets of bugs I've run into have popped up when using them in multi threaded environments.

GTA III

[epine]

But I bet the kind of bugs that put Python over average are the first kind, and that Python is below average on the second kind. Which is a good tradeoff.

It would be no different in C++ with end users programming in the modern idiom on top of mature application libraries that support and encourage the modern idiom.

C++ is the GTA III of programming languages.

cout << "Open, world!" << '\n';

Let's look at programmers

[plopez]

Looking at programming languages is good but this report implies there are other factors more important at play. What is the demographic of a good programmer? What is the marker of a good programmer who does not produce bugs? Ivy league vs. "Scheme certificate in 90 days" training programs? Wyoming programmers vs. California programmers? Just graduated 20 somethings vs. 50 year olds? Traditional CS programs vs. explicit software development training programs?

We all have our biases, but let's see what, if anything, pops up.

Re:Meanwhile on Slashdot..

[Anonymous Coward]

Poor wittle snowflake. Do you need a safe space?

Toying with languages vs professional use

[OrangeTide]

While there are professional Haskell programs, there are lots of amateur projects on github that don't get much love from the authors. There is certainly a real effort to filter out the many small and insignificant projects, I feel that someone learning Haskell that is a bit obsessed with lots of small git commits can create a large enough commit history to get through the survey's attempts to gather statistics on different languages.

Basically I think the differences between the languages can be explained by the differences in the behavior of the people who are drawn to those languages.

A moderately experienced programmer with a methodical approach should be able to write code with few bugs and detect and address those bugs quickly, no matter which language they use. Of course carefully writing your web blog back-end in Brainfuck is a lot more work than doing it in PHP and I'd expect it to take a lot longer time. In terms of quality it's hard to quantify it based on language alone, except perhaps in very large projects with many contributors.

Short list:

[Anonymous Coward]

Any language coded by humans.

Ones coded by AI simply have unexpected features.

C, C++, Visual Basic, Javascript

[Anonymous Coward]

Let's start with a total anti example: Haskell. People who can figure out how to do _anything_ in Haskell are bright enough not to write too many bugs in it. Every wannabee codemonkey and his dog play with Javascript, or before that, VB. Then C and especially C++ excel in giving you myriad ways to hang yourself whilst simultaneously (provided there are enough cores available) shooting yourself in the foot and hanging yourself with more rope than a rock climbers convention.

Only One Language to Rule Them All...

[Anonymous Coward]

"Goat C" is the only Internet language you need to learn.

Some Errors are not Programming Errors

[Anonymous Coward]

You are describing the difference between "Programming Errors" & "Logic Errors". The first kind of error raises a Python exception and is obvious to the interpreter. The other kind is an algorithm logic error.

Python (and every other programming language out there) cannot detect logic errors for you. When "the totals on the report don't add up or something", your math is wrong. Python can't tell you to makeyour FOR-loop iterate 10 times instead of 100; it's not AI.

As a programmer, what I do is this:

[hey!]

convert problems I don't know how to solve into problems I *do* know how to solve. That's what programming is.

So using that methodology, I have to ask here: which programming languages are the most popular?

Re:As a programmer, what I do is this:

[Anonymous Coward]

So using that methodology, I have to ask here: which programming languages are the most popular?

Define "popular" ...

Does that mean "get the most queries on how to use them on twit boards like StackOverflow"?
Does that mean "have the most projects written in them on (pick your suppository)"?
Does that mean "used the most by kiddy-coders?"
Does that mean "used in the most 'Learn to Code in 30-days' courses found on Matchbook covers"?
Does that mean "used fluently by the most programmers over 50 years of age"?
Does that mean used in "large line-of-business applications"?

All of these definitions have been used in one of more "popularity" contests. And each of them yields different orderings and languages.

Re:As a programmer, what I do is this:

[Anonymous Coward]

This reminds of an old story (that is probably not true -- but should be).

A Consultant was hired to debug an "issue" in a huge COBOL program. The Consultant laid out the huge printout of the code in a Conference room with glass walls where everyone walking past could see the code. The CEO walked by and complained that "the company jewels were on free display" and anyone of the customers and competitors could read the code. He then proceeded to give the Consultant crap about the display remarking "And what if someone walking by reads and understands the code and steals our business?" To which the Consultant replied "Hire him immediately and pay him whatever he wants. Anyone who can figure out how this crap works with just a view from the reception desk is worth his weight in Gold."

Using this metric, Perl wins

[Anonymous Coward]

Perl would have the least number of defect fixes per LOC b/c nobody, including the original programmer, can understand the damn code.

I've tested software for over 25 years...

[gestalt_n_pepper]

And the most buggy software is always C, C++, Objective C or anything else that encourages a human to manipulate pointers and/or memory.

Most buggy framework? WPF, by far. I haven't had to test UWP yet, but it looks like an even bigger, overly elaborate clusterfuck.

Sometimes newer is not better. I despised MFC, loved Winforms, which is inflexible and dull as dishwater, but simple, obvious and easily testable (everything Microsoft appears to hate). It's all been downhill after that.

And don't get me started on ASP. I'm pretty sure the rise of the recent spate of rather nicely designed javascript frameworks happened because the ASP collection ranges from mediocre to Godawful.

Re:I've tested software for over 25 years...

[david_thornley]

Modern C++ doesn't encourage manipulating pointers and/or memory. You can do it, but there's usually better ways.

Language never mentioned in comparisons

[eliphalet]

I'm stuck using MS PowerShell at work, but PowerShell never appears in these reports about popularity, bug avoidance, etc. Not sure whether it is low usage, type of projects, or that it's for Windose.

Quantity versus quality

[Big Bipper]

This survey can't tell us anything about how hard it was to find those bugs ( time between reporting and fixing ) though. That would be a very interesting statistic if it could be produced.

The one you use

[Anonymous Coward]

Bugs are the product of humans.

Don't forget the bigger issue.

[Anonymous Coward]

Only GNAT can compile GNAT, and this has been true since the early 90s.

There is the original NYU 'teaching compiler' which is written in C and compiles ada83 to an interpreter/virtual machine, but the vm/compiler doesn't compile cleanly on modern hardware, and having made an effort to port it, even once you get it compiling it has other logic errors that caused it to crash.

In order to have GNAT make any sense at all as a member of the gnu compiler collection, it really needs a bootstrap compiler written in C which can provide a formally verifiable subset of ada, which in turn can be used to compile the GNAT build tools, which in turn can be used to compile the full GNAT compiler suite on top of GCC. This is a very similiar complaint I have to Rust. We are supposed to *TRUST* that the single-source binary compiler is not backdoored, even though it has been 20+ years since 'Reflections on Trusting Trust', and yet here we are with people trying to force us into using languages where the compilers inherently can't be trusted due to a single source for the required precursor compiler.

The fact that GNAT was allowed at all in GCC is imho an affront, since every other compiler frontend in GCC required at minimum a C bootstrap mode to begin the compilation process, with the option of using a native compiler if already available. GNAT flies in the face of that before taking into consideration the issues with the GPL vs LGPL core library, which I will note IS actually LGPL or GPL+linking compliant in the GCC suite. However the periodic GNAT releases from GNATCORE or whatever they call themselves are GPLv2 licensed for exactly your stated reason.

Having said all this, even the DoD no longer uses ADA for any newly developed projects, so what does that say about its future prospects as a programming language, without at least a second source compiler becoming available?

Going back to Rust above: There is in fact a second source C++ compiler in the works for rust, mrustc which compilers the normal rust tools and libraries using its own less-advanced C++ based compiler. It is not a 100 percent option yet, but at least it does require you compiling like 10+ iterative copies of Rust in order to be able to leverage the original OCAML compiler implementation which supported Rust 0.14 or something, as well as each successive breaking point for the language which needs the old compiler used to compile the new compiler subset.

The fact that Mozilla considers it acceptable to have a self-hosting only language without a secondary implementation for regression testing and proof of trust makes me assume they are just as malicious as they are inept.

bugs bugs get the raid

[ohgary]

Pretty much any language using libraries that you didnt write are prone to errors. Not properly interfacing with the libraries, just trusting libraries to do everything you need to do or think the libraries are good and bug free.

Not a count of bugs

[Anonymous Coward]

They didn't count bugs, they counted bug fixes. There are fewer bug fixes in Haskell and Clojure projects because bugs in Haskell or Clojure programs are unfixable. Either the program works perfectly on the first try or it is abandoned.

Demonstrating Java is the best.

[sproketboy]

keep crying fagbots

Re:Demonstrating Java is the best.

[ebvwfbw]

Really. Go sit in the corner for 2 hours.

If you haven't learned your lesson, slap yourself 5 times and sit in the corner for another 2 hours. Repeat until you admit your error.

Re:Demonstrating Java is the best.

[sproketboy]

keep crying fagbot

Re:Demonstrating Java is the best.

[ebvwfbw]

Keep crying? It took you 3 days to even respond. Either you were crying from slapping yourself silly or you were sucking your mom's cock before she pegs you again.

Re:Demonstrating Java is the best.

[sproketboy]

keep crying fagbot!

Re:Demonstrating Java is the best.

[ebvwfbw]

Look in the mirror

Re:Demonstrating Java is the best.

[sproketboy]

WAHH

Languages are not prone to anything

[Anonymous Coward]

The problem is simply this: incompetent or lazy programmers.

It's PEOPLE who are prone to bad behaviors, not things that are prone to bad behaviors.

"Fixing" languages is NOT the answer - for every "foolproof" system there's always gonna be a bigger fool who can still screw up. If the "new and improved" languages are in ANY way inconvenient to good programmers, then the net gain is probably non-existent. This is particularly an issue if the good programmers negatively impacted are working on serious and important stuff while the bad ones are working on unimportant crappy stuff like web sites, games, etc.

Rather than fixing/improving languages in a way that is a hindrance to good coders, what is probably needed are much better tools for analyzing and flagging bad/dangerous code. These tools could be deployed frequently and rigorously in an automated manner on projects staffed by bad coders and less-frequently bus as a process gate on complex projects with good coders. By keeping the safety garbage out of the languages, we leave the power there for the special cases where unusual stuff is needed and the competent teams doing it can cross-check their work and sign-off on it as needed.

Interesting, but not especially useful

[cshark]

Here's the thing. It's sort of an open secret. Open Source code sucks. It's always sucked. The only time it doesn't suck is when rigid standards are applied, or you have huge groups of professional programmers working on it. IBM and Microsoft both contribute huge amounts of open source code every year. Most of it is pretty solid, well written by pros.

That's the exception though.

I've worked with hundreds of open source projects over the years, even tried to manage a couple of them. And the reality is that the code that comes in is generally learning code. Stuff written by guys and gals who are picking up the language, whatever language it is for the first time. And that's not bad. It gives them valuable experience on a living app, and it gets me the functionality I want to download and use. Hopefully, without having to redevelop it too much. See, at the end of the day, I'm a pragmatist. If it does what I want it to do, and it doesn't incinerate my hardware or cause my vm to stop responding... I just don't care anymore.

Anyway, that's why you can't depend on open source code, most of the time, for something like this. If you are going to use Github to do it, you're going to need a much larger sample, if it's even possible to come to the conclusions the premise of the survey is trying to figure out. I would be curious to know if projects with only one person on them were more likely to be buggy than projects with active teams. Or if there's a difference in the rate of defects with professional teams vs amateur programmers. I don't think looking at the language itself is ever going to yield anything actionable, but there's a lot of meta around this that could be interesting.

Re:Interesting, but not especially useful

[swilver]

I'll let you in another secret.

Closed source code is just as bad. Software is written by people. Sometimes it is better (as people get paid to make it good) and sometimes it is worse (as there are people working on it that only care about getting paid). Sometimes people don't care about getting paid and enjoy what they do (then it is *really* good).

Re:Interesting, but not especially useful

[cshark]

Oh, absolutely. No disagreement at all.

And Pascal less buggy than Perl....

[Anonymous Coward]

Go look it up.

What would you expect from from somebody who's been designing languages and compilers for decades vs a couple of guys trying to cram a better language into a cheaper computer?

C became more popular because of patent issues.

It was and is the worse language.

Retard APK is too full of himself

[Anonymous Coward]

Hey retard, I've never said your code has bugs.
I have said it is slow, bloated, and overly complex (it is).
I have also said it is ineffective and easily circumvented.
Finally no one asked about your bullshit software as this is about programming languages.
I guess Alexander Peter Kowalski just like to prove he is a retard and a spammer.

Is it the language or the programmers

[lsatenstein]

A programmer is a programmer. Some are born to program, others are programming to implement an idea. Some look at the code as an atomaton, where others just look at code as a set of frequently travelled links, ignoring wrong (you should not do take those traversal states).

You can program badly in any language. If you report C or C++ has having the most errors, its for a few reasons vis:

Most used languages of all the languages is C and C++. As a percentage of bugs reported for number of lines of code, add a new measure, the dimension of programmer's skill, you should find no differences between them and frequency of errors.

C and C++ have advantages of portability, and minimal execution overhead. C and C++ are not going away soon. Rust is a new language which, if you do multi-tasking, has built-in safety / type / decendant call checks for variables that are constant and or mutable. But the number of github entries for Rust is insignificant, when compared to the C's.

I measure the quality of code by the skill of the programmer and inversely proportional to the number of lines in a module.

Re: Whatever is used by inexperienced programmers.

[Anonymous Coward]

Exactly. Programmers write bugs, not programming languages.

You hit the nail on the head.

[Qbertino]

WordPress is an insane mess. The simple task of migration to another domain is nigh impossible with WP. With relatively well built systems such as Joomla it's done in a few minutes.

However, unlike my attempt 7 years ago with Joomla, I've actually manged to make a decent living of WordPress in the last 4 years and continue to do so. Thus I have decided to deal with the mess. It's sort of like bloated ERP Setups. They may be expensive and they may be outdated, but they provide an endless opportunity for stuff that needs to be done and can get billed. ... And at least it is open source.

Bottom line: Count me in on the never ending WP craze.

One thing - it may not be the "language".

[Anonymous Coward]

The thing I notice about this list: the languages with the lower error rates are also the languages that are ONLY pursued and used by the smarter and most able programmers while the ones with the highest rates are the languages of the hoi polloi and first time programmers. The error rate could EASILY be nothing more than "seasoned programmer error rates" vs. "newbie/average programmer error rates".

My code's better than anything you do

[Anonymous Coward]

My code's better than anything you do yourself in code. Prove otherwise "jealous jowie" you do-nothing "ne'er-do-well" talker behind unidentifiable anonymous posts.

APK

P.S.=> It truly must BLOW to be a puny 'jealous jowie' like you, lol... apk

Additionally, quoted /.ers disagree

[Anonymous Coward]

I'm going to continue using the Host File Engine. Your software is well written, functional. The Host File Engine performs exactly as promised by mmell

his hosts program is actually pretty good by xenotransplant

his hosts tool is actually useful for those cases in which one does indeed want to locally block stuff outright while consuming minimum system resources by alexgieg

(APK's) work, I've flat out said it's good by BronsCon

I've tried his hosts file generating software. It works by bmo

APK your posts on this & the hosts file posts, and more, have never been in error &/or bad advice by BlueStrat

Your premise that hostfiles are a good way to deal with advertising & malvertising is quite valid by JazzLad

I like your host file system by Karmashock

(NEED MORE? Ask!)

* It's recommended/hosted by Malwarebytes' hpHosts!

APK

P.S.=> Let's see /.ers say the above on your non-existent programs, lol... apk

Re:Whatever is used by inexperienced programmers..

[KingBenny]

yes well statistics like that (like most actually) are usually pretty much built on incomplete datasets so they show (if at all at least) what 'might' be the common denominator. I could read (without rtfm) that the languages that are around the longest and used most have had more faulty code written over the time period in which they have been used and as you so eloquently say, it doesnt really seem to stat the skill / xp / yearsofservice and knowledge of one or multiple levels per specific dev involved per language per project per number of bugs (lawl) etc... its new year, i guess the news need something to write about but i suppose they read something else

Shouldn't the answer be

[Veretax]

All the ones used by humans? Seriously, the survey taken in this manner is more than likely, biased. Just because someone uses Github doesn't mean they put all their bugs in Github (which skews the numbers), furthermore, its likely that newer languages may be using techniques which allow a lot more bugs, but they get found because of process and aren't being checked in with bugs because of it. Translation, modern methods have a lot more to do with lower bug counts in newer languages, then anything I'd imagine.

Re:APL Still A Write Only Language

[DavidHumus]

Here we go again - people with their eyes closed saying how dark it is.

It's like saying that French is impossible to read or speak when you've never even tried to learn the language.

I've worked several large, complex systems written in APL and maintained by one or two people. I've also seen any number of failed attempts to re-write an APL-based system, usually with teams several times the size of the APL one.

Eye of the beholder

[Tablizer]

What I'm hearing is that you're an idiot who can't handle more than a basic level of abstraction. I suppose those who prefer Java deserve what they get.

What's a "good" abstraction is often in the eye of the beholder. My favorite abstractions have driven others batzo. Generally one has to target something that is likely to be digestible to a typical developer. If you target the elite and/or only others who think like you, it gives the organization fewer hiring choices. It may be great job security for yourself, but it is not pleasant for the organization. Don't be selfish.

Missing Factor

[herbierobinson]

The missing factor here is that they did nothing to factor in the exposure (how many hours the software has actually been used). That has a huge effect on the number of defects discovered. All this could really mean is that C++, C, and Objective-C, also PHP and Python are what most heavily used software written in.