The Effect of Programming Language On Software Quality

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

Comments

Take away for me

[just_another_sean]

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

Re:Take away for me

[Anonymous Coward]

Indeed. The strongly typed personalities prefer...strongly typed languages.

Or do they??

Re:Take away for me

[Anonymous Coward]

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

[jythie]

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:Take away for me

[Mr Z]

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 programmers programming in across them (assuming a reasonably high level of proficiency in all of them), then perhaps you can determine what portion of the effect is due to the programmer vs. due to the language.

After all, Real Programmers can write FORTRAN in any language.

Re:Take away for me

[__aaltlg1547]

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

Re:Take away for me

[Mr Z]

BTW, this ACM Queue article 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

[Anonymous Coward]

After all, Real Programmers can write FORTRAN in any language.

I'd be more impressed if they could write APL in COBOL (or vice versa).

Re:Take away for me

[Mr Z]

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:Take away for me

[Spazmania]

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

[Mr Z]

I imagine the result resembles INTERCAL.

Re:Take away for me

[psmears]

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

Re:Take away for me

[Dutch Gun]

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 correlate directly to code quality? I've seen some bug-free code that was absolutely horrible. OpenSSL comes to mind - even though it's reasonably bug-free and stable, when people looked into a little deeper, they realized that, architecturally speaking, it was a disaster.

Interesting paper, but the end results are unsurprising. Naturally, languages that make more efforts to protect the programmers from their own mistakes will tend to have have fewer bugs. Of course, the kicker is that languages are chosen for a variety of reasons, not necessarily because of which one produces overall fewer bugs. Languages often are chosen because of ecosystem, interoperability, performance, history/legacy, or even just personal preferences.

Re:Take away for me

[Dutch Gun]

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

My experience with C++ 11 has mirrored yours. After an entire career of working mostly in a C++98 style, C++ 11 feels almost like a new language, after creating a new project from scratch that I've been working on for several years now. I've described it before as almost like working in C#, but with uglier syntax.

C++ is one of those languages, though, where if you don't know what you're doing, you can create downright evil code... probably even worse than bad C code, and that gets pretty bad. I think that's partially why it has a bad reputation for a lot of people.

Re:Take away for me

[UnknownSoldier]

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 understanding what the machine is doing. People who suggest "Just throw memory / cpu / hardware at a problem" are piss-poor programmers.

However consider the majority of programmers 0.5% can't even grok a simple 4* case if-then statement of FizzBuzz ....

* http://blog.codinghorror.com/w...
* http://c2.com/cgi/wiki?FizzBuz...

... then I would say the bigger problem is teaching programmers to have critical thinking. Stop over-engineering everything. Here is an article on "Criminal Overengineering."

* http://coderoom.wordpress.com/...

This is the reason modern programs chew up megabytes of RAM and people _still_ are waiting on a GHz CPU.

Somewhere along the way we lost the importance of K.I.S.S. -- Keep it Simple Stupid.

--

* The 4 cases are:

  1. n mod 15 = 0, print fizzbuzz
  2. n mod 5 print buzz
  3. n mod 3 printf fizz
  4. default: print n

Re:Take away for me

[Anonymous Coward]

Picking Linux as a C example is probably a bad idea as that's an entire class of software that is only shared with the *BSD kernel's, basically the bug counts and patches for something "core" to a computer are going to be higher than something that just runs on top of it (user space, drivers,) and what runs in user space is going to pick something other than C because they have that luxury.

Most of the time, the reason to stick to straight C is to ensure compatibility with other OS or Library's. You can write C++ stuff and still have C bindings.

Everything else though. Error rate is related to what IDE, if any, is used. If you use an IDE that highlights syntax errors, you will make less of them. The Compiler will also play a factor, as C/C++/OBJC/C# and such can be configured to ignore certain warnings, which really should be considered errors. There are plenty of programs I've seen compiled on *nix where I see miles and miles of warning messages, but the application still successfully compiles. This is... gross really. It's like making hamburger or sausage and ignoring the insect infestation in the storage area.

Re:Take away for me

[duck_rifted]

It's strangely obvious that you're right in this case. Code is simply organization of non-ambiguous instructions and information. People organize both differently.

But I think the article is trying to shrewdly rebut the concept of using the right tool for the job. I can not agree with that underlying point because there are technical limitations that determine which tool is best for a task. A hammer isn't used to tighten a bolt, and Python isn't used for low level memory management. There are two studies that would be much more useful.

A task to language map based upon technical limitations would be very useful if it were well-developed. The key would be to begin by avoiding anything contentious. The map should depict the most obvious observations in a manner useful to those who are interested in learning to program. I would wager that there are very few people in the world who could author that map without assistance, straight from their heads.

The second useful study would investigate whether learning to program with a language that organizes information or instructions differently can train the brain to better communicate with people whose thoughts or knowledge are organized in a manner similar to that language. There's a conceptual level to learning that involves modeling the topic so that it can relate to familiar things. What applies to learning applies to communication.

Re:Take away for me

[Half-pint HAL]

The FizzBuzz test puts me in mind of something that was said to me on a forum recently: "not all computer programmers are mathematicians, nor should they be". This was in reference to me suggesting that code would be far more readable if we gave up our plaintext fetish and allowed our code editors to render the likes of (a+b)^2/(a-b)^2 using superscripts for exponents and showing the numerator over the divisor, as per maths.

If people think that sort of thing is too mathematical for computer programmers, I hate to think how such programmers would ever conceive of using a modulo operator to solve a problem!

But once we lower the bar that far... what the hell are they expecting people to code? I know these courses try to be as "generalist" as possible, but computers are number machines, and most useful tasks with computers involve numbers at some level...

Re:Take away for me

[Hognoxious]

Most computer programmers work on boring shit like accounting & inventory systems. You add, multiply and subtract. Sometimes you divide. You don't need to work out the prime factors of the number of widgets in your warehouse, let alone understand what prime factors are.

tl;dr: Working with numbers isn't necessarily maths; it might just be arithmetic.

Re:Take away for me

[Half-pint HAL]

Yes, but my point is that someone was seriously arguing against my use of superscript exponents and the "over" line on the grounds that that was maths, and not all programmers are mathematicians. That's a million miles from prime factors and the like.

Re:Take away for me

[Hognoxious]

I think I misread your point, and I think we actually agree.

The syntax is a bit of a frig to make it appear on one physical line, but if you can't mentally (or on a bit of scrap paper - I believe it's still allowed) convert it how it'd be written on a school blackboard) then I doubt you'd understand it whatever format it's in.

Some people do over-emphasise the maths (and in the US people seem to have a calculus fetish). I may have mistaken you for one of them. A maths-over-emphasiser, not an American.

Re:Take away for me

[Half-pint HAL]

