Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Programming Technology

The Effect of Programming Language On Software Quality 217

HughPickens.com writes: Discussions whether a given programming language is "the right tool for the job" inevitably lead to debate. While some of these debates may appear to be tinged with an almost religious fervor, most people would agree that a programming language can impact not only the coding process, but also the properties of the resulting product. Now computer scientists at the University of California — Davis have published a study of the effect of programming languages on software quality (PDF) using a very large data set from GitHub. They analyzed 729 projects with 80 million SLOC by 29,000 authors and 1.5 million commits in 17 languages. The large sample size allowed them to use a mixed-methods approach, combining multiple regression modeling with visualization and text analytics, to study the effect of language features such as static vs. dynamic typing, strong vs. weak typing on software quality. By triangulating findings from different methods, and controlling for confounding effects such as team size, project size, and project history, they report that language design does have a significant, but modest effect on software quality.

Quoting: "Most notably, it does appear that strong typing is modestly better than weak typing, and among functional languages, static typing is also somewhat better than dynamic typing. We also find that functional languages are somewhat better than procedural languages. It is worth noting that these modest effects arising from language design are overwhelmingly dominated by the process factors such as project size, team size, and commit size. However, we hasten to caution the reader that even these modest effects might quite possibly be due to other, intangible process factors, e.g., the preference of certain personality types for functional, static and strongly typed languages."
This discussion has been archived. No new comments can be posted.

The Effect of Programming Language On Software Quality

