If you are not working for a startup, majority of the time, you will be maintaining legacy code or bug fixing. I would take easily understandable verbose code over "clever" concise code every time.
Clojure code is far easier to maintain for a number of reasons. The code is declarative, so it separates what's being done from the implementation details. The first step of code maintenance is to understand the intent, and it's much easier to do that with declarative code. Immutability means that the code is largely referentially transparent, so the cognitive load of understanding a particular piece of code remains constant as the project size grows. This is not the case for imperative languages where you pass references to shared mutable state all over the place. The syntax is much smaller and more consistent, meaning that you have to learn less rules and quirks to understand the code. There are less chances of code being misinterpreted. Finally, you have the REPL, so you're able to run any code you're not clear about right from the editor in the context of your application.
My team moved from Java to Clojure about 8 years ago, and we find that it's much easier to maintain Clojure projects than it was for similar scope Java projects. We deliver faster, we have far less defects, and we're able to make changes much more reliably than we ever could with Java.
Could it just be that you are all better developers than you were 8 years ago, and the language doesn't really make a difference?
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.
"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...
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.
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...
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.
I don't know about that, a lot of people seem to like j[1]
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.
And in the general case verbosity and cleverness are orthogonal properties.
You would think so, sure. I used to write Perl code and I was extremely familiar with it and it used to be pretty easy for me to hack a script. Going back after couple of months and trying to understand it though, was a totally different animal.
You can argue that it was my fault for writing bad Perl code, but ask any old farts who ever had to write Perl.