I think I misread your point, and I think we actually agree.

Yes/no/maybe

The syntax is a bit of a frig to make it appear on one physical line, but if you can't mentally (or on a bit of scrap paper - I believe it's still allowed) convert it how it'd be written on a school blackboard) then I doubt you'd understand it whatever format it's in.

Some people do over-emphasise the maths (and in the US people seem to have a calculus fetish). I may have mistaken you for one of them. A maths-over-emphasiser, not an American.

There's two things in there -- overemphasising maths, and wrong kind of maths. Calculus isn't applicable to a lot of programming problems, so you're right that an emphasis on calculus isn't particularly helpful to the general programmer. Algebra similarly isn't much use, as in programming we generally have lots of fixed knowns, and a predefined unknown.

Graph theory, on the other hand, is an extremely useful way of conceptualising state-space and data, as graph theory leads to trees and to finite state automata. Even if you don't draw out the automata for a program you're writing, if you've properly studied FSAs, you will have learned how to think on that level of abstraction.

Set theory may not seem directly applicable, as it's not something directly compatible with the hardware layer, but there are plenty of problems that are best modelled as sets, and if you can't reason about sets, your code will end up very hacky.

You won't get very far in computer graphics without Cartesian coordinates, column vectors and matrix arithmetic. OK, so only a small part of grads are going to be dealing with graphics on that low a level. But that brings us to the crux of the debate:

Are computer programmers generalists or specialists? The current notion of this is somewhat confused. We are generalists because we are expected to be able to adapt to any type of problem; we are specialists because our skills are still relatively rare. But being generalists means not knowing what we're going to work on. If a university doesn't teach matrix manipulations, its students won't work in 3D graphics or physics modelling. If it doesn't teach statistics, its students won't work on statistical applications. The more conceptual tools we omit from our courses, the less the student can do.

The way I see it, my university did things right: we were taught general programming concepts and modes of thought. We were given the tools to think our way through problems in any area. It was a true "Computer Science" degree. On the other hand, the industry was complaining that CS grads weren't adequately trained that they could "hit the ground running" and be a productive programmer from day one, and there were more and more "Computer Programming" degrees springing up. I found myself going into my first job with a groups of peers who knew the main APIs of the most important technologies of the day and could sit at a keyboard constantly typing, but who couldn't reason through problems without the spec. Heck, on my first project, our database architect said a ridiculous thing: "you can't do that with computers". Erm... what? If he'd said that it was too big a processor load or had too high a memory requirement, that might be OK, but "can't do that with computers"...?!? Not only was it something that could be done with computers, but when I checked the documentation, it was a basic feature of the database software.

We cannot predict which conceptual tools (=mathematics) a programmer will need as long as the programmer is considered a generalist. If you want a maths-light course on computing, therefore, you have to know which field the student is going to work in. This brings us back to a notion that the teaching staff at my university discussed while I was studying there: that "programming" (as opposed to CS) should be incorporated into every degree course, adapted to the needs of the field. This was already happening with Physics and Math

More factors to normalise out.

[beelsebob]

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.

[Anonymous Coward]

Poppycock. It's caused by those languages being tools for shooting yourself in the foot. And the fact idiots still use those languages in areas where performance isn't an absolute priority is simple idiocy. Meanwhile, the smart people use HLLs and they strike the top five C/C++ issues off the chart entirely just by using an HLL. Perf issues are pretty much all that's left, so in fact people writing in HLLs tend to care quite a lot about performance, but only insofar as performance actually matters.

Re:More factors to normalise out.

[Wootery]

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:More factors to normalise out.

[Anonymous Coward]

So you make your only problem the one you can't solve.

Car analogy:
I can enter a Honda Civic in the Indy 500 race. I will only need to refuel once, won't need new tires, am likely to be reliable enough to finish every time, have AC and radio I can listen to. My only problem at this point is going fast enough to win the race, but that's "minor" compared to the rest according to you. You'd rather have a single impossible problem than 5 problems that you might have to actually work on but can solve.

Re:More factors to normalise out.

[K. S. Kyosuke]

The car analogy should include the fact that since the vast majority of people isn't facing the need to solve the Indy 500 problem, the very same vast majority of people is better served with learning to use more practical tools. A computer analogy would be using assembly language for a bootloader vs. using Python for whatever non-bootloader problem you happen to have.

Re:More factors to normalise out.

[naasking]

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.

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.

Re:More factors to normalise out.

[Anonymous Coward]

Pretty sure Shlemiel The Painter is just as easy to write in C as it is in a HLL.

http://www.joelonsoftware.com/articles/fog0000000319.html

Re:More factors to normalise out.

[SomeoneFromBelgium]

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:More factors to normalise out.

[Anonymous Coward]

Well now you're talking about the developer, not the language. What is a "hassle" to one developer is a triviality to another.

Re:More factors to normalise out.

[Wootery]

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.

[Wootery]

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++ are generally quite good at making it clear where something inefficient or expensive is being done, unlike many high-level languages where one creates short-lived intermediate data-structures without even thinking, involving lots of avoidable copies.

Re:More factors to normalise out.

[Wootery]

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:More factors to normalise out.

[Jeremi]

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 deterministically the instant you are done with them, rather than "at some time in the future, maybe". That determinism gives us the added bonus of making smart pointers also usable for managing other resources besides RAM -- sockets, file descriptors, etc)

Re:More factors to normalise out.

[naasking]

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.

Because smart pointers are degenerate garbage collection.

Re:More factors to normalise out.

[naasking]

Oh, I also forgot to mention:

and that your resources are freed deterministically the instant you are done with them, rather than "at some time in the future, maybe".

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:More factors to normalise out.

[pmontra]

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.

Re:More factors to normalise out.

[Jeremi]

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.

[Wootery]

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:More factors to normalise out.

[Anonymous Coward]

So determinstically collecting individual garbage once
is degenerate compared to
scanning the whole address space multiple times and guessing

Re:More factors to normalise out.

[Wootery]

But 'the C++ way' can cause cascading release of resources. See this comment below.

Re:More factors to normalise out.

[Anonymous Coward]

You're right... in the most technical sense of the word.

But what's wrong with using the STL (Standard Template Library) in addition to the C standard library ?

I mean... is there some compelling horrible reason you can't use the hashmap in /that other/ big honking well working library? It's been there since what...about 95 or so?

Re:More factors to normalise out.

[Half-pint HAL]

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

I beg to differ. A trivial example:

int fibonacci (int n) {
if (n==1 || n==2) {
return 1;
} else {
return fibonacci(n-1) + fibonacci(n-2);
}}

Ignore the incorrectness here (the infinite recursion when passed a negative number, and instead focus on the O(2^n) execution time. It's very, very easy to shoot yourself in the foot. (That's a first-year university example -- second year at the latest.)

