Sure, you can trade off static typing for terseness. This isn't a Java vs Clojure issue. You can make code even terser by abandoning documentation. Even more terse by abandoning tests!
I don't have time to fully dive into the second example, but at first glance it looks like poorly written Java. You can write Java in a functional style! It can look a lot like Kotlin or Scala or even Clojure, and I generally prefer it to.
Badly written code looks terrible in every language.
But if bug count is proportional to LOC and LOC per day are constant across all languages, then bug per day will also be constant across all languages.
You can write shit code in any language. I used to think Java made it harder to write shit code, but the project I'm on right now has made be reconsider this opinion.
IME, the bugs are also easier to deal with in the more expressive language. They tend to be things like faults in the business logic or gross edge cases that people are likely to catch in code review or QA. Whereas the bugs in languages like Java seem to typically be really annoying things like off-by-one errors, comparing Integers with ==, and goofy run-time type errors that sail past the compiler because of weak static type checking when generics are at play, and also past code review because people aren't expecting to have to review for type errors when they're using a static language.
Yes, I'm inclined to agree, but I actually haven't ever seen a study which compares the same project implemented in different languages to establish in toto the variance in SLOC. It could be the case that in the main for the same project the differences between languages wash out, as different languages may have different advantages and disadvantages that are more likely to tell on a substantive project.
What you suggest seems reasonable, but I simply don't know it to actually be the case.
Of course -- but the important thing is that bug count per feature/app will be lower in a more expressive language.
Umm...so for the same amount of bugs I can have more features if I choose the more expressive one...
I don't know about that, a lot of people seem to like j[1]
"Code Review Metrics". [0]
"A Large-Scale Study of Programming Languages and Code Quality in Github". [1]
"Software Quality Metrics". [2]
"Study on the Correlations Between Program Metrics and Defect Rate by a Controlled Experiment". [3]
0 - https://www.owasp.org/index.php/Code_Review_Metrics
1 - https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-...
2 - https://www.developer.com/tech/article.php/10923_3644656_2/S...
Is there some particular aspect of the Clojure code here that you think is overly clever, or hard to understand? This Clojure code uses only one lambda, and in a straightforward way.
I've written a lot of Java, and a moderate amount of Clojure, and if I had to place a wager on which version had fewer bugs, I'd definitely bet on the Clojure. Especially if there were the possibility that it was related to threads.
We could write this in assembly language, and it'd take 50,000 lines, and probably have lots of bugs. The salient point is not (just) the lower line count, but that when code is shorter, that's a good indicator that it's written at a level of abstraction that fits the problem.