Comments Filter:
  • Take away for me (Score:5, Interesting)

    by just_another_sean ( 919159 ) on Wednesday November 05, 2014 @09:22AM (#48316707) Journal

    e.g., the preference of certain personality types for functional, static and strongly typed languages.

    My guess is that this has a bigger impact on most projects than actual features of a chosen language. I was thinking it the whole time I read the summary and then, sure enough, it's mentioned as a disclaimer at the end...

    • by jeffb (2.718) ( 1189693 ) on Wednesday November 05, 2014 @09:34AM (#48316767)

      "We aren't saying that functional, static and strongly typed languages are inherently superior. We're just saying that if you don't prefer them, maybe you aren't really cut out for programming."

      • by Z00L00K ( 682162 ) on Wednesday November 05, 2014 @10:36AM (#48317225) Homepage

        So far my preference lies with static strongly typed languages, and from the question of code quality it's certainly helpful.

        However the real strength of static strongly typed languages is when it comes to maintenance. The original programmer knows what he's using, but someone inheriting an old code base will need to put down a large amount of time to figure out how it's actually built and what a certain type do. A dynamically typed solution tends to be elusive and can change the semantics depending on how it's used, which can range from confusing to outright hilarious.

        • by i kan reed ( 749298 ) on Wednesday November 05, 2014 @10:46AM (#48317303) Homepage Journal

          I'm going to put out an alternate conjecture:

          Interfaces are the magic that tend to make strongly typed languages work well. That, for example, C and C++ don't positively contribute to the trends this article discusses(though I can certainly imagine that people who know how to manage their own memory tend to have a more robust understanding of code).

          The ability to abstractly describe the kinds of behavior that are needed to fulfill a class of task in an application lends itself to a framework that's intuitive to complete. In other languages you expose yourself to a lot of time spent manually lining up the requirements of external pieces to what you're writing now.

          Again, all conjecture, but it comes from my own observation of when I tend to make mistakes.

        • However the real strength of static strongly typed languages is when it comes to maintenance. The original programmer knows what he's using, but someone inheriting an old code base will need to put down a large amount of time to figure out how it's actually built and what a certain type do.

          Spoken like someone who's never looked at his own old code. You'd be surprised at how often the guy inheriting your old code is older you.

        • Re: (Score:2, Interesting)

          by Anonymous Coward

          I've used functional programming languages at university and in my career started off with strongly typed languages, but four years ago I retrained to Ruby and haven't looked back.

          I'm a SCJP and a OCMJD and when I was working through the OCM assignment, I couldn't conceive of a language nicer than Java. My first encounter with dynamic languages was with Groovy. I was already a keen test-driven developer but at first I had to absolutely TDD the code 100% because I was so paranoid about this new language I wa

          • Re: (Score:2, Insightful)

            by Anonymous Coward

            Java is horrible for many reasons.

            When it comes to language choice, you have to decide if performance matters. Because if it matters, you pick C and don't look back. If it matters enough to ensure there are no warnings and errors, C++, OBJC/OBJC++, and "natively compiled" C# become viable. Only those languages can compile into a clean program, but only C is gauranteed to compile cleanly on all OS's because every OS and Compiler has different "standard" bits. Microsoft is a bit worse for adhering to a standa

      • all i can say is neener neeener neener

        • Indeed... From the fine paper

          "The remaining coefficients are significant and either positive or negative. For those with positive coefficients we can expect that the language
          is associated with, ceteris paribus, a greater number of defect fixes.These languages include C, C++, JavaScript, Objective-C,
          Php, and Python. The languages Clojure, Haskell, Ruby, Scala, and TypeScript, all have negative coefficients implying that these languages are less likely than the average to result in defect fixing commits
          "

          Alth

          • by Fubari ( 196373 ) on Wednesday November 05, 2014 @04:05PM (#48320291)
            Wait. Aren't they saying that static typing needs more defect-fixes and dynamic needs less defect-fixes?
            Relevant parts highlighted:

            "The remaining coefficients are significant and either positive or negative.
            For those with positive coefficients we can expect that
            the language is associated with ... a greater number of defect fixes.
            These languages include C, C++, JavaScript, Objective-C, Php, and Python.

            The languages Clojure, Haskell, Ruby, Scala, and TypeScript, all have negative coefficients
            implying that these languages are less likely than the average to result in defect fixing commits"

            Isn't the real message here to choose static typing if you like fixing bugs?

          • I bet that's because there are few new perl devs, so on average they are far more experienced.

            Got to be something like that. Perl is worse than C for the ability to have subtle errors, and it doesn't have C's excuse of manual memory management.

    • by Anonymous Coward on Wednesday November 05, 2014 @09:39AM (#48316819)

      My take away is that strong typing is best. I need to start lifting weights and get my fingers stronger.

    • Re:Take away for me (Score:5, Interesting)

      by jythie ( 914043 ) on Wednesday November 05, 2014 @10:01AM (#48316969)
      That was my initial thought too. Each language and framework within the language seems to have developed its own developer culture, with people generally gravitating towards languages popular among others like themselves. I am not even sure if it is really 'personality type' of the individuals, but instead seems more likely to be the cultural norms within the developer community and what the 'right' balances when it comes to acceptable practices and such.
      • Re: (Score:3, Interesting)

        by Mr Z ( 6791 )

        I wonder if you can do an analysis of code bases across languages for the same team? I regularly write significant amounts of C++ (these days, C++11), Perl and assembly language. Those are three rather different languages, with strong, weak and largely non-existent type systems, respectively.

        Of course, all three languages also open themselves to a wide range of programming styles, and I imagine if you picked any other set of languages you could make a similar statement. But if you measure the same progra

        • Re:Take away for me (Score:4, Informative)

          by Mr Z ( 6791 ) on Wednesday November 05, 2014 @10:28AM (#48317173) Homepage Journal

          BTW, this ACM Queue article [acm.org] was linked from the blog post I linked above. It's another good, somewhat relevant read, IMHO. It makes largely the same point, though: It's more the programmer than the language.

        • Re:Take away for me (Score:4, Interesting)

          by Mr Z ( 6791 ) on Wednesday November 05, 2014 @10:48AM (#48317317) Homepage Journal

          I finally brought up the PDF. It appears the authors consider C++ weakly typed because it allows type-casting between, say, pointers and integers.

          While this is strictly true, I find myself avoiding such things whenever possible. Main exception: When talking directly to hardware, it's often quite necessary to treat pointers as integers and vice versa.

          I guess to fairly evaluate a language like C++, you need to categorize programs based on how the language was used in the program. If you stick to standard containers and standard algorithms, eschewing casting magic except as needed (and using runtime-checked casts the few places they are), your program is very different than one that, say, uses union-magic and type punning and so on every chance it gets. (I've written both types of programs... again, FORTRAN in any language.)

          One of my more recent projects was written ground-up in C++11. It relies on type safety, standard containers, standard algorithms, smart pointers (shared_ptr, unique_ptr) fairly heavily. It's been quite a different experience to program vs. my years of C programming. Way fewer dangling pointers, use-after-free errors, off-by-one looping errors, etc. But, the paper lumps both languages into the same bucket. That hardly seems fair.

          • Interesting. I thought most considered C++ to be strongly typed. It just allows you to break the rules, so to speak. It's helpful and sometimes even necessary to do that when writing a memory allocator, or creating a variant class, as a couple of examples. That's why C-style casts should be discourage in favor of the more explicit C++ casts. They're finer-grained, and the verbosity makes you think a bit harder as to if and why you really need a cast. It also makes searching for casts in the codebase e

        • That's an interesting thought. I've long figured that good programmers were good programmers regardless of the language used, and I'm sure the opposite likely applies as well.

          Honestly, my thoughts after reading the summary and skimming the paper were more about questioning whether one could quantify code quality algorithmically, as they apparently did. If I understand correctly, they're quantifying the number and types of bugs and trying to sort them into categories by keywords, but does that actually cor

        • That is a great point !

          Yes, they really need to look at the same programmer across procedural, functional, and OOP languages. In my experience programmers that don't understand how to use C well tend to be very poor Java, etc. programmers. :-( Understanding low levels such as memory usage and cache performance, the ability to read assembly, and knowing concepts such as register spell and branch prediction, while not "necessary" for the modern programmer all help you to be a much better programmer by under

    • Yeah, definitely. It must be because of something that wasn't measured and is impossible to measure.

    • Re:Take away for me (Score:4, Interesting)

      by Spazmania ( 174582 ) on Wednesday November 05, 2014 @10:53AM (#48317347) Homepage

      the preference of certain personality types for functional, static and strongly typed languages.

      Translation: because only very high-skill programmers attempt to use the very unpopular functional languages (like lisp and erlang) the resulting code is, on average, of better quality.

      • by psmears ( 629712 ) on Wednesday November 05, 2014 @11:31AM (#48317627)

        the preference of certain personality types for functional, static and strongly typed languages.

        Translation: because only very high-skill programmers attempt to use the very unpopular functional languages (like lisp and erlang) the resulting code is, on average, of better quality.

        There is another possible interpretation: that programmers who are very concerned about quality - and hence are happy when their language gives them lots of information about potential mistakes - like using languages with features (such as a strong type system) designed to allow detection of certain types of mistake. That is, it's specific features of the languages, rather than the fact that the languages are "unpopular", that draws quality-focussed programmers to them.

        Of course, that is just as much conjecture as any other interpretation :-)

  • by beelsebob ( 529313 ) on Wednesday November 05, 2014 @09:24AM (#48316723)

    It's clear that there are more factors here that need to be normalised out. For example, they found that the category that "had" the most performance bugs was the procedural, static, unmanaged memory category, i.e. C, C++ etc, far outstripping languages like ruby. To me, it's clear that that is caused by people using these languages actually caring about performance, while people using languages who's implementations are many orders of magnitude slower, don't really file (or fix) bugs about perf.

  • I see they list the top three projects per language... but I have this gut feeling they mi-cross-attributed ruby and perl... rails sounds distinctly ruby, while pretty sure homebrew is perlesque
  • So (Score:4, Funny)

    by stealth_finger ( 1809752 ) on Wednesday November 05, 2014 @09:27AM (#48316737)
    it says basically nothing
  • Other factors. (Score:5, Interesting)

    by LWATCDR ( 28044 ) on Wednesday November 05, 2014 @09:35AM (#48316785) Homepage Journal

    Almost no casual programer uses functional languages and do not tend to be used for large FOSS projects.

    • I'd say quite a few casual programmers use Javascript, though many of them surely do their best to ignore its functional aspects.

      But you're right in that casual and beginning programmers, or experienced programmers when they're only throwing together something quick and dirty, may be drawn to more forgiving languages or the languages they were taught in school/university, and this would bias the projects written in those languages.

      Statistics is hard. You can't simply use a random selection, or else you migh

      • I'd say quite a few casual programmers use Javascript, though many of them surely do their best to ignore its functional aspects.

        Javascript is not a functional language. Lots of idiots like to claim it is because it has features like closures. Having closures does not make a functional language, instead, what makes a functional language is referential transparency. That's something that javascript doesn't have, or even attempt to have.

        • Re:Other factors. (Score:4, Informative)

          by naasking ( 94116 ) <naasking&gmail,com> on Wednesday November 05, 2014 @11:02AM (#48317415) Homepage

          Having closures does not make a functional language, instead, what makes a functional language is referential transparency.

          Scheme, Lisp, OCaml are all functional languages that are not referentially transparent. Pure functional languages require referential transparency, but impure functional languages do exist.

          JavaScript is a functional language, but it's also procedural and object-oriented.

          • Wikipedia gives a good general-purpose description of functional programming [wikipedia.org]:

            In computer science, functional programming is a programming paradigm, a style of building the structure and elements of computer programs, that treats computation as the evaluation of mathematical functions and avoids changing-state and mutable data. It is a declarative programming paradigm, which means programming is done with expressions.

            This implies referential transparency. Scheme, Lisp, JavaScript, and other impure "functional" languages are really multi-paradigm, and more often used to write procedural programs than functional ones. While they do have the necessary language support for functional programming, the fact that they are impure means that even when you're following the functional paradigm you can't count on the rest of the program playing by the same

            • It always entertains me It always entertains me when people come up with a definition of functional programming that excludes Lisp. Similarly, when they come up with a definition for object oriented programming that excludes Smalltalk.

              Lisp was a functional language long before people attempted (and failed) to build languages that removed changeable state and mutable data.
              • I agree that it would be interesting to see a definition of object-oriented programming which didn't include Smalltalk. However, Lisp has never been all that different from well-known procedural languages except for garbage collection, closures, and the use of lists as syntax—none of which are necessary or sufficient for functional programming. These features (the first two, anyway) make it easier to write functional programs in Lisp compared to, say, C, but they don't automatically make all Lisp prog

    • On the contrary. Lots of casual programmers use SQL.
  • by EmperorOfCanada ( 1332175 ) on Wednesday November 05, 2014 @09:35AM (#48316787)
    I would say that there are three other critical factors; which languages beginners chose, which languages are rarely used, and potentially even more importantly which languages become the programmer's only language ever.

    If someone is new to programming then their programming is probably going to be poor. So certain languages tend to be "gateway" languages such as PHP, Python, VB(in the past), C#, etc. It is doubtful that someone is going to start out their programming career with the C in OpenCL or Haskell.
    I have seen many people learn PowerBuilder and never learn anything else, and while they might master powerbuilder they never really master programming. I have also seen the same thing with accountants who master the VB in excel resulting in some of the strangest agglomerations of code I have ever seen.
    But also certain languages are sort of throwaway for many programmers such as whatever the language is inside Make scripts; as most programmers that I know have not mastered make and do what they have to do to get things to compile. The same with bash; I have only met a few programmers who truly knew bash. They did what they had to do and ran away after that.

    So it would be very difficult to tease out the quality of a language based on these statistics. But regardless of the results the religious zealots who think their language is the very best and that all others are for children won't be swayed by facts anyway.
    • Re: (Score:3, Interesting)

      by Mr Z ( 6791 )

      As for which language is your gateway language, it probably depends on what era you started programming in, too. My path was Microsoft BASIC => Assembly => Turbo Pascal => C => Perl => C++11, with some shell scripting and other goodies around the fringes. I've probably written more C than anything, but C++11 rules my future. Turbo Pascal was my short-lived gateway to C, where I then spent most of my career. I wrote some truly regrettable neophyte-programmer code in C there at the beginnin

  • by msobkow ( 48369 ) on Wednesday November 05, 2014 @09:37AM (#48316801) Homepage Journal

    The more flexibility and power a language provides, the more opportunities you have to hang yourself with it.

    Personally what I hate are loosely, dynamically typed languages. They provide no compile-time checking at all that I can detect, which means that in order to even guess whether the code is "correct" you have to run through all the possible use cases. I realize that it's an ideal to test all possible inputs (especially boundary conditions), but that just isn't practical for most project schedules and budgets.

    As powerful as functional languages can be, the restrictions imposed by them can lead to difficulty implementing certain behaviours in the code. In fact, one Erlang project I worked on proved to have such an extreme difficulty implementing an algorithm that we had to cancel the project, even though the rest of the project had been completed. (That function was *the* heart of the system: the scheduling algorithm>)

    Much as the researchers discovered, I've never really found the programming language itself to have much of an impact on the code quality or readability of the code if the code was competently written. That said, even the best of languages can be turned into unmaintainable gobbledygook by a dedicated bonehead, especially consultants who know damned well they'll be long gone before the project enters maintenance/enhancement mode.

    What I found really degrades quality is not the language, but an overemphasis on code style at some companies. Instead of code reviews focusing on the functionality of the code being reviewed, they spend all their time nit-picking about variable names and whether to use camel-case or underscores.

    I consider the maintainability and readability of code to be at least as important as any metrics about the number of bugs in a project. If you can't read and understand the code easily, fixing a bug when it is discovered becomes a hellish nightmare.

    • by Shados ( 741919 ) on Wednesday November 05, 2014 @09:44AM (#48316855)

      For functional languages, the ideal is a language that supports both procedural and functional construct, so you can use either when it makes sense. Scala, and to a lesser extent C#, fit that bill quite nicely.

      Dynamically typed languages are great in cases where you'd be writing all the test cases anyway. UI code is a good example. Its faster to write proper JavaScript unit tests. provided you have the necessary infrastructure, than to manually test click click click. Since you're writing all the tests anyway, then having a dynamic language has very little drawbacks.

    • by SQLGuru ( 980662 ) on Wednesday November 05, 2014 @09:58AM (#48316945) Journal

      This. Languages that enforce their rules at compile time vs run time should inherently lead to higher quality code just by "accident". You can still write bad (or good) code in any language, but a language that lets you do whatever you want requires you to be much more rigorous in your testing strategy to ensure higher quality......and we all know how much developers love to test (and to document).

      • by cdrudge ( 68377 ) on Wednesday November 05, 2014 @10:32AM (#48317205) Homepage

        and we all know how much developers love to test (and to document).

        What are these "test" and "document" things you speak of?

        • "Test" refers to if(foo). "Document" refers to printf(...).

          When both are frantically performed hundreds of times at 2am the night before going gold, that's called "coverage".

      • But, on the other hand, people who use dynamic languages often find after a while that simple type errors actually happen to be quite a rare occurrence unless you're a total pig. Meanwhile, statically typed languages sometimes completely miss some type errors (nil in Java being an "acceptable" member of any Object-derived type despite providing none of the required behavior), and generally never extend the type system very far (one might argue that from the point of view of a dependent type system, the ordi
        • by dwpro ( 520418 )

          people who use dynamic languages often find after a while that simple type errors actually happen to be quite a rare occurrence unless you're a total pig

          Hah! Yeah right. I guess it's just the "pig" programmers who can't remember to mentally evaluate the type of each variable at each and every operation in code while they work. What sloths they must be.

          • If you're designing code consistently (read the HtDP in any edition to see what I mean by "consistently"), then I see very little opportunity for that.
    • by DarkOx ( 621550 )

      What I found really degrades quality is not the language, but an overemphasis on code style at some companies. Instead of code reviews focusing on the functionality of the code being reviewed, they spend all their time nit-picking about variable names and whether to use camel-case or underscores.

      I have to disagree with you here. Style and consistency are important. I often do third party code reviews for security and I can tell you the code I get where the there is consistent style and convention being used almost always exhibits fewer problems.

      I am sure there is a point in organizational maturity where people first start focusing on style but the group has not mastered it yet, it probably is a distraction there, once past that inflection point however, it makes it easier for peer reviewers to sp

      • Re: (Score:2, Informative)

        by Anonymous Coward

        I have to disagree with you here. Style and consistency are important. I often do third party code reviews for security and I can tell you the code I get where the there is consistent style and convention being used almost always exhibits fewer problems.

        I am sure there is a point in organizational maturity where people first start focusing on style but the group has not mastered it yet, it probably is a distraction there, once past that inflection point however, it makes it easier for peer reviewers to spot the bad decisions and questionable logic in code.

        if user = authenticate(user,password)

        doSomeStuff(user)
        else

        doSomethingDifferent(user)
        end

        Might be perfectly correct code. If you are trying to get code released though you might buzz by what this is doing on a fast read or read it wrong; unless this is a typical convention in use and then you probably would understand immediately. In other shops though you'd see this:


        user = authenticate(user,password)
        if user

        doSomeStuff(user)
        else

        doSomethingDifferent(user)
        end

        I don't have a preference actually but If you have people doing it both ways in the same code base, its a recipe for overlooked bugs.

        You pass the user variable to the authenticate function and then immediately assign user to the result of the function. If this new user is falsy, then you pass it to the doSomethingDifferent function. That's just nasty, and at that point I don't really care about the style issue you brought up.

    • Personally what I hate are loosely, dynamically typed languages. They provide no compile-time checking at all that I can detect, which means that in order to even guess whether the code is "correct" you have to run through all the possible use cases.

      People who write quality, large projects in dynamically typed languages usually do soo by writing lots of unit tests. You don't need to run through every possibility (which is impossible), but you do need to run every line, to make sure it 'compiles'

  • KISS (Score:5, Insightful)

    by polar red ( 215081 ) on Wednesday November 05, 2014 @09:40AM (#48316823)

    The KISS-principle is probably the most important thing to keep software quality up, more so than tools and language.

    • Re:KISS (Score:4, Interesting)

      by internerdj ( 1319281 ) on Wednesday November 05, 2014 @09:48AM (#48316883)
      The motivation behind this paper was probably the intuition that language choice greatly influences KISS. But frankly, I've never had a real project where language choice wasn't driven by external forces.
      • Re:KISS (Score:5, Interesting)

        by Anne Thwacks ( 531696 ) on Wednesday November 05, 2014 @10:11AM (#48317029)
        I have been responsible for language choice on many occasions, and I can say with confidence, sometimes I made the right choice and sometimes not.

        For a project starting in 1983, and expected to last 8 months, Basic seemed like a good idea. By 1995, it should have been obvious to everyone that a re-write in ANYTHING ELSE was justified (not that I would personally recommend using Perl to write a Basic interpreter to re-interpret the original Basic code or using Snobol4 to translate the Basic into Fortran).

        I could have used C instead - the project would probably have taken a couple of weeks longer, but would have saved countless people years of grief. I have C programs from the 80's that compile on *BSD unchanged, and still work as intended*. It was a toss-up at the time.

        My point is that the language choice may be influenced by incorrect information about the external world - because the external world is subject to massive change.

        * I had to rewrite some C from the 70's cos they were written for Idris and all in capitals :-{ Fortran4 programs from the 70's may compile and run, but you certainly need to re-test them!

        Yes its true: my lawn is written in Fortran, but my Mum's has an Ibjob border.

  • Language (Score:5, Insightful)

    by ledow ( 319597 ) on Wednesday November 05, 2014 @09:44AM (#48316857) Homepage

    You can code sloppily in any language.

    All this tells me is that there's so little difference as it not to be a major factor in your choice of language. As such, other more practical considerations (such as hiring programmers, project time, and even speed of the final code) should take far more precedence than the triviality of what language you happen to use.

    As with all things "programming language" - apply them to real language. I'm certain that in some languages, it's easier to mis-speak at a critical moment, or to say the wrong thing, or be misconstrued. I'm also certain that some languages are more prevalent, easier to learn, clearer in their intent and grammar, etc.

    But it doesn't mean at any point that you should change what you're doing to the language of the moment, nor that you should choose what language to do a project in taking any notice of the structure or grammar of the language over who you have who can speak it and how well everyone can be understood if they speak it together.

    Also, there are languages and dialects that make specific tasks easier (for instance, IT has a language all of it's own, talking about SCSI, buses, cloud, etc.). If everyone is able to "speak the lingo", then that's a good choice, but it's not the be-all and end-all of a good project.

    As such, all the programming language discussion is really like saying "We should all speak and write only in Chinese, because the Chinese for death and dearth sound more different and we won't get confused". Don't. Program in the language that you're comfortable with, that the people you hire can read and write fluently, and that is most common and available.

    Personally, that's always been C / C99 for me. So I always find it hard to justify the use of other languages except when there's a functional difference that gives a distinct advantage (e.g. a scripting language for scripting, or string-handling in Perl, etc.)

    TL;DR version: Who cares what language? Stop arguing about it and start coding.

    • Language (Score:5, Insightful)

      by TVmisGuided ( 151197 ) <alan.jumpNO@SPAMgmail.com> on Wednesday November 05, 2014 @10:11AM (#48317025) Homepage

      You can code sloppily in any language.

      True, but some languages make it more difficult to do so. Ada, for example, won't allow code to compile with (what should be) obvious logic or syntax errors that most C/C++ compilers will happily ignore, and hence allow to go undiscovered until runtime...errors that could be catastrophic in the real world.

      Ada has acquired a reputation as a niche-market language, but that niche market takes heavy advantage of Ada's strengths: strong typing and a requirement that the developer properly design the software before writing code. Unfortunately, deciding to develop commercial software in Ada also comes with a fairly steep price tag, because it's a niche market...thus perpetuating the cycle.

      DISCLAIMER: I am not affiliated with any company which produces or sells Ada compilers.

      • I remember working on a large Ada project several years ago, which involved porting an old system from Solaris/SPARC to RHEL/x86, and adding a slew of new features. The dev environment was absolutely horrible: Each engineer had a windows desktop (corporate policy, you know) and had to use exceed to connect to a Linux dev box to do our actual work (and of course, one monitor per workstation).

        As a scumbag sub-contractor, I was not allowed to look at/have access to certain parts of the codebase -- which
  • by pem ( 1013437 ) on Wednesday November 05, 2014 @09:46AM (#48316863)
    They discuss prior studies that looked at development effort, but hand-waved away the fact that dynamic languages take less development effort.

    This may well be because their study cannot discern the amount of programmer effort per check-in, but it is a fatal flaw. Open development methods mean that a lot of dirty laundry gets checked into repositories. If dynamic languages have more bugs per check-in, but require significantly less work per check-in, then measuring bugs per check-in without measuring effort per check-in is meaningless, and that's before you even get to the functionality provided by the checked-in code.

  • Summary: Some languages give you more control over the hardware on which the software runs. Those languages require more skill, experience and discipline to use, thus software written in those languages will have more defects.

  • So stronger compile time checking leads to better quality code, no surprise there. I'm a fan of strong checking during compile time. But dynamic features might allow the programmer to achieve more with their program. Either way when you see that project organisation factors have a much greater effect, it seems to me that the language effect is insignificant. What's really interesting to me is how they measured the code quality. How did they determine that a commit was defective?
  • by MobyDisk ( 75490 ) on Wednesday November 05, 2014 @10:23AM (#48317135) Homepage

    The problem with these kinds of studies is that there is no actual way to objectively measure software quality. You can correlate all the data you want, but garbage in means garbage out.

    For this study they used two thinfactor gs to determine software quality: one is the number of bugfix commits. Ugh. I'm not even clear if the number of bugfix commits means higher quality, or lower quality. That could go either way. It might mean you had better testers, or that you committed things in small batches, or that you had more branches. The other factor was a natural language processor that read the check-in comments. While this is a really cool idea, you would need a lot of research just to prove that this approach actually works before you can start using the technique to draw conclusions about some other data.

    So while this was very cool, and very ambitious, the results are completely meaningless until someone can prove that this technique actually measures software quality at all.

  • by Count Fenring ( 669457 ) on Wednesday November 05, 2014 @10:25AM (#48317155) Homepage Journal
    Also striking - they point out that functional languages, in particular Scala, Erlang, and Clojure have more concurrency bugs, without bringing up that concurrency support is basically the primary feature those languages are selected for. I'd love to see the defect number correlated with the percentage of code dealing with concurrency.
    • That would make some sense if the projects themselves were intended for highly concurrent operation, thus the choice of language, thus the defects in that category because that's what the code is for.

      I will say that the all of those languages have very particular models for concurrency, such that misunderstanding the models can lead to design errors in the code. Harder problems plus clever code often yields brutal bugs.

    • by jeorgen ( 84395 ) on Wednesday November 05, 2014 @11:46AM (#48317795)

      Absolutely! They write:

      "The major languages that contribute concurrency errors
      from these classes are Go, C#, and Scala and their regression
      coefficient is also statistically significant. These results confirm,
      in general static languages produce more concurrency errors than
      others. Among the dynamic languages, only Erlang is more
      prone to concurrency errors. The regression analysis also shows
      that projects written in dynamic languages like CoffeeScript,
      TypeScript, Ruby, and Php have fewer concurrency errors"

      Well, there isn't much concurrency to be had in TypeScript or CoffeeScript since they operate in single threaded environments, and it wouldn't surpise me if the same goes for the other ones. And saying that Erlan has problems with concurrency is... the cart before the horse.

  • As per the content of published document:

    Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
    FSE’14 November 16–22, 2014, Hong Kong, China Cop

  • by mwvdlee ( 775178 ) on Wednesday November 05, 2014 @10:49AM (#48317329) Homepage

    This research used open source from Github as a base.

    I used to be a COBOL, PL/1 and Java programmer within a single 80.000+-employee company for over a decade, so I have some insight in the quality aspects of both languages.

    If you compare the quality of COBOL code on Github it's generally very low, because most of it is small, half-finished projects made for fun.
    In a professional environment, COBOL quality is generally very high; much higher than Java code.

    None of this has anything to do with the language, rather the Java was running on a desktop, where 99.9% uptime and a projected maintenance lifespan of ~10 years was good enough. The COBOL was running on a mainframe where 99.995% was the bare minimum uptime and there were no projected lifespans; it should be maintained forever.

    Heck, even aging PL/1 code on a mainframe is typically of much higher quality than modern Java code on a desktop.

    The language is completely irrelevant. If NASA made their in-flight software using Brainfuck [wikipedia.org], it would probably be rated as an incredibly stable and secure language as well.

    • If you compare the quality of COBOL code on Github it's generally very low, because most of it is small, half-finished projects made for fun. In a professional environment, COBOL quality is generally very high; much higher than Java code.

      Interesting. You're the second person who's told me that recently. I've never seen an example of good cobol though, do you happen to know where any is floating around the net?

      • What makes you think you are qualified to assess the quality of COBOL code? Do you maintain code bases that have handled financial transactions for over a decade?

      • by mwvdlee ( 775178 )

        I don't remember seeing one on the net, but I've stopped doing COBOL about 5 years ago.

        Besides, the language is besides the point. It's the mentality of the developers.

        Basically do every good thing you were taught but practically never do, like checking every possible error, validating every input, keep-it-simple, etc. Then add mature procedures, methodologies and tooling. If you're doing ingenious things in your code, you're probably making it harder to maintain. Code should look like it doesn't solve any

  • Emacs! (Score:5, Funny)

    by Bob9113 ( 14996 ) on Wednesday November 05, 2014 @10:52AM (#48317337) Homepage

    I don't care what they say, software written with Emacs is way better than software writen with Vi!

    • by Xyrus ( 755017 )

      I don't care what they say, software written with Emacs is way better than software writen with Vi!

      Ha! Like I'd listen to you! You still refuse to open your eggs from the little end!

    • by labnet ( 457441 )

      HaHa... Modded Insightful!!

  • Sometimes, the gentle pace of machine code development can be augmented by the adoption of a “FORTRAN” compiler. That's what I thought!
  • Not sure if it's the fact that you can host PHP on Godaddy's lowest tier(s) or what, but PHP seems to be the lowest hanging fruit and a lot of "babby's first project"s are written in PHP. I know a few people who avoid PHP projects based on that principle. The average PHP project seems to be dramatically lower in quality compared to similar ones written in Python, Ruby, heck even C#/ASP.

  • It has snob appeal for the uber geeks but the language sucks in so many ways. It killed Netscape 6.0 and that should have been the last of the language but it still lives, alas...
  • Boilerplate

    The language that has the least boilerplate for your problem is usually the most pleasant to work with, which in turn increases productivity and quality, although this expressibility usually comes at the cost of performance and sometimes at the cost of correctness which can lead in reduced quality. Javascript literal objects and literal arrays for example makes it a joy to program compared to Java when you have to pass those Map>> around. 90% of the cases you need an anonymous inner class i

    • My personal mileage varies significantly. I still prefer Ada, which is a language that you'd probably characterize as having a lot of "boilerplate". An experience Ada programmer learns how to use that to his advantage in several ways:
      1. When you're on a large or long-lived project, readability of code (even your own, years later) is more important than writeability,
      2. The compiler checks consistency, and as you get better with the language you learn how to maximize what the

    • A lot of Java boilerplate code (and not just getters/setters) can be gotten rid of with a bit of AspectJ (Spring Roo leverages this heavily). With good use of AspectJ, your java objects look like POJOs (plain old java objects) with all of the extra stuff added at compile-time by the .aj files.
  • Strong typing was meant to curb errors, but the types of errors strong typing catches are a minority of bugs. Most bugs are logic bugs, followed by performance bugs. The rise in importance of a thorough test suite has made many software projects better.

    I'm not talking test-driven development, but ANY test framework that can be easily written and maintained, either by developers themselves, or by a competent QA department.

  • This is a language that of course was designed very differently from the common C based languages in wide use today, and one for which there is a very large amount of publicly available code (but not on GitHub.) I've seen studies from large volumes of Ada code, both with respect to error rates and with respect to development and maintenance costs, that show a significant advantage for that language.

    • Ada was a great language but the college douchebags hated it because it was designed by the DoD. There excuse was that it was too complicated to write a compiler for. So the college pukes kept using C and kept overwriting their stacks and heaps and reveling in the "flexibility" and freedom of their language. Then along came C+ which was truly impossible to compile and these idiots jumped right on that road to perdition.
  • by Anonymous Coward

    i am unfamilliar with how these words together make sense. The fact that no one els epointed it out makes me feel like its me. But it's driving me nuts. It's like a person giving a lecture has their pants drop to the floor and no one says anything. I have to post becuase it seriously is driving me nuts. If someone can explain hwo this phrase makes sense i would appreciate it.

"Open the pod bay doors, HAL." -- Dave Bowman, 2001

Working...