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."
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."
Take away for me (Score:5, Interesting)
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...
Or, to put it another way... (Score:5, Insightful)
"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."
Re:Or, to put it another way... (Score:5, Insightful)
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.
Re:Or, to put it another way... (Score:4, Informative)
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.
Re:Or, to put it another way... (Score:5, Funny)
Using abstract classes in C++ (with multiple inheritance) is a bit like surgically cutting a hole in your foot so that when you shoot yourself, it doesn't hurt too bad.
Yeah, it achieves the goal, and makes it a little less messy to clean up, but it doesn't really guide the coding process to protect yourself the way compiler recognized interfaces do.
Re: (Score:2)
Using abstract classes in C++ (with multiple inheritance) [...] doesn't really guide the coding process to protect yourself the way compiler recognized interfaces do.
I'll bite.
The AC above makes it clear that we are talking about people using language features appropriately, so how do "compiler-recognized interfaces" provide such a significant benefit over appropriate use of C++11 abstract base classes?
Re: (Score:2)
Enforcement is all I mean. Well, that and that abstract classes are proper classes and have all the collision problems that implies when multiple inheritance rears its ugly head.
Re: (Score:2)
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)
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)
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
as a perl wizard.... (Score:2)
all i can say is neener neeener neener
Re: (Score:2)
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
so, static == more defects? (Score:4, Interesting)
Relevant parts highlighted:
"The remaining coefficients are significant and either positive or negative. ... a greater number of defect fixes.
For those with positive coefficients we can expect that
the language is associated with
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?
Re: as a perl wizard.... (Score:2)
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.
Re:Take away for me (Score:5, Funny)
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)
Re: (Score:3, Interesting)
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)
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)
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.
Re: (Score:2)
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
Re: (Score:3)
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
Re: (Score:2)
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
Re: (Score:2)
I imagine the result resembles INTERCAL. [wikipedia.org]
Re: (Score:2)
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)
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.
Re:Take away for me (Score:5, Insightful)
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 :-)
More factors to normalise out. (Score:5, Interesting)
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.
Re:More factors to normalise out. (Score:4, Informative)
C/C++ certainly let you shoot yourself in the foot regarding correctness, but they generally don't make it easy to shoot yourself in the foot regarding performance. (C++ templates, exceptions, and RTTI being exceptions.)
And the fact idiots still use those languages in areas where performance isn't an absolute priority is simple idiocy.
Other legitimate reasons include legacy codebase, existence of useful libraries accessible from only these languages, extreme practical portability (yes you can technically run C# on Android, or Java on iPhone, but it takes proprietary external tools), etc.
Re: (Score:2)
Sure they do, you're less likely to go through the hassle of creating a data structure that would be optimal for your domain simply because of the complicated memory management issues it raises. This is a complete non-issue with GC'd languages, so you're far more likely to do the (asymptotically) right thing.
low level programmers understand data structures (Score:3)
In several languages, associative arrays are used for modt things. Perl calls them hashes, PHP calls them arrays, and both languages tend to see them overused. I strongly suspect that most programmers using them have no idea how these data structures work internally, so they don't really know when or how to best use them. C programmers will tend to understand how the data structures and which other types of structures are better suited for a particular use. A single C program may use a queue, a doubly-
low level programmers understand data structures (Score:3, Interesting)
Python also uses hash tables everywhere, including for global and local variables and instance and class members.
The implementations of the hash table is extremely optimised.
There was an interesting discussion on usenet about someone who wanted to optimise a piece of Python code by writing a C++ module to do the heavy lifting. It was about adding C++ strings into a C++ hash map. The naive version was 10,000 times slower in C++.
Of course the naive function was copying strings many times since this is what th
Re: (Score:2)
I've never seen this occur myself, but yes, maintaining cyclic data-structures is harder in C/C++ than in GC'ed environments.
shared_ptr, and its related smart ptrs, are generally adequate for fully automatic memory-management, though. Cycles are quite rare in my experience, but of course they do happen.
There's a related point to be made about how it can be difficult to do the algorithmically 'right thing'. Until C++11, you had to use external libraries for hash-maps. What I should've said is that C and C++
Re: (Score:2)
Sure they do, you're less likely to go through the hassle of creating a data structure that would be optimal for your domain simply because of the complicated memory management issues it raises. This is a complete non-issue with GC'd languages, so you're far more likely to do the (asymptotically) right thing.
If you use smart pointers to manage your dynamic allocations, you'll find that memory management in C++ isn't any harder than in a garbage-collected language. It's only when trying to manually manage memory (C-style) that it gets tricky, and manual memory management is almost never necessary.
(The downside is that you have to make sure to avoid reference cycles, but in my experience that is easy enough to do. The upside is that you don't incur the overhead of a GC thread, and that your resources are freed
Re: (Score:2)
Because smart pointers are degenerate garbage collection.
Re: (Score:3)
But 'the C++ way' can cause cascading release of resources. See this comment below [slashdot.org].
Re:More factors to normalise out. (Score:4, Interesting)
Oh, I also forgot to mention:
Except this can lead to extremely high latency due to cascading deletions, which is another potential source of performance problems in C/C++. If you try to bound the amount of work to do to avoid this problem, you necessarily introduce reclamation latency. Reclamation latency isn't necessarily a bad thing.
Re: (Score:3)
Except this can lead to extremely high latency due to cascading deletions, which is another potential source of performance problems in C/C++
I suppose that is possible; although I've never actually encountered that problem (over the last 15 years I've spent doing C++ programming).
Re:More factors to normalise out. (Score:4, Interesting)
Not really. Which data-structures are immediately available in a language, does matter. Ruby has associative arrays as part of the language, and they're used for all sorts of things despite that traditional arrays would be more efficient. Ruby doesn't care much about efficiency.
On the other hand, up until quite recently the C++ standard-library didn't include a hash-map, so a busy developer might be tempted to just use an array and a linear-scan; that's easier than setting up Google's sparsehash library.
Re: (Score:2)
C/C++ [..] don't make it easy to shoot yourself in the foot regarding performance. (C++ templates, exceptions, and RTTI being exceptions.)
Sorry, but I'm taking exception to this...
Re: (Score:3)
As an example: the LLVM project coding standards forbid use of exceptions or RTTI, on the grounds that they cause global performance harm, even if you don't use them. (Whether this is still true of exceptions, I'm not entirely sure.)
Templates can be tremendously useful, but their reputation for binary code-bloat isn't undeserved. Careless use of templates can cause vast amounts of machine-code to be generated. That said, even speed- and size-sensitive applications may find they have a place.
Re: (Score:2)
Yep, C strings, and strlen, are pretty nasty. Fair point. C does at least make it fairly clear that there's work being done to find the length of a string. (Unlike in, say, Ruby, in which iirc a zero-argument method invocation has the same syntax as member-access.)
Re:More factors to normalise out. (Score:4, Insightful)
Re: (Score:3)
There are only a few ten of thousand cars in the world that have to solve a win-the-race problem. Most of cars must solve the problem go-buying-something-at-the-shopping-center. An Honda Civic wins that race easily against an Indy Car especially if you buy a week's worth of stuff.
Computer analogy: programs written in not so efficient languages can win races to delivery and keep their business alive. An example: GitHub.
Possible error in early pages? (Score:2)
So (Score:4, Funny)
Other factors. (Score:5, Interesting)
Almost no casual programer uses functional languages and do not tend to be used for large FOSS projects.
Re: (Score:3)
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
Re: (Score:2)
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)
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.
Re: (Score:2)
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
Re: (Score:3)
Lisp was a functional language long before people attempted (and failed) to build languages that removed changeable state and mutable data.
Re: (Score:3)
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
Re: (Score:2)
Also which languages that beginners choose. (Score:5, Insightful)
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)
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
You need enough rope to hang yourself (Score:5, Informative)
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.
Re:You need enough rope to hang yourself (Score:4, Interesting)
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.
Re:You need enough rope to hang yourself (Score:5, Insightful)
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).
Re:You need enough rope to hang yourself (Score:5, Funny)
What are these "test" and "document" things you speak of?
Re: (Score:2)
"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".
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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)
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.
Re: (Score:2)
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)
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)
Re:KISS (Score:5, Interesting)
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)
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)
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.
Re: (Score:2)
As a scumbag sub-contractor, I was not allowed to look at/have access to certain parts of the codebase -- which
Re: (Score:2)
Re: (Score:2)
If data shows a possible advantage, we should not dismiss it out of hand.
"Most people stumble upon the truth, but usually they pick themselves up and move on as if nothing had happened."
This describes how much of slashdot handles new scientific information.
Development effort not considered (Score:5, Insightful)
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 (Score:2)
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.
How to measure quality? (Score:2)
How did they measure quality? (Score:5, Insightful)
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.
Concurrency bugs found in highly concurrent langs (Score:5, Insightful)
Concurrency bugs found in highly concurrent langs (Score:2)
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.
Re:Concurrency bugs found in highly concurrent lan (Score:4, Interesting)
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.
redistribution FYI (Score:2)
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
The case of COBOL (Score:3)
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.
Re: (Score:2)
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?
Re: (Score:2)
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?
Re: (Score:2)
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)
I don't care what they say, software written with Emacs is way better than software writen with Vi!
Re: (Score:3)
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!
Re: (Score:2)
HaHa... Modded Insightful!!
Re: (Score:2)
Burn PHP (Score:2)
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.
C++: the biggest joke ever played on developers (Score:2, Insightful)
I have just one word for you (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
Test frameworks (Score:2)
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.
Too Bad Ada wasn't included (Score:2)
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.
Re: (Score:2)
does have a significant, but modest effect (Score:2, Insightful)
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.
Re: (Score:2)
Fuck you.