4 ms·
I like verbosity in programming language. It becomes pretty easy to read the code, compared to lambdas or other concise languages. If you are not working for a
by phakding 8y ago
I like verbosity in programming language. It becomes pretty easy to read the code, compared to lambdas or other concise languages.
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.
- sfvisser 8y agoIn my experience ease of reading code is not a function of verbosity, but a function of familiarity. And in the general case verbosity and cleverness are orthogonal properties.
- phakding 8y ago> In my experience ease of reading code is not a function of verbosity, but a function of familiarity. 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.
- cutler 8y agoPerl is an elegant, artfully designed language based on linguistic context. If you don't grok it don't use it.
- ken 8y agoStudies have found that bug count is roughly proportional to program length, across languages. Saying you prefer verbosity essentially means you prefer more bugs. 500 lines is generally less understandable than 40 lines. There may be cases where terseness can be too extreme, but I don't see it here. 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.
- GuiA 8y agoIt would be wonderful if anyone commenting on HN with “studies have found...” would accompany their comment with links to said studies :)
- AdieuToLogic 8y agoJust did a moment ago in this thread: https://news.ycombinator.com/item?id=17946568 https://news.ycombinator.com/item?id=17946568
- dcu 8y agocan you link the studies? I'm genuinely interested
- hellofunk 8y agoThey have been linked many times here on HN over the last 2 years.
- dcu 8y agoI just found this link https://labs.ig.com/static-typing-promise https://labs.ig.com/static-typing-promise Clojure seems to be the best followed by Go, both designed to be simple
- AdieuToLogic 8y agoHere are a few which are relevant: "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 https://www.owasp.org/index.php/Code_Review_Metrics 1 - https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/fulltext https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-... 2 - https://www.developer.com/tech/article.php/10923_3644656_2/Software-Quality-Metrics.htm https://www.developer.com/tech/article.php/10923_3644656_2/S... 3 - https://scialert.net/fulltext/?doi=jse.2013.114.120 https://scialert.net/fulltext/?doi=jse.2013.114.120
- yogthos 8y agoI've worked with Java for over a decade professionally. Most of the verbosity in it is just noise, and does not provide any meaningful information. 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.
- eafkuor 8y ago> 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 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?
- yogthos 8y agoWe're obviously better developers than we were 8 years ago since we've had a lot of practice in that time. However, my team has hired many people in that time, and we also regularly hire co-op students. We see that new employees are able to write better code in Clojure as well regardless of their experience. We've also found that it's easier to train beginners to be effective with Clojure than it was with Java. The language is smaller, more consistent, and encourages good patterns out of the box.