Which Programming Languages Are Most Prone to Bugs? (i-programmer.info) 247
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."
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."
Honorable Mention (Score:3, Funny)
Brainfuck
Re:Honorable Mention (Score:4, Funny)
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: (Score:2)
In before Fractal of Bad Design (Score:5, Interesting)
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: (Score:3)
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: (Score:2)
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: (Score:2)
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 50
Re: (Score:2)
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: (Score:2)
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 (Score:5, Informative)
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: (Score:2, Insightful)
Nope.
http://csapp.cs.cmu.edu/3e/doc... [cmu.edu]
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
Re: (Score:2)
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: (Score:2)
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 (Score:5, Informative)
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: (Score:3)
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
Re: (Score:2)
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: (Score:2)
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 [wikipedia.org]).
Re: (Score:2)
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 [wikipedia.org]).
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: (Score:2)
Re: (Score:2, Interesting)
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: (Score:2)
Re: (Score:2)
Re: In before Fractal of Bad Design (Score:4, Informative)
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/ [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/ [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: (Score:2)
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: (Score:3)
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... [newpascal.org] to lea
2018 (Score:5, Insightful)
Re: (Score:2)
Re: (Score:3)
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: (Score:2)
Re: (Score:2)
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 [wikipedia.org].
"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 (Score:2)
Re: (Score:3)
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 idea
Re: (Score:2)
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.
Complexity (Score:5, Insightful)
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: (Score:2)
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 abo
Re: (Score:2)
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: (Score:2)
Fair enough, I didn't know that. Still, as Meat Loaf said, 2/3 ain't bad.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:3)
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 dif
Re: (Score:3)
1993 just called and wants it C vs. C++ flamewar back.
Re: (Score:2)
Be fair. The argument still made sense before C++11 or so.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:3)
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
Re: (Score:2)
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 (Score:2)
Are there any large Cobol projects out there? I mean this as a question, not sarcasm.
Haskell and C++ programmers are different. (Score:5, Insightful)
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. (Score:5, Interesting)
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: (Score:2)
Re: Haskell and C++ programmers are different. (Score:2)
Same here
Re: (Score:2)
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).
Conclusions only valid on Open Source Projects? (Score:5, Interesting)
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?
Python (Score:5, Insightful)
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: (Score:2)
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 (Score:4, Interesting)
Re: (Score:2)
APL Still A Write Only Language (Score:2)
source http://wiki.c2.com/?AplLanguag... [c2.com]
[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 mangl
Re: (Score:2)
Actually thinking about it, it was always easier to just code a new function than try to read someone else's old stuff.
Re: (Score:2)
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.
Languages aren't error prone. Programmers are (Score:2, Flamebait)
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: (Score:2)
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" (Score:3)
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: (Score:2)
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 t
Re: (Score:2)
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 fun
Re: (Score:2)
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
Re: (Score:2)
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 sho
Re: (Score:2)
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: (Score:2)
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
GTA III (Score:2)
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! [wikipedia.org]" << '\n';
Stupid comparison. (Score:3)
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: (Score:2)
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 lang
Re: (Score:3)
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: (Score:2)
Mentioning Drupal can be taken as an indication that you know nothing about PHP frameworks. You are simply displaying your prejudices.
Re: (Score:2)
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: (Score:2)
If you work in an organization that used obsolete frameworks like Drupal, then you deserve what you get.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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.
18 years worth of code? (Score:2)
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
Re: (Score:2)
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
good tinder for a flaming post war (Score:2)
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 rati
Let's look at programmers (Score:2)
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 an
As a programmer, what I do is this: (Score:2)
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?
I've tested software for over 25 years... (Score:2)
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
Demonstrating Java is the best. (Score:2)
keep crying fagbots
Re: (Score:2)
Re: age of code (Score:3)
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."
Re: Mainstream languages, duh (Score:2)
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
Re: (Score:3)
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 i
Re:The actual problem languages (Score:4, Funny)
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: (Score:2)
Do javascript problems actually get fixed? Based on my experience with our ever deteriorating Internet, bugs in javascript "programs" live on forever.
Re: (Score:2)
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: (Score:2)
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.
Re: (Score:3)
I'm pretty sure the "weak minds" quote was making an implicit argument for strong typing, not against it.
Re: (Score:2)
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 (Score:2)
I have written a compiler in Prolog, and I assure you it was better than writing it in C.