5 ms·

>the only proven risk factor for bugs is number of lines of code. I'm sure you can cite that, but it feels wrong in this context. That is, given the same lang

>the only proven risk factor for bugs is number of lines of code. I'm sure you can cite that, but it feels wrong in this context. That is, given the same language, or equally verbose languages, it may be true and applicable. But, if comparing a more verbose language to one that is less so, then the former will naturally yield a higher LOC count. But, does this mean it's more bug prone? There aren't any more logical constructs, flow control mechanisms, etc. The language simply requires more lines to express the same intentionality. In fact, I wonder how a more verbose language would compare with a less verbose one if we normalized for some verbosity factor. So, let's say language A is twice as verbose as language B, such that when the LOC count of A is twice that of B, we consider them equal (call it the same "Effective LOC"). I actually wonder if, in this case, language B would have a higher bug count per effective LOC, owed to its terseness and/or reduced readability.

unclebucknasty 12y ago
Downvotes (especially without comments) as an expression of disagreement are just plain silly. Are we eight-year olds?
- fsloth 12y ago
  This behaviour - downvoting without explanation irritates me too when there is very lucid and concisely structured argument you can oppose. As such, I do not find your argument for 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. For numerical algorithms, where a multiplication is just as verbose in any language then there is no difference. But when manipulating collections, for example in C I need to write int i; for(i = 0; i < someSize; i++){...} This has several places where the verbosity of language can make it easier to write bugs that slow down the progress a bit. If we add these tiny slowdowns throughout the lifecycle of the entire application the cost is not neglible if compared to a situation where these bugs would not appear at all. Some other language: for i in collection do:... Which does really have no place to shoot oneself in the foot unless the iteration logic itself does something funny.
  - pgsandstrom 12y ago
    What you argue is not that LOC in itself causes bugs, but that certain programming syntaxes are both complex (thus induces bugs) and takes up more LOC.
    - fsloth 12y ago
      Oh, that I did. Very true.
  - unclebucknasty 12y ago
    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

Downvotes (especially without comments) as an expression of disagreement are just plain silly. Are we eight-year olds?

fsloth 12y ago
This behaviour - downvoting without explanation irritates me too when there is very lucid and concisely structured argument you can oppose. As such, I do not find your argument for 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. For numerical algorithms, where a multiplication is just as verbose in any language then there is no difference. But when manipulating collections, for example in C I need to write int i; for(i = 0; i < someSize; i++){...} This has several places where the verbosity of language can make it easier to write bugs that slow down the progress a bit. If we add these tiny slowdowns throughout the lifecycle of the entire application the cost is not neglible if compared to a situation where these bugs would not appear at all. Some other language: for i in collection do:... Which does really have no place to shoot oneself in the foot unless the iteration logic itself does something funny.
- pgsandstrom 12y ago
  What you argue is not that LOC in itself causes bugs, but that certain programming syntaxes are both complex (thus induces bugs) and takes up more LOC.
  - fsloth 12y ago
    Oh, that I did. Very true.
- unclebucknasty 12y ago
  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 :)