Live data from Hacker News

On the Impact of Programming Languages on Code Quality

arxiv.org

31–40 of 138 posts

Re: On the Impact of Programming Languages on Code Quality

#31

My own take of this: - This study tries to enhance the original work by better metrics (e.g. confusion with C/C++), using better statistics (e.g. uncertainty). - Automatically evaluating the quality of a code is hard and time-consuming. They had to use peer review of labellisation. - Most of the old claims are not confirmed. - Only 2 languages in this study had both a significant impact (impact coeff) and enough fiab…

"... and there may be other influencing factors."

Selection bias? Consider the type of person likely to be attracted to languages like Haskell or Clojure.

(Note, didn't read the original study so I don't know the selection criteria. Were code samples in different languages from the same programmers compared, or were there different sets of programmers per language? My comment really only applies to the latter case.)

Re: On the Impact of Programming Languages on Code Quality

#32
Casual observation: adding a framework to any language seems to improve the overall code quality. It adds and teaches structure, patterns and good practices that developers usually follow.

I've seen terrible codebases written in vanilla PHP, JavaScript, Python (probably the worst ones). But I've seen very good looking, easy to understand, easy to maintain codebases written in Symfony, React and Django.

(React is an interesting case because it's not actually a framework but a view library, which doesn't force you to follow any structure to your project. But its declarative, component-based paradigm seem to help developers structuring their projects and writing simple, reusable and composable components in a good way).

Re: On the Impact of Programming Languages on Code Quality

#33

Casual observation: adding a framework to any language seems to improve the overall code quality. It adds and teaches structure, patterns and good practices that developers usually follow. I've seen terrible codebases written in vanilla PHP, JavaScript, Python (probably the worst ones). But I've seen very good looking, easy to understand, easy to maintain codebases written in Symfony, React and Django. (React is an i…

I agree. Our framework, libraries, and/or interfaces can and should make a bigger difference than programming language.

If you have to use the "weird parts" of a language to get typical work done, you are doing something wrong. And if you are not using the weird parts, then programming languages look and do pretty much the same thing.

Braggings such as, "look! My language can do double recursive lambda backflips while blindfolded and chewing gum!" are mostly just 1950's car racing done in cubicles. We buy cars to get to work and shops as cheaply and conveniently as possible, not beat Fonzy.

Re: On the Impact of Programming Languages on Code Quality

#34
Unfortunately, it's the original paper that will keep getting quoted at me forever.

My favorite line from this paper is: "Correlation is not causality, but it is tempting to confuse them." I think most people believe "correlation is not causality, but most of the time it is", when in reality it is, "correlation is not causality, and almost never is." There was a great analysis of this in a book or paper I read years ago that I haven't been able to find, but the tldr is that if you have a set of events, if causality were truly common, the events would for a seized up network of causality.

Re: On the Impact of Programming Languages on Code Quality

#35
I’ve read a lot of code as a consultant. The best codebase I’ve read had almost no comments and was written in erlang. Besides that every codebase I’ve read in Golang were super clear and of excellent quality for the exception of one that was written by java developers.

I can say I hated reading C because of maccros and different build systems. I hated C++ codebases because people abused generics. And I hated Java the most because of the verbosity and the directory structure and all the layers of abstractions and all the factories and all the singletons and all the...

Re: On the Impact of Programming Languages on Code Quality

#36
post #35

I’ve read a lot of code as a consultant. The best codebase I’ve read had almost no comments and was written in erlang. Besides that every codebase I’ve read in Golang were super clear and of excellent quality for the exception of one that was written by java developers. I can say I hated reading C because of maccros and different build systems. I hated C++ codebases because people abused generics. And I hated Java th…

That is always a risk if a team decides to pick up a new language but does not make the effort to learn the language properly. At work we are going through a similar Java - Go transition, so I know :(

Re: On the Impact of Programming Languages on Code Quality

#37
post #6

(Edited-- I was reading the original paper, which showed good results for TypeScript; the new paper linked above refutes that result. My mistake. Thanks to the posters who corrected me!) The winners in this paper are Clojure, Haskell, Scala. I look forward to seeing Rust added. The authors go into substantial detail about what they consider errors, and in my personal experience Rust solves many of them. See e.g. "Som…

Scala will really start to shine only after Scala Native[1][2] is ready.

[1] http://www.scala-native.org

[2] https://github.com/scala-native/scala-native

Re: On the Impact of Programming Languages on Code Quality

#38
post #35

I’ve read a lot of code as a consultant. The best codebase I’ve read had almost no comments and was written in erlang. Besides that every codebase I’ve read in Golang were super clear and of excellent quality for the exception of one that was written by java developers. I can say I hated reading C because of maccros and different build systems. I hated C++ codebases because people abused generics. And I hated Java th…

That is always a risk if a team decides to pick up a new language but does not make the effort to learn the language properly. At work we are going through a similar Java - Go transition, so I know :(

It's always a problem when people shoe-horn a non-idiomatic approach from one language into another.

It makes me wish the language creators wrote a single none-trivial 'this is how we intended it to look' project.

When learning a new language I find as many big projects written in it as I can and spend time exploring them.

It helps but there is often no guarantee those projects are doing it idiomatically either.

Re: On the Impact of Programming Languages on Code Quality

#39
The problem is that "code quality" isn't just bugs per line of code. Maintainability, extensibility, readability, expressivity all factor into it.

Suppose I have to write 100,000 lines in language B to write something doable in 10,000 lines of A. Who cares if the defect rate is twice as high per line of A: I still have five times fewer defects due to ten times fewer LOC's.

Another thing to consider is the nature of defects. A defect that allows a remote execution exploit is not the same as an incorrect result being ignored and propagating to later calculations, is not the same as terminating with a diagnostic.

Re: On the Impact of Programming Languages on Code Quality

#40

Of note is that these are all associations. It's possible the associations are all due to selection effects (or even that the "better" language are actually worse but their effects are reversed by selecting for programmers who are better). In the early days of Python, some employers used it as a way to filter for candidates who were ahead of the curve. I believe Paul Graham mentioned Lisp being good for attracting be…

In an infamous rant, Linus Torvalds also hints at using a language as a filter for programmers[1]: >Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C [1] http://harmful.cat-v.org/software/c++/linus

Considering the astonishing density of defects in Linux we can treat its author’s advice on software development as anti-advice.
Post reply on HN