Stories
Slash Boxes
Comments

SoylentNews is people

posted by LaminatorX on Thursday November 06 2014, @12:40PM   Printer-friendly
from the Brainfuck++ dept.

A variety of debates ensue during discussions whether a given programming language is “the right tool for the job" and 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 using a very large data set from GitHub that 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.

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 overwhelm- ingly 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.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Funny) by Sir Garlon on Thursday November 06 2014, @12:57PM

    by Sir Garlon (1264) on Thursday November 06 2014, @12:57PM (#113494)

    TFS says:

    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.

    So the authors are downplaying the controversial claim that some languages are better than others, and instead are making the claim that functional, static, and strongly typed languages are preferred by better programmers. What could be controversial about that? :-)

    --
    [Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
    • (Score: 2, Funny) by Anonymous Coward on Thursday November 06 2014, @01:03PM

      by Anonymous Coward on Thursday November 06 2014, @01:03PM (#113495)

      Nothing is controversial about that. It's a well known fact.

      If some Ruby weenie doesn't like that fact and he cries about it, well, then it's just too bad for him!

    • (Score: 2) by DrMag on Thursday November 06 2014, @03:21PM

      by DrMag (1860) on Thursday November 06 2014, @03:21PM (#113537)

      The only two languages that they classified as functional, static, and strongly typed are Haskell and Scala. Was that the conclusion you were intending to draw?

      I have to wonder how many programmers assume their preferred language is something it is not.

      • (Score: 2) by Random2 on Thursday November 06 2014, @06:49PM

        by Random2 (669) on Thursday November 06 2014, @06:49PM (#113604)

        The conclusion I saw there is that functional programming is awful for embedded systems, but Ada is pretty nice (and it is, believe you me).

        --
        If only I registered 3 users earlier....
        • (Score: 2) by HiThere on Thursday November 06 2014, @07:34PM

          by HiThere (866) Subscriber Badge on Thursday November 06 2014, @07:34PM (#113624) Journal

          OK, but there is no best language. There is a "best language for the job". Just because a language *can* do anything computable doesn't mean it's a good tool to use for a particular job.

          Ada is one of those languages that feels "almost right". For embedded systems it may be more right than any other language (though even there it might depend strongly on exactly what the embedded system needed to do). But they should have made the default string type unbounded, and they should have *strongly* encouraged garbage collection be implemented...as in if garbage collection was not implemented it should only have qualified as a subset of the full language. Most other things feel right, and the flaw with garbage collection is largely due to the fact that when it was being designed garbage collection was not fully developed. (Mind you, there's no reason you shouldn't be able to turn it off if you don't need it...or actively don't want it. But I don't consider storage pools to be an even approximately adequate replacement. But what you need depends on what you are doing.)

          --
          Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
          • (Score: 2, Insightful) by novak on Thursday November 06 2014, @08:27PM

            by novak (4683) on Thursday November 06 2014, @08:27PM (#113642) Homepage

            Please don't get your garbage collection all over my embedded systems. Some of us do not consider its absence a flaw.

            --
            novak
            • (Score: 2) by TheRaven on Friday November 07 2014, @10:09AM

              by TheRaven (270) on Friday November 07 2014, @10:09AM (#113775) Journal
              It depends a lot on what you mean by 'embedded'. At the really low end, you have a degenerate case of garbage collection: all dynamically allocated memory is reclaimed, because there is no dynamically allocated memory. Embedded these days generally means 'needs to run for a really long time without maintenance or downtime' rather than 'has very low resource constraints'. In this case a full tracing GC can be acceptable depending on the latency requirements. More commonly, you'll use very coarse-grained GC and periodically restart components, reclaiming their entire heap.
              --
              sudo mod me up
            • (Score: 2) by HiThere on Friday November 07 2014, @07:59PM

              by HiThere (866) Subscriber Badge on Friday November 07 2014, @07:59PM (#113924) Journal

              Did you even read where I mentioned disabling it? Ada already has an optional appendix to allow garbage collection, it's just that nobody implements it, making it unusable.

              --
              Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
              • (Score: 1) by novak on Friday November 07 2014, @10:34PM

                by novak (4683) on Friday November 07 2014, @10:34PM (#113945) Homepage

                Yes. I guess I read (part of) your comment as "I wish they would hobble ada without garbage collection," to which I wanted to say "I do not wish that."

                --
                novak
    • (Score: 0) by Anonymous Coward on Thursday November 06 2014, @03:58PM

      by Anonymous Coward on Thursday November 06 2014, @03:58PM (#113552)

      at first, i felt like you were being somewhat sensationalist and creating the controversy by using the term 'better programmers'. that is not what i took from the quoted sentence. to me, it meant that detail-oriented, meticulous and anal programmers preferred functional, static and strongly typed languages. then i realized that you are correct. those are the best programmers.

      • (Score: 2) by HiThere on Thursday November 06 2014, @07:25PM

        by HiThere (866) Subscriber Badge on Thursday November 06 2014, @07:25PM (#113620) Journal

        That depends on exactly what part of the job you are focusing on. In the final design it becomes necessary to be detail oriented, but when doing the preliminary design it's an active hindrance. But perhaps you use the word programmer where I would use the word coder. To me programmer includes system analyst. And I dread having to work on a system designed by someone who was top-down detail oriented. You get the worst of both worlds.

        --
        Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
  • (Score: 5, Insightful) by PizzaRollPlinkett on Thursday November 06 2014, @01:16PM

    by PizzaRollPlinkett (4512) on Thursday November 06 2014, @01:16PM (#113498)

    I think the biggest flaw is that there is no control group - we do not know what quality software looks like. If we did, writing software would be easier...!

    The only flaw I really see in this research is that it assumes all things are equal, when in reality the languages matters less than the user base, the platforms and frameworks being used, and other factors outside the programmer's control. Your Java code may be interfacing with an almost indeterministically complex "stack" of MVC, ORM, DI, and back-end database code written by other people, or with Google's badly-written, crash-prone Android platform. So while I want to write zero-defect, bug-free code, I'm at the mercy of the environments I have to interact with. And don't get me started with JavaScript, browser bugs, and frameworks like jQuery.

    I'm wondering if this research is proving that people who use obscure dynamic and functional languages write better code because they are in a more self-contained environment less dependent on other people's code.

    And how many bug fixes are actual coding errors, versus say errors understanding badly written documentation (I got burned by that recently), workarounds for problems in the platform or external environment, users wanting the software to do something the developer didn't intend, or similar bugs? All bugs aren't the same. Would be really interesting to isolate coding error bugs from others.

    --
    (E-mail me if you want a pizza roll!)
    • (Score: 4, Interesting) by Sir Garlon on Thursday November 06 2014, @01:29PM

      by Sir Garlon (1264) on Thursday November 06 2014, @01:29PM (#113505)

      I'm wondering if this research is proving that people who use obscure dynamic and functional languages write better code because they are in a more self-contained environment less dependent on other people's code.

      Drat, I don't have mod points today. I think you may be on to something here. That makes for an interesting trade-off: whether it is better, in fact, to re-invent the wheel from time to time in order to preserve a carefully pruned execution stack, or to accept the inherent risks of linking to a giant hairball of libraries and frameworks. Most of the time I just whip out the framework or library because I want to get to the business logic I'm being paid to implement.

      --
      [Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
    • (Score: 1, Insightful) by Anonymous Coward on Thursday November 06 2014, @01:38PM

      by Anonymous Coward on Thursday November 06 2014, @01:38PM (#113508)

      I think the biggest flaw is that there is no control group - we do not know what quality software looks like. If we did, writing software would be easier...!

      After shortly looking into the paper, I think their quality measure is simply the number of bugs. Which makes sense because, after all, the programming language should not influence e.g. whether you manage to design an intuitive user interface.

  • (Score: 1, Insightful) by Anonymous Coward on Thursday November 06 2014, @01:17PM

    by Anonymous Coward on Thursday November 06 2014, @01:17PM (#113499)

    Anyone can write bad code, no matter what programming language it happens to be in.

    • (Score: 4, Funny) by Sir Garlon on Thursday November 06 2014, @01:23PM

      by Sir Garlon (1264) on Thursday November 06 2014, @01:23PM (#113503)

      But to write truly hideous code takes dedication and talent!

      --
      [Sir Garlon] is the marvellest knight that is now living, for he destroyeth many good knights, for he goeth invisible.
      • (Score: 2) by choose another one on Thursday November 06 2014, @02:32PM

        by choose another one (515) Subscriber Badge on Thursday November 06 2014, @02:32PM (#113522)

        Real programmers can write FORTRAN in any language...

      • (Score: 1) by GeminiDomino on Thursday November 06 2014, @02:33PM

        by GeminiDomino (661) on Thursday November 06 2014, @02:33PM (#113523)

        And PHP.

        Even VB6 couldn't come up with some of the horrible crimes against determinism that I've seen in PHP.

        --
        "We've been attacked by the intelligent, educated segment of our culture"
      • (Score: 2) by Marand on Friday November 07 2014, @03:35AM

        by Marand (1081) on Friday November 07 2014, @03:35AM (#113741) Journal

        But to write truly hideous code takes dedication and talent!

        Or a text editor and perl :)

        (disclaimer: I actually like Perl and have used it since the 90s, but I'd have to be a fool to deny that Perl makes it extremely easy to make some truly frightening, unreadable code)

    • (Score: 2) by Nerdfest on Thursday November 06 2014, @01:45PM

      by Nerdfest (80) on Thursday November 06 2014, @01:45PM (#113510)

      Some languages (VB, PHP, etc) seem to encourage it. Languages should make doing the right thing the easiest thing. They should also be consistent in the way they work, unlike JavaScript and PHP.

      • (Score: 3) by tibman on Thursday November 06 2014, @02:35PM

        by tibman (134) Subscriber Badge on Thursday November 06 2014, @02:35PM (#113524)

        They call it the "pit of success". You typically find it in "professional" languages. I think VB falls into the pit of success category though. PHP and JavaScript certainly do not because of automatic type-casting, recursive dependencies, prototype inheritance(js), very inconsistent function naming(php), and truthy/falsey values. C and C++ are not pit of success languages.. they are just pits : )

        --
        SN won't survive on lurkers alone. Write comments.
      • (Score: 2) by Thexalon on Thursday November 06 2014, @02:36PM

        by Thexalon (636) on Thursday November 06 2014, @02:36PM (#113525)

        For what it's worth, as someone who's colleagues and employers considered me to be a solid and productive programmer, the best code I've looked at for large applications has been written in Ruby, Python, or Java. The next tier I've seen was in C#, C, or C++. The code that made me want to find the programmer who wrote it and engage in a violent act so they could never code again was mostly written in PHP or Perl. Generally, what I've seen of Javascript is that its quality varies with the quality of the server-side code it's paired with e.g. people who write great Django apps write very good Javascript, while people who write security-holed PHP monstrosities write bad Javascript too.

        It wasn't so much that there was all bad code in PHP, or all great code in Python, as it was two trends in good languages (and opposite trends in bad languages):
        1. The good languages all make it easy to do the right thing.
        2. The good languages quickly established a culture of extensive documentation, testing, and overall code quality, encouraged by the language designer.

        --
        The only thing that stops a bad guy with a compiler is a good guy with a compiler.
        • (Score: 2) by Nerdfest on Thursday November 06 2014, @03:23PM

          by Nerdfest (80) on Thursday November 06 2014, @03:23PM (#113540)

          My experience actually matches yours pretty much perfectly, although I do see fairly good java programers writing fairly poor client side code in JavaScript. Part of it is probably inexperience in languages that are not strongly typed.

          • (Score: 2) by snick on Thursday November 06 2014, @04:03PM

            by snick (1408) on Thursday November 06 2014, @04:03PM (#113555)

            The biggest problem with Java programmers writing JavaScript is that way too many figure that they can just wing it. Because of the name, they don't realize that JavaScript is a completely different language, and try to use it like Java w/o types.

            Java is to JavaScript as Car is to Carpet.

            • (Score: 2) by meisterister on Friday November 07 2014, @01:50AM

              by meisterister (949) on Friday November 07 2014, @01:50AM (#113715) Journal

              But most cars have carpet in them, right?

              --
              (May or may not have been) Posted from my K6-2, Athlon XP, or Pentium I/II/III.
    • (Score: 1, Insightful) by Anonymous Coward on Thursday November 06 2014, @02:29PM

      by Anonymous Coward on Thursday November 06 2014, @02:29PM (#113521)

      Some languages make it far easier to write bad code. PHP is a good example of this.

      Some languages make it far harder to write good code. JavaScript is a good example of this.

  • (Score: 0) by Anonymous Coward on Thursday November 06 2014, @05:31PM

    by Anonymous Coward on Thursday November 06 2014, @05:31PM (#113578)

    What is a bug? A missing "const" qualifier in a function prototype is a bug by some people's reckoning.

    Or how about using O(n**2) nested loops when the collection is thought to be reasonably small?

    I think the researchers need to at least provide some standard black box tests that can be applied uniformly to software written in different language. Number of open bugs isn't a good metric.

    • (Score: 0) by Anonymous Coward on Thursday November 06 2014, @11:47PM

      by Anonymous Coward on Thursday November 06 2014, @11:47PM (#113693)

      Yes, those are bugs.

    • (Score: 0) by Anonymous Coward on Friday November 07 2014, @03:30AM

      by Anonymous Coward on Friday November 07 2014, @03:30AM (#113738)

      According to this "study," if you call it a "bug" and fix it, it is a bug, and if you ignore it because it compiles anyways and the features still work, then it is not a bug. The less you fix, the higher quality your software is.

      No? Well, then this study doesn't measure software quality. It may (or may not) measure inverse quality, though.

      Remember, windows has less bugs than linux, because they have a lower bug count! And openbsd is the buggiest software ever written, because they flag and fix bugs not only their own bugs, but upstream bugs too. Cleaned up some dirty code? Your software is now lower quality than if you didn't clean it up. Oh, wait...

  • (Score: 2) by skullz on Thursday November 06 2014, @05:35PM

    by skullz (2532) on Thursday November 06 2014, @05:35PM (#113580)

    Um... for their programming paradigm they have Procedural, Functional, and Scripting. What is the Scripting paradigm? I've heard of OOP but never Scripting. Even their reference [15] is functional vs OOP.

    That and they lump C++, Java, C# and even Objective-C into the Procedural category. Objective-C? Common, its in the name!