And of course, there is a general tendency that languages that allow optimisation end up requiring optimisation. And while automated optimisation may still not be able to outperform the most skilled human coders, most of us aren't the most skilled, and we shoot ourselves in the feet all the time....

Re:More factors to normalise out.

[Half-pint HAL]

Typical "throw more money at the problem" bullshit here. You're probably one of these "hackers" who'll just start a tantrum when they can't run [insert shitty scripting language here] on an oversized microcontroller just to display the time on a fucking LED array. I bet you even own a Mac.

We have lots of cycles spare. The problem with [insert shitty scripting language here] isn't "scripting", but "language". Most scripting languages would be just as effective compiled (getting rid of "exec" would make Python far safer, certainly) and far more efficient. There are various tools that do either full compilation or just-in-time, and they all achieve some really surprising speeds (heck, even the SpeedBasic compiler for the C64 was adequate for game programming), it's just unfortunate that these are all separate and peripheral projects. There is no theoretical reason why someone shouldn't be writing code in any language they feel like and compiling to any platform.

Re:More factors to normalise out.

[mcvos]

Car analogy:
I can enter a Honda Civic in the Indy 500 race. I will only need to refuel once, won't need new tires, am likely to be reliable enough to finish every time, have AC and radio I can listen to. My only problem at this point is going fast enough to win the race, but that's "minor" compared to the rest according to you. You'd rather have a single impossible problem than 5 problems that you might have to actually work on but can solve.

It's a nice analogy, but you need to keep in mind that most people are just driving to work, not trying to win the Indy 500.

Performance is a very specific use case, and not remotely as important as it was during the 1980s.

Re:More factors to normalise out.

[naasking]

scanning the whole address space multiple times and guessing

You don't understand how garbage collection works.

Re:More factors to normalise out.

[Wootery]

But any C/C++ programmer worth their salt will be aware of the risks of unbounded recursion.

What I meant was C and C++ do not encourage inefficient use of data-structures in the way that, say, Ruby does. Creating lots of short-lived arrays, with lots of avoidable allocation and copying, is typical of languages like Ruby. One doesn't normally see it so much in C++, which goes to fairly extreme lengths to avoid such things (move constructors etc).

Of course, this isn't just about the language itself, but what the programmer is interested in: it is essentially a contradiction for someone to write performance-critical code in Ruby, but performance is one of the major reasons one would suffer C/C++.

Re:More factors to normalise out.

[Half-pint HAL]

Of course, this isn't just about the language itself, but what the programmer is interested in: it is essentially a contradiction for someone to write performance-critical code in Ruby, but performance is one of the major reasons one would suffer C/C++.

Which I think was one of the main points earlier up the thread -- that high-performance languages suffer more performance bugs than low-performance languages.

The work I'm doing at the moment doesn't need precise optimisation, and as long as I avoid O(n!) and O(2^n), the job will complete, and I'm happy enough. That's why I chose Python. Easy access to the things I need, and fairly straightforward to convert to a proper language once the code logic is proven.

Re:More factors to normalise out.

[Wootery]

Easy access to the things I need, and fairly straightforward to convert to a proper language once the code logic is proven.

I recently went Java -> C++ -> C, for some fiddly data-structure work, with good results. Have to be careful to pass objects by reference when you port to C++, but otherwise generally painless.

Republican Wave Storms Washington!

[Anonymous Coward]

And it's not just Washington, either. Yesterday's US elections were a resounding mandate to repeal Obamacare and impeach the communist that was installed in our White House in 2012 by a corrupt electoral college. We need to abandon the corrupt electoral collage and we will have a Republican in the White House in 2016 and people in this country will learn the meaning of work again - no more free Uncle Sugar rides for ANYONE. And I'm pretty sure ISIS would be a thing of the past within 6 months of a Republican president. It's time to give control back the the makers and eliminate the takers. So happy.... Obamacare will be defunded now.

Re:Republican Wave Storms Washington!

[BVis]

Fuck you.

Possible error in early pages?

[emagery]

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

[stealth_finger]

it says basically nothing

Or, to put it another way...

[jeffb (2.718)]

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

[Z00L00K]

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

[i kan reed]

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

[Anonymous Coward]

You can create abstract classes in C++, similar to Interfaces in other languages (Java, C#, etc.)
With multiple inheritance, you can implement as many as you like and how method calls are resolved is straightforward.

Of course you don't HAVE to use them that way, but you don't HAVE to use interfaces in Java or C# either. I've seen plenty of bad code in both, and I don't think Interfaces are the "magic."

Re:Or, to put it another way...

[penguinoid]

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:Or, to put it another way...

[i kan reed]

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:Or, to put it another way...

[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 was using. In this way I kept bugs out of the code by having a comprehensive suite of tests. Since moving to Ruby, I've found that TDD practices are more ingrained than with a language like Java so the lack of compiler errors doesn't bother me. Early on in my career code was deemed correct if it compiled, even if it wasn't tested, which has put me off relying on the compiler too much.

Re:Or, to put it another way...

[Anonymous Coward]

What is really happening is that applications that are easily implemented using a functional, static, and strongly typed language are less error prone. An application that requires the flexibility of C is more likely to have errors. An application that is coded in C but that doesn't require the flexibility of C is less likely to expose the programmer to the pitfalls of C.

Re:Or, to put it another way...

[Ottibus]

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:Or, to put it another way...

[i kan reed]

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:Or, to put it another way...

[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 standard, but the GNU compilers are much worse at consistency, even across versions. Something compiled with 2.95.x won't co-exist with anything newer.

That's just one problem with the C family.

Java (and similar efforts like C#) takes all the problems of C, and adds the overhead of trying to interpret it to native or pseudo-native instructions. So If performance was your concern for C, "Being able to run on any OS without recompile" is Java and C#'s. Unfortunately, that's not the case either. OpenGL use tends to throw this idea out the window because now you have to add different rendering pipelines INSIDE Java/C# for each OpenGL or OpenGL ES variant, thus getting rid of the concept of "pure Java" or "Pure C#"

So if you're going to develop a game from scratch, you may as well skip trying to do anything in Java and just use C the first time. You're better off writting your own graphics wrappers per OS, than trying to fudge it inside Java .

Now, interpreted things (Ruby, Javascript, Perl, PHP, Python, etc) have one advantage over everything else. You can generally just hit "run" and figure out what it does. They're much easier to reverse engineer. The tradeoff is that they are 100x slower than native. So where you use interpreted languages without stupid hacks (eg webGL, asm.js in web browsers) you get slow performance compared to something native, as interpreted languages lack the ability to actually use native threads, and instead rely on "single-threaded" behavior, even though it may multithread some parts of the underlying support code in C/C++. So, "Nice octa-core processor you have there, too bad my dual core runs circles around it because it has a higher clock speed."

I really hate this entire "lets make everything a web app" approach lately. There are various things that can, and should, get away with it (eg email), but let's quit fooling outselves that we're going to get "native" console performance in a stupid web browser. Yay I can run a 15 year old game in the browser, big whoop. Call me when the latest 3D FPS game runs in a browser at the same performance as a console.

Language choice should consider the target platform's "today" performance first. If today's consoles and desktops have at least 2 cores, there is no reason NOT to multithread it. Software like x264, ffmpeg, make use of all available CPU and GPU power they can reasonably expect to use. OpenCL use is still limited, and may never get any practical use outside of sciences since the GPU is better used for graphics, and for some damn reason everyone is hellbent on putting weak GPU's in tablets, notebooks and entry level desktops to ensure OpenCL doesn't get used.

Re:Or, to put it another way...

[alphabetsoup]

There is absolutely no difference between an interface and an abstract class with all virtual functions, no default implementations and no data members. Multiple inheritance is strictly a superset of interface inheritance.

Besides, unless you need to store the base class pointer in an array, you will in most cases be better off using templates instead of inheritance anyways :)

Re:Or, to put it another way...

[Anonymous Coward]

Either you've failed to communicate what you actually meant to communicate, or you actually don't realise that there's no difference between the two cases.

An interface (in the sense of e.g. Java's "interface" concept) is nothing more than an abstract class, i.e. one which contains only pure virtual methods.

Implementing an interface in Java and inheriting from a class which contains only pure virtual methods are exactly the same thing.

The only difference is that Java requires that all but one of the base "classes" are interfaces, while C++ doesn't impose that restriction.

Re:Or, to put it another way...

[the_arrow]

Speed isn't all that it used to be. 30 years ago you wrote games in assembler, 20 years ago in C, and 10 years ago in C++. Today? You can write a game that looks as good as the best games did ten years (or less) ago in Java Script or other purely interpreted languages. With JIT languages (like Java and C#) you can even rival other modern games.

Speed was an issue with processors in the low MHz range, with todays multi-core, multi-GHz beasts with dedicated graphics hardware you don't need to code everything in assembly for speed, it's going to be fast enough anyway.

Re:Or, to put it another way...

[rioki]

Honestly I think the culture an community surrounding the language has way more influence on quality than actual language features. Take languages like C, C++ or Perl. They they where born during a time where people actually designed software and mostly knew what they where doing. Although Perl is more gung ho than C, but the design is clear, be simple and don't get in my way, I know what I am doing. The average developer is more rigorous, but the language lets you shoot yourself in the foot.

In contrast take languages like Ruby or Python, where you are booed out of the room when you don't have unit tests. This has the perversion where unit tests are written for trivial tasks or in way that is totally ineffective, but YOU CANT'T PROGRAM WITHOUT TESTS. Here the quality comes mostly through process that is indoctrinated in the community. The programmers don't pay much attention to what they are actually doing, if it does not trip a test, all is well.

JavaScript for example a difficult one. JavaScript in the browser is mostly "I can programz, YOLO", like PHP it was born in a community of hobbyists with very little quality control. Their awesome utility made them the center of an industry and as developers from other fields came into the industry the community slowly stated adapting more rigor towards design and quality. Here the quality can be all over the place. In contrast JavaScript in the context of node.js, is totally different. Node.js came to a certain degree from web developers communities, like ruby on rails, they for example took the unit testing rigor with them.

As I noted, the community and culture in which the language is used, is probably the dominant indicator.

Re:Or, to put it another way...

[rioki]

Would you feel better if you replaced "abstract base class" with "interface"? I will immediately accepts that non abstract multiple inheritance is a feature that you can do without; like goto. But the actual problem is not simple multiple inheritance, that is quite simple to reconcile, but the moment the inheritance graph forms a diamond. (Do you have tow "instances" of the base class or only one?) But the use of single inheritance and multiple ABC's is no different than the use of interfaces in C# or Java. Then again, I think inheritance is THE over used feature in C++.

Re:Or, to put it another way...

[rioki]

Basically it depends. Speed is not "that important", but number of physics enabled objects on screen are. And here is the corundum, you can probably control and render a huge number of objects in say JavaScript, but never actually simulate them. The result is that the physics kernel is written in C/C++ and maybe brought into a scripting language via an API. Also the rendering core (OpenGL/Direct X) or database are written in C/C++, since they need to be fast. Your assertion is correct, high level application code often is not the critical path in performance. But low level components are, databases, drivers or simulation packages, and these are written in a language that compiles natively. But then again, there is a high chance that you are not developing one of these low level components.

Re:Or, to put it another way...

[jeremyp]

You can create an interface in C. Just typedef a struct with a bunch of function pointers. People implement the interface by creating an instance of the struct and filling in the function pointers.

It's actually a fairly common pattern. For example there are several described here

Re:Or, to put it another way...

[mcvos]

For really, really high performance code, of course you use the highest performing language. But that's a pretty extreme use case. Most games do not require huge numbers of simulated objects on the screen.

Re:Or, to put it another way...

[rioki]

Do not require or are designed to not require a high number of objects? If I get a dollar for each time a designer or artist bitches about them reaching the polygon/object budget, I would be rich. If you would let them they would cram the levels and geometries full of stuff and most gamers would love it. The reality is that the scenes are carefully designed to not tank. Granted More's law has helped, but more efficient code will always make people happy. But if your script code just sits around an waits for it's next tick, you cam make it inefficient, but you will bitch if your collision test takes "forever".

Other factors.

[LWATCDR]

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

Re:Other factors.

[pushing-robot]

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 might conclude children with large feet have better reading skills.

Re:Other factors.

[beelsebob]

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.

[Errol backfiring]

On the contrary. Lots of casual programmers use SQL.

Re:Other factors.

[naasking]

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.

Re:Other factors.

[Anonymous Coward]

On the flip side of the coin, NESL is a functional language without closures but with referential transparency. It was one of the languages for the Connection Machine, which was a 64k-cpu SIMD machine back in the 90's.

Re:Other factors.

[JesseMcDonald]

Wikipedia gives a good general-purpose description of functional programming:

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 rules. Any call to external code may perform I/O or depend on or modify global mutable state.

Re:Other factors.

[phantomfive]

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.

Re:Other factors.

[romons]

Statistics is hard. You can't simply use a random selection, or else you might conclude children with large feet have better reading skills. [rationalwiki.org]

Well, if the point of statistics is to predict things, then causality is immaterial. If you have a list of children, and you have their shoe sizes, you can use the statistic to predict their reading ability. If you are trying to understand the causes of reading ability, you aren't going to pick a statistic that includes shoe sizes. So, the whole 'correlation isn't causation' trope is, in fact, nonsense.

The article is trying to predict bugs based on language. To that end, it doesn't matter if there is causation, it just matters that there is correlation.

Re:Other factors.

[JesseMcDonald]

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 programs functional. Programmers being programmers, the end result is procedural programming in a functional-capable language.

The pure functional languages, on the other hand, push programmers to actually use the functional style. Even when they support a familiar procedural syntax (like "do" notation in Haskell) the evaluation model remains referentially transparent. Since the whole program is guaranteed to be referentially transparent, it's much easier to reason about its behavior, both for the programmer and for the compiler.

Re:Other factors.

[phantomfive]

I agree that it would be interesting to see a definition of object-oriented programming which didn't include Smalltalk.

There are two main ideologies of OOP, the Smalltalk way which is centered around (briefly) message passing, and the Liskov/C++ way which is centered around (briefly) strong types. Occasionally you'll see someone in the Liskov ideology define OOP in a way that omits Smalltalk, similarly to what you've done to Lisp. Show me a language that has no side effects, and you can lecture me about 'pure functional.' Otherwise it's just smoke and mirrors.

Re:Other factors.

[Anonymous Coward]

Are you not entertained entertained?

Re:Other factors.

[Half-pint HAL]

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 programs functional.

Almost. Lisp is multiparadigm. As part of that, it is a functional language, but that doesn't automatically make all Lisp programs functional. Lisp is functional because the syntax is built on expressions rather than statements (except perhaps the top-level "defines"). Code can be executed sequentially through begin...end blocks, but that's still a hack layered on top of functional syntax -- you are calling functions, then throwing away the return value (statements conceptually have no return value, although languages such as C assign success/failure flags to them). Everything is a function (even if not pure functions) and functions are first-class citizens. That's the core of FP.

(Although I personally feel impure FP is a waste of time, as it's missing the correctness and determinism of pure FP, thus not really making the code sufficiently bug-safe....)

Re:Other factors.

[naasking]

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 rules. Any call to external code may perform I/O or depend on or modify global mutable state.

Sure, but triggering side-effects during a fold can be perfectly sensible, and this doesn't make functional programming languages any less functional. Find me one person that considers this program to be non-functional, as your definition does:

let main = let list = [10; 2; 99; 30; 3] in
    map (fun x -> printf "%d\r\n" x);;

Also which languages that beginners choose.

[EmperorOfCanada]

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:Also which languages that beginners choose.

[Mr Z]

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 beginning, so really C was where I grew from a college-aged hacker to someone who can actually program. Now guess how old I am. ;-)

I guess for an analysis like this, you really need to limit yourself to people who consider themselves competent programmers. Those VB macro whizzes in accounting likely consider themselves accountants, not programmers. Likewise for the physicist with a pile of creaky MATLAB models.

BTW, I have to agree with you 100% on make and bash. I consider myself above average on make as compared to my coworkers, but that's an extremely low bar. And while I've done some crazy stuff in bash in the past, these days I'll hop over to perl for anything more than 10 - 20 lines, especially if I find too much 'sed' showing up or find myself wanting an actual data structure.

Re:Also which languages that beginners choose.

[Anonymous Coward]

Wow, same progression for me, only I worked with C++ before Perl. I did a lot of work with assembler on intel/motorola processors and developed embedded systems with my own RTOS. (wrote task switcher / scheduler in assembler and other critical areas, but the rest was mostly in C/C++).

My first C compiler was "Small C" (Dr. Dobbs), leading to Microsoft C, Turbo C, Lightspeed C, MPW C, GCC, etc. (A good friend of mine was actually the lead developer of Borland C++ 3.0, smarter fellow than myself!)

I have to say that I have gravitated to Perl for most quickie projects where I just need to do some fancy data extraction or manipulation. I just love regular expressions and having this basically built into the language is awesome! Data structures like tied hashes are also nice.

I always come back to Perl for simple projects. It seems universally easiest to use on any OS platform and gets the job done faster than anything I can think to use.

-Carl

Re:Also which languages that beginners choose.

[Mr Z]

FWIW, I technically had some C++ before Perl, but not enough that I count it.

Re: Perl: I'm much the same way with Perl. I use Perl for lots of quickie projects. Great for anything I'm only going to spend at most a couple days developing.

Perl's also great for much larger projects too, where runtime performance isn't absolutely critical but flexibility and development ease is paramount. We actually have some fairly significant projects at work that are written in Perl.

One of them, which embeds Perl in another language as a metaprogramming language. I couldn't imagine trying to write that in C++ without a dedicated team. But, a set of hardware designers are effectively maintaining the tool in the background thanks to it being written in Perl.

Re:Also which languages that beginners choose.

[Anonymous Coward]

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.

Wonder if that is why so many are poo poo ing on shell scripts these days...

You need enough rope to hang yourself

[msobkow]

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

[Shados]

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

[SQLGuru]

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

[DarkOx]

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

Re:You need enough rope to hang yourself

[Anonymous Coward]

you forgot C++. Between Boost.Phoenix and c++11's lambdas, you can program in a functional style where it makes sense to, and drop back to OO or procedures when you need to.

Dynamic languages are shit for anything large. You come back after 3 years, or get a new maintainer, and you need to read most of the code base again just to begin to guess what each variable actually is and what each function does. That thing someone assigns to 1 make end up being a string later, after all.

Re:You need enough rope to hang yourself

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

Re:You need enough rope to hang yourself

[cdrudge]

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

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

Re:You need enough rope to hang yourself

[K. S. Kyosuke]

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 ordinary type systems in statically typed languages are very weak).

Re:You need enough rope to hang yourself

[phantomfive]

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'

Re:You need enough rope to hang yourself

[dwpro]

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:You need enough rope to hang yourself

[K. S. Kyosuke]

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.

Re:You need enough rope to hang yourself

[theskipper]

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

KISS

[polar red]

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

Re:KISS

[internerdj]

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

[Anne Thwacks]

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.

10 goto 10

[Anonymous Coward]

run

why are subjects necessary?

[Anonymous Coward]

Does anyone know of an all encompassing check of which factors affect code quality most, without focusing on programming language?

Language

[ledow]

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.

Re:Language

[Anonymous Coward]

You can code sloppily in any language.

All this tells me is that there's so little difference.

Interesting; I agree with your two statements but take the other lesson. Even though programmers are probably making the same mistakes in the better languages, the strength of those languages is still visible. In which case we should definiteily use them. I wonder if we don't both have confirmation bias.

Re:Language

[Anonymous Coward]

This seems to be a free compiler for Ada. Does it perform poorly or you mean it's expensive because it implies hiring someone who knows Ada?

PS - This is an honest question, I have no idea about Ada, the language.

Re:Language

[TVmisGuided]

The license for GNAT GPL allows for FOSS development at no cost. Commercial development, however, typically runs around $25000US for up to five seats.

Re:Language

[Boronx]

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.

Re:Language

[shaven_llama]

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 meant there was no way for me to do a complete build and actually test my module -- all I could do was run my code through the Ada compiler and let it do its error checking. The schedule was overly-optimistic of course, with all testing pushed to the very end of the project (waterfall).

I coded slowly, and carefully -- pausing often to run the code in my head. I was being constantly harrangued for being behind on my SLOC (occasionally even going backwards, a grave sin). Finally, 3/4 of the way through the project, a code repository was set up. I submitted my code to the one blessed person who had permission to commit to svn on my behalf, and weekly builds were provided for testing purposes.

My stuff largely just worked (and suddenly I was no longer a slacker in the eyes of others). I left that job with a new respect for Ada, though I never used it again. I program in Java (blech) these days, becuase I like being employable.

Re:Language

[Anonymous Coward]

The license for GNAT GPL allows for FOSS development at no cost. Commercial development, however, typically runs around $25000US for up to five seats.

No. The license for GNAT allows you to use it for any type of project just like GCC does for C and C++. What you are paying for is support, binary versions that have through been some some level of testing, any certifications on that binary, packaging, and whatever add-ons they might have. You do NOT have to pay AdaCore just to develop and deploy a commercial application.

Granted that anyone using Ada for a serious application is going to pay them for support. But it is not required.

Development effort not considered

[pem]

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.

Re:Development effort not considered

[lars_stefan_axelsson]

They discuss prior studies that looked at development effort, but hand-waved away the fact that dynamic languages take less development effort.

Only with the old style "straight jacket" static typing. With a modern Hindley-Miller type type system, effort is a wash at worst, and in most cases static typing is a clear win as you're not nearly as dependent on testing to find the simple, common brain farts or typos. (And if you're using tools to find those, then guess what? Then you're using static typing, only poorly implemented static typing.) Also, those types, when you've taken the complete step towards typeful programming, serve as wonderful documentation etc.

Re:Development effort not considered

[pem]

> Only with the old style "straight jacket" static typing.

Dynamic languages don't have to be dynamically typed.

Re:Development effort not considered

[lars_stefan_axelsson]

You mean they don't have to have types at all? That's even worse...

Or is it just one of those tedious semantic confusions that are so common when discussing programming languages and types. Do you mean something else by "dynamic language", if so what exactly?

Summary

[Dan East]

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.

Bad programming language = High TIOBE index

[Anonymous Coward]

the TIOBE index is assembled by the number of posts about the programming language. A good language will therefore lead to less references (no complaints or questions on fora), and the less references it has the more it seems to be dead language.

How to measure quality?

[Roodvlees]

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?

Right

[Anonymous Coward]

Because people that insist on using sh*t languages like Java, C#, Ruby, Python, etc., are going to write sh*t code, no matter what.

Re:Right

[risht]

What's your list of "not shit" languages?

Nothing to see here, move along...

[yorgo]

From the summary:
“they report that language design does have a significant, but modest effect on software quality.”
“strong typing is modestly better than weak typing”
“static typing is also somewhat better than dynamic typing”
“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”
“we hasten to caution the reader that even these modest effects might quite possibly be due to other, intangible process factors” ...and from TFA:
“Hence, we are unable to quantify the specific effects of language type on usage”

Paraphrased: “Findings were inconclusive.”

Language

[TVmisGuided]

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.

Winner is...

[funkymonkjay]

Typescript? yea... thanks for that.

I think the biggest take away for me is that there isn't a huge variance. What are we talk about.. 2% max?
I was hoping to see something amazing, say 20% difference between java and scala. something i could really take to my boss and say "SEE! we need to switch".

How did they measure quality?

[MobyDisk]

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.

Re:How did they measure quality?

[Anonymous Coward]

I saw that too, or didn't see it. It's a major weakness of the study IMO. Measuring software quality is a young science, but it's about SO much more than bugs identified.

Look at any list of -ilities for a start on what I mean. SQALE is a good start at formal measurement. See also, Technical Debt and Nemo.

Concurrency bugs found in highly concurrent langs

[Count Fenring]

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.

You're asking the wrong question

[Anonymous Coward]

Assuming several programmers with equal coding skills I think that the compiler they choose has a bigger impact on the quality of software produced than the language used. If you have a programmer that produces nice, really tight high-quality code and he runs it through a compiler who's libraries (or "optimization" routines) were written by a poor-quality sloppy programmer, it is going to produce sloppy bug filled software.

Language does have some impact on software quality as specialty languages existed in the past to fill narrow niches (i.e. SNOBOL was specifically designed to do string manipulation) and if you use a language outside it's niche you are going to produce a poorer quality software. BUT overall software quality it is going to depend on the compiler and link-libraries used.

Script languages have few concurrency errors

[ziggystarsky]

See Figure 2. They even stress this in the text:

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

Now everyone knows that Erlang is bs for doing concurrent stuff, right? I do all my concurrency related programming in Ruby, as every other sane developer would do!

redistribution FYI

[MouseR]

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 Copyright 2014 ACM 978-1-4503-3056-5/14/11 ...$15.00.

Perl Gets No Respect

[Anonymous Coward]

Only scanned the article but this jumped out -- when discussing Table RQ1. they say --
"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."

Ruby has a negative coefficient of -0.15 which is the same as Perl's -- why isn't Perl on the "good language" list?

The only other mention of Perl is to highlight its database issues (along with C -- and the disclaimer that these may very well be MySQL use problems).

Table 2. has an interesting thing - Perl has the lowest number of project bug fixes out of the whole list. And comparing that to another language with around the same number of projects (PHP with 109 and Perl with 106) -- bug fix comparison is 1903 for Perl and 47,193 for PHP ! Maybe the number of authors working has something to do with this (86 for the Perl projects and 3892 for the PHP).

Re:Perl Gets No Respect

[Anonymous Coward]

Well, since Perl can only be written and not read, perhaps there was no way to count the errors.

The case of COBOL

[mwvdlee]

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, it would probably be rated as an incredibly stable and secure language as well.

Re:The case of COBOL

[Anonymous Coward]

NASA already used Brainfuck for their metric to imperial converter.

Re:The case of COBOL

[phantomfive]

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:The case of COBOL

[Anonymous Coward]

> I used to be a COBOL, PL/1 and Java programmer ... so I have some insight in the quality aspects of both languages.

There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.

Re:The case of COBOL

[iggymanz]

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:The case of COBOL

[mwvdlee]

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 problem at all; it should look like any idiot could have made it.

Re:The case of COBOL

[phantomfive]

Code should look like it doesn't solve any problem at all; it should look like any idiot could have made it.

Well said.

Re:The case of COBOL

[phantomfive]

What makes you think you are qualified to assess the quality of COBOL code?

Good code is recognizable. See also this comment. I've never seen cobol code that have handled financial transactions for over a decade.

Emacs!

[Bob9113]

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

Re:Emacs!

[Xyrus]

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:Emacs!

[labnet]

HaHa... Modded Insightful!!

Re:Emacs!

[Data Forms Action!]

I think you got that the wrong around buddy! Which is quite typical of Emacs users I'm led to understand

Re:Emacs!

[Anonymous Coward]

Even if that is the case, it's still not nearly as good as software written in ed.
There is a reason why ed is standard!

Re:Emacs!

[lars_stefan_axelsson]

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

Well duh! Emacs is written with Emacs, so that's trivially true.

How Many Projects Used Specifications?

[Anonymous Coward]

Did they control for whether the project bothered with good SW project process, like the use of specifications versus "cowboy* coding"?

Bad code is as much a function of poor (or nonexistent) design as it is language choice.

Yours,

A long-suffering ex-SW-engineer who's been a Tech Writer for 30 years, begging the fools to do a design spec up front.

Re:How Many Projects Used Specifications?

[Anonymous Coward]

* cowperson?

software procreation efficiency

[Grindalf]

Sometimes, the gentle pace of machine code development can be augmented by the adoption of a “FORTRAN” compiler. That's what I thought!

as a perl wizard....

[goombah99]

all i can say is neener neeener neener

Re:as a perl wizard....

[Camel Pilot]

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 "

Although not mentioned by name Perl's coefficient was -.15

Re: as a perl wizard....

[spike hay]

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: as a perl wizard....

[Anonymous Coward]

Confirmation bias is alive and well...

Re:as a perl wizard....

[Anonymous Coward]

Only because perl is read only, you don't fix defects, you rewrite the whole thing

low level programmers understand data structures

[raymorris]

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-linked list, and several arrays. The JavaScript, PHP, or Perl version will probably use an associative array for all three cases. Heck, in Perl OBJECTS are normally associative arrays (hashes) which have been blessed as a particular class.

Architecture and Process!

[Anonymous Coward]

Architecture and process are more important than the language/system chosen. Process includes proper QA testing as well!

Lies, Damned Lies & Statistics

[Anonymous Coward]

What a wonderful piece of statistical analysis! The only problem I can see is that there is no (and probably cannot be) any analysis of the effect of program design methodology, which I think would be of vastly greater significance.

Concurrency bugs found in highly concurrent langs

[SlowMovingTarget]

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

[jeorgen]

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.

Used tp be pretty simple.

[Anonymous Coward]

Don't use COBOL for performing statistical analysis, and don't use FORTRAN for lots of string manipulation. And C. Always use C.

fundamentally flawed

[Anonymous Coward]

They correlate everything to the code-size of any project.

BUT they don't take in to account that strongly typed languages (e.g. JAVA) need almos 5 times as much code to do the same as in e.g. Ruby. So there might be little less BUGs in the JAVA-Implementation per SLOC, but a lot more BUGs overall to achieve the same goal.

Even worse, the complexity doesn't grow linear, so logic errors will be way more likely in the 5 times larger JAVA-Project than in the smaller project.

On the other side, bigger projects, that need more than just a few programmers, can probably be coordinated easyer using a strongly typed language.

Burn PHP

[Hadlock]

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.

Where is Eiffel or Spark/Ada or Oberon2 or Modula3

[Anonymous Coward]

Strong typed functional languages where designed to produce higher quality programs but should be compared to imperative languages also designed to reduce defects and rise quality like Eiffel or Spark/Ada or ComponentPascal/Oberon2 or Modula3... just saying

C++: the biggest joke ever played on developers

[Squidlips]

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

How much production-quality code is on GitHub?

[Anonymous Coward]

I just wonder what percent of GitHub projects are professional-quality code. I mean, the amount of code Google puts on GitHub alone is enough to skew things towards low-quality code.

fundamentally flawed

[Anonymous Coward]

Code size to strongly typed mostly only correlates in languages lacking good type inference. Haskell code is extremely strongly typed, but also extremely dense, and type annotations are mostly not required - just nice for documentation.

I have just one word for you

[Daniel Hoffmann]

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 in Java could be handled just as well with less boilerplate code with a simple anonymous function in Javascript.

Re:I have just one word for you

[david.emery]

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 compiler can check. (This is particularly true for strong typing, where in my experience the bugs caught by typechecking are caught on scalar types. You're a lot more likely to add 'count-of-apples' to 'count-of-oranges' than you are to actually try to add apples and oranges.) Thus as a designer, I'd concentrate on the algorithm, logic flow, etc, and let the compiler check things like parameter names/types. When the compiler and I both agreed that the program was right, it usually was correct.
    3. Syntactic error recovery. This is a big deal when first learning a language, and later when doing significant changes (e.g. refactoring). On a lot of compilers, a single syntax error made all the subsequent error messages both numerous and confusing/worthless (usually because the compiler made an incorrect assumption.) Ada compilers, particularly the hand-craft GNAT parser, got really good at providing meaningful error messages for the rest of the compilation after detecting (and recovering from) a syntax error.
    4. Better optimization. The more info the compiler can get and depend on, the better job the optimizer can do, mostly by limiting the assumptions about how data or control flow is used.

"boilerplate" can be your best friend, when you and the compilation system take advantage of it.

Re:I have just one word for you

[WuphonsReach]

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.

Re:I have just one word for you

[Daniel Hoffmann]

Boilerplate sometimes take the appearance of real code, for example Javascript has a .reduce function for Arrays while Java does not have the same for Lists. This actually happened to me while I was doing some UI vs Backend stuff, I had to find the smallest value in an array of objects in Javascript (and the analogue List of Maps in Java) Sure I could roll my own reduce function or find a generic library to provide it for me but I would probably only use it once, so my Javacript ended up using [].reduce while my Java used for(a : b). Plus the anonymous inner class that any List reduce function would pobably need in Java ( = 7).

Test frameworks

[jlowery]

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.

Re:Test frameworks

[Anonymous Coward]

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.

Citation? Evidence? Proof? Wishful thinking? Religious Belief?

I have seen projects where the logic and performance bugs happened in large part (in my estimation) because the language used didn't support a sensible type system. A sensible type system allows a small number of highly experienced developers to limit the damage the many less experienced folks can do.

Note that "less experienced" does not solely include the young, often it refers to the old-timers with lots of domain-specific knowledge but not much experience thinking about how to write good software or experience with modern tools and techniques for software development.

I use the word "sensible" instead of "strong" because some Perl programmers will insist their language has a "strong" type system, as a result of "clearly" distinguishing between hashes, scalars, and arrays...

Very few Perl-people have sufficient variety of real-world experience to understand why compile-time type checking can be a godsend. These people tend to be the source of most of the unwarranted prejudice against the languages with sensible type systems.

In addition to allowing one to find lots of bugs at compile-time, sensible type systems make writing self-documenting code much easier, not a bad thing given the typical lack of professionalism one encounters in most developers with respect to writing documentation (especially that same group of "less experienced" folks).

Good test suites are certainly a nice thing to have, but they are at best a supplement to having good underlying tools, processes, and practices. It is impossible to simulate many complex systems and cover a significant portion of the state space, in the time allowed and with the manpower available to most organizations. Even with our computing grid -- lots of super fast, modern machines with huge amounts of memory -- we often run into simulation time limitations. Paying for the licenses needed to run all those tests is another issue, for those of us not able to run open-source.

Too Bad Ada wasn't included

[david.emery]

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:Too Bad Ada wasn't included

[Squidlips]

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.

low level programmers understand data structures

[Anonymous Coward]

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 the string class does when passing by value. After many posts they came up with a optimised version, it was about 100 lines of code (original was 10 lines), with lots of references passing and explicit and complex template instantiation of the hash map and its iterators. It was still 1.2 times slower than the Python implementation.

And the rest of them?

[Evan Langlois]

Too bad they didn't include Smalltalk or Self

Re:low level programmers understand data structure

[Anonymous Coward]

That's hard to believe that Python, running on a C++ interpreter, is somehow faster than a native C++ module.

Who gets to decide?

[DavidCBillen]

I've programmed over 30 years professionally. If there's every been an occasion, (on at least a medium sized project), where the choice of programming language wasn't pretty much dictated by some kind of requirements - I can't remember it.

so, static == more defects?

[Fubari]

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?

Re:so, static == more defects?

[DMUTPeregrine]

Nope, though it's confusingly worded.

C, C++, JS, etc, have more instances where someone committed a fix for a bug (as opposed to new code).
Clojure, Haskell, etc, required fewer bugfix commits.

Re:so, static == more defects?

[mcvos]

I don't think that quote says anything about static versus dynamic typing, as each group is about 50/50 divided between statically and dynamically typed languages.

Re:so, static == more defects?

[Anonymous Coward]

Look at the summary charts - the Proc-Static-Strong-Unmanaged were the worst by far. That is C++, C, and Objective-C. The only safe ones that were better were functional languages and the Proc-Static-Strong-Managed (like Java, Go, C#). So the scripting languages were less prone to defects than C++ or C.

does have a significant, but modest effect

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

Re:does have a significant, but modest effect

[DavidCBillen]

It makes sense. Don't think "significant" like "important". Think "significant" as opposed to "insignificant".

Re:does have a significant, but modest effect

[phantomfive]

i am unfamilliar with how these words together make sense.

It makes sense in statistics (and science, and math, things you should familiarize yourself with).

1) Scientifically, 'significant' means measurable, or observable.
2) modest means it was small.

So this means that there was an actual difference that was measurable beyond the noise of their observation tools, but it was a small difference.

Re:does have a significant, but modest effect

[Anonymous Coward]

Significant as in not insignificant, not entirely irrelevant. Think statistical significance. Still modest though, i.e. small.

Re:Where is Eiffel or Spark/Ada or Oberon2 or Modu

[dpilot]

Unused. I'm a bit amused to hear them refer to their examples as "strongly typed" languages.

Re:low level programmers understand data structure

[gwjgwj]

Passing strings by value is usually done with reference counting, so it is not such a large problem as it seems.

Higher level languages are usually better

[Anonymous Coward]

The higher the level of the language the less lines of code need and the more productive the programmers.

Re:First Post!!!

[Hognoxious]

In Soviet Russa, frist psot misspells YUO.

Also, Bennet Haselton sucks Poettering's Hosenwurst.

No Ada?

[mnooning]

In the pdf, the University of California studied the effect of programming languages on software quality without including Ada, the one single language that is designed for software quality. That says more about the U of C than the study says about it's intended topic.

Bullshit....

[gweihir]

They forget that a language, like any tool, selects the people that work with it and that the type of project does as well. These results are worthless, but will, as usual, cause some clueless bean-counters to make decisions based on them.

hmm

[MakersDirector]

Programming language, much like a spoken language, influences the design of the systems being implemented.

That's a no brainer.

However, there's more to this than meets the eye.

To me, a programmer is an artist. Who paints with code. Take the artist's background and experiences. Cultural values. Their language. Their gender. And more. And ask them to implement something unique in their favorite language and my bet is - chances are you will have a different implementation, every time.

But programmers, to me, are not that much different than lawyers, than doctors, than scientists, than tv show and movie produces and directors, and so on. Each may have their vision or perspective. Each may think they're being unique.

But given the tools, language, and constraints they have to work with - with time, material , and resources - my suspicion is the product created will always be different.

But then again. i am dirt poor as a homeless guy after spending 30 years with ideas to build a holodeck and software for it, and would like to do it with Windows XP, OPENGL, and Visual Basic, and accordingly, no one wants to support me on this.

especially since Microsoft discontinued support for XP.

Especially since I want to take my time on it to do it right and not worry about budget with the hopes that the hardware will manifest itself.

Yep. I'm a dreamer.

having a chaotically ordered mind who firmly believes I have seen alternate realities and timelines probably doesn't help with the credibility building in a linear based world, right? I mean. How do I convince someone that alternate realities exist because that's what I am going to be creating and would like to get funded on, when no one seems to understand it and I am the only one who's seen them??

ughhh. Life as a former programmer and (in another reality somewhere) former NSA grunt.

Read this!

[Anonymous Coward]

http://norvig.com/java-lisp.html
http://programmerhrishi.blogspot.fr/2013/02/lisp-versus-ccjava.html
http://benchmarksgame.alioth.debian.org/u64q/lisp.php

Re:low level programmers understand data structure

[frank_adrian314159]

As an old school Lisp programmer, I just use them like assoc lists.

Re:Concurrency bugs found in highly concurrent lan

[sergueyz]

More than that, fellows pointed that what they consider TypeScript are XML files from Qt projects, where layout and everything reside.

This study is flawed albeit flattering to my view.

Concurrency bugs found in highly concurrent langs

[Anonymous Coward]

I thought that to but then I thought that languages with concurrent features will probably be used to write programs with concurrent features and are more likely to have concurrent bugs. C++ programmers are less likely to go multithreaded in their projects than perhaps Clojure programmers.

wtf? Don't blame the semantics in the language

[el_jake]

Don't blame the semantics in the language - blame the meat head 40 cm in front of the illuminated screen!

Eat Code.

[Anonymous Coward]

Can I get an abstract for my abstraction please? My dependency resolvers are injecting all over themselves.