[fluffything]

The OPs claim that it has been shown that bugs are a function of LoCs is unsubstantiated at best.

The number of bugs in a program correlates with the number of LoCs, but that's about it (correlation does not imply causation).

The claim is also quite absurd, since, for example, you can pre-process any C or C++ program ever written into a single line of code, yet this operation doesn't reduce the number of bugs in these programs, therefore the amount of bugs is not "just" a function of the amount of LoC.

Languages with better abstraction capabilities than Go (e.g. Rust or Python), might require programmers to type less, but the resulting lines of code are often dense. For example, I'm quite comfortable with Rust iterators and Python lists comprehensions, but it still takes me much longer to parse what code using these abstraction does, than code that just uses a simple for loop. It definitely feels great to cram a 10 LoC loop into a 1 LoC list comprehension in python, but reading that code 6 months later never felt that great, even for code that I've written myself. I just need to stop at those lines for much longer.

[pcwalton]

Really? For loops are a nightmare. Here's one from SPEC 2006:

    for (dd=d[k=0]; k<16; dd=d[++k])
    {
        satd += (dd < 0 ? -dd : dd);
    }

The problem with for loops is that they are too flexible, and so there's more opportunity for misuse. Iterator functions are less flexible, and therefore easier to read.

And this excessive flexibility doesn't even make simple things simple. Try counting down from N to 0 inclusive using unsigned ints.

[fluffything]

Can you solve the exact same problem using Python list comprehensions or Rust iterators?

I'd like to see how solving this same problem in those languages is less of a nightmare.

I personally find that C loop quite readable compared with the same iteration being done in Rust.

[pcwalton]

This is a sum of absolute differences, so in Rust:

    let satd = d.iter().cloned().map(abs).sum();

As an added bonus, there's no undefined behavior!

[tfha]

Loops in go are much less flexible than loops in C, you'd never see code like that in go.

[pcwalton]

In Go that loop could be:

    for k, dd = 0, d[0]; k < 16; k, dd = k + 1, d[k + 1] {
        ...
    }

I don't find that significantly more readable than the C version.

[bfrog]

Yeah a quick glance and I have no clue whats going on, tl;dr in review for sure

[coldtea]

>The number of bugs in a program correlates with the number of LoCs, but that's about it (correlation does not imply causation).

No, but it suggests it, and in this case, there's not many other options that could explain this than causation.

>The claim is also quite absurd, since, for example, you can pre-process any C or C++ program ever written into a single line of code, yet this operation doesn't reduce the number of bugs in these programs, therefore the amount of bugs is not "just" a function of the amount of LoC

That's an irrelevant strawman. When people speak of LoC they mean as to how many LoC are needed for various tasks based on the expressiveness of the language. Not whatever old LoC based on arbitrary adding needless lines (e.g. by preprocessing to inline function calls)...

[littlestymaar]

> The OPs claim that it has been shown that bugs are a function of LoCs is unsubstantiated at best.

But when looking at OP:

> bugs in software has been shown to be a function of LoCs [1,2,3].

He provided three different sources! Maybe it's wrong, or maybe you don't believe it, maybe it doesn't fit with your beliefs, but you can't say the OP claim is unsubstantiated when he provided academic sources on the subject!