There's a ton of problems with empirical studies about software in general. Very hard to conduct reliable experiments. In particular, I think analyzing public GitHub projects is pretty much the worst corpus possible.

For example, almost all of the projects in this study are infrastructure projects (I'm not familiar with all of them so I can't say that it's definitely all). I'm much more interested in application projects, and even if you (general you) aren't, you have to admit that an infrastructure project has a totally different set of characteristics than your average business application.

I think anything we can do to get more empirical data related to software the better, as we have devolved into strong personalities and conviction making pretty much all of the major decisions in our industry, which is really deeply sad. But we have to do better than just mining open source Github projects.

Yeah, I wasn't necessarily trying to get into an argument with the person who responded, but there's so many factors not being accounted for in that study that it might as well be measuring nothing at all.

Choosing Github projects and measuring defects on them has almost nothing to do with the quality of closed-source code (as we were discussing, functional programming languages in the wild). I also briefly started down the path of mapping that study's measurements to overall language popularity (as I think they're related - more C++ code available = more bugs), but gave up as I remembered that A.) Nobody's opinion changes as a result of a reasonable argument on the internet, and B.) Convincing this person nets me nothing at all.

You get higher quality code by hiring people capable of producing higher quality code. A great way to find people that are capable of producing higher quality code is by hiring for languages with extremely small talent pools - nobody got there because it was easy or the odds of getting hired were good. Functional programming might seem popular on HN, but in the wild is really not popular at all. Clojure developers probably care a great deal more about the quality of their work than, say, some random J2EE developer, as the Java dev might not care at all about anything other than staying employed.

I guess my argument summarizes down to "Functional programmers care more about their work", which, to my original point, has nothing at all to do with the languages they're using (as the person I responded to was saying). To assert that "Functional programming languages produce higher quality code" is like saying "This brand of hammer hammers better." It's just nonsense.

That's oversimplification. Good programmers care about their work, doesn't matter which language.

Also, use the right tool for the job.

A language that forces you to think about values rather than mutable objects, will produce higher quality code as the number of ways you can shoot yourself in the foot are drastically reduced.

Clojure will make you run your code constantly in the REPL. Paired with a dead-simple testing library, the desire to keep your majority of functions pure, it is not hard to see why Clojure code has higher quality.

> Good programmers care about their work, doesn't matter which language.

Yes, but the whole purpose of my post is to point out the difficulty in _finding_ the good programmers.

> Also, use the right tool for the job.

Not sure how this applies. You can build banking software in literally any programming language.

> A language that forces you to think about values rather than mutable objects, will produce higher quality code as the number of ways you can shoot yourself in the foot are drastically reduced.

Again, this is just totally unsubstantiated. You're using "higher quality code" to mean "code I like more".

> Clojure will make you run your code constantly in the REPL. Paired with a dead-simple testing library, the desire to keep your majority of functions pure, it is not hard to see why Clojure code has higher quality.

Where have we demonstrated that clojure has implicit higher quality? Also, where have we demonstrated that all clojure devs keep their functions pure? Or test them? And how does clojure enforce that?

Your last bit kinda proves my whole point, I think. You like a language a lot, and you make good use of its tools. But again, when you're looking at large groups of programmers, they're going to drastically lower the bar on what you "should" do - talking about "strong desire" and "dead simple" is totally unrelated to whether people will _actually do_ something in the wild. And what's the best way to keep a codebase good? Well first, tooling, but second, not letting bad devs get ahold of it.