2 ms·

Well, I can appreciate the reply versus a downvote, but "I do not find your argument [against] verbosity normalizing convincing." :) >I fail to see how normali

Well, I can appreciate the reply versus a downvote, but "I do not find your argument [against] verbosity normalizing convincing." :) >I fail to see how normalizing some risk metric against a verbosity of language will provide any valid data in the general context. OK, then let's look at the corollary: that is, not normalizing against verbosity would mean, roughly, that you're claiming that a language that is twice as verbose would yield twice the bugs over the same app. I don't think that's the case nor what you intend to say. I think you're also confusing complexity with verbosity. An extremely terse language can be very complex, and may even suffer from readability issues. Overall, the notion of LOC alone being a risk-metric absent any additional context seems an oversimplification.

fsloth 12y ago
"Overall, the notion of LOC alone being a risk-metric absent any additional context seems an oversimplification." Yeah, I agree completely. Didn't think too long before answering there, I'm afraid. I confused the fact that in my experience increase of LOC correlates with increased risk of bugs with there actually being a causality between the said observables. For me personally languages with higher LOC are harder to read, but this is just about the languages I like and not a generalization that can be applied to any language in general (i.e. Ocaml is nicer than C in this sense but APL or J would get me just terribly confused). Basically, of the languages I consider readable, and when dealing with container operations, it's easier for me to parse especially those that either have basic containers as fundamental data types in the language (e.g. Python, F#) or have a uniform syntax over typical algorithms and containers (Clojure) rather than verbose languages like C or Java. In these instances, it's not about the overall LOC count of the languages but the fact that they make common operations more legible and easier to reason with than C. I.e. they have less non-value adding burden typically. Why they are nicer, is not because of their LOC, though, but their LOC is a side-effect of their features that make them nice, I think. Thanks for pointing this out :)
- unclebucknasty 12y ago
  >Thanks for pointing this out Well, I think you actually described it more eloquently, once we got there. :)

fsloth 12y ago

"Overall, the notion of LOC alone being a risk-metric absent any additional context seems an oversimplification." Yeah, I agree completely. Didn't think too long before answering there, I'm afraid. I confused the fact that in my experience increase of LOC correlates with increased risk of bugs with there actually being a causality between the said observables. For me personally languages with higher LOC are harder to read, but this is just about the languages I like and not a generalization that can be applied to any language in general (i.e. Ocaml is nicer than C in this sense but APL or J would get me just terribly confused). Basically, of the languages I consider readable, and when dealing with container operations, it's easier for me to parse especially those that either have basic containers as fundamental data types in the language (e.g. Python, F#) or have a uniform syntax over typical algorithms and containers (Clojure) rather than verbose languages like C or Java. In these instances, it's not about the overall LOC count of the languages but the fact that they make common operations more legible and easier to reason with than C. I.e. they have less non-value adding burden typically. Why they are nicer, is not because of their LOC, though, but their LOC is a side-effect of their features that make them nice, I think. Thanks for pointing this out :)

unclebucknasty 12y ago
>Thanks for pointing this out Well, I think you actually described it more eloquently, once we got there. :)