Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Going Fast Slowly

varnish-cache.org

Post reply on HN
Print view View original

11–20 of 77 posts

Re: Going Fast Slowly

#11

Post by bovermyer »

lucideer wrote: post #9
pdonis wrote: post #2

From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. http://plasmasturm.org/log/linesspent/

Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…

Because technical beauty is not the only metric measured by businesses.

Re: Going Fast Slowly

#12

Post by zokier »

About the numbers, I feel like going through the commit diffs and counting all the + lines would be better (in some sense) metric than counting the final lines of code if we'd want some proxy for the amount of labor.

Re: Going Fast Slowly

#13

Post by frankosaurus »

lucideer wrote: post #9
pdonis wrote: post #2

From the article: "I no longer think about code lines as an asset to be accumulated, but rather as an expenditure to be avoided." The obvious Edsger Djikstra reference: [I]f we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger. http://plasmasturm.org/log/linesspent/

Chiming in to say I agree with the sibling (dead) comment (not sure why it ended up dead). Djikstra's words (and the article's) are clearly correct, but hardly revolutionary or contrary to modern belief today. The real question is: why, despite a prevailing belief in modern software software engineering that red diffs are beautiful and cathartic things to be celebrated, and that the great spectre of technical debt is…

survivorship bias?

Re: Going Fast Slowly

#14

Post by FreeFull »

drewm1980 wrote: post #8
FreeFull wrote: post #5

Earlier quoted context omitted.

In Rust, an assert can turn multiple bounds checks on array indexing into just a single bounds check. Maybe it's something along those lines here too.

Interesting! Do have a link to an example?

Given the following code (and with optimisations on):

    pub fn no_assert(input: &mut [u8]) {
        for i in 0..10 {
            input[i] += input[i+1];
        }
    }

    pub fn with_assert(input: &mut [u8]) {
        assert!(input.len() >= 11);
        for i in 0..10 {
            input[i] += input[i+1];
        }
    }
The no_assert function ends up doing a bounds check for every iteration, and the with_assert function only does a single check.

Re: Going Fast Slowly

#15

Post by nemo1618 »

zokier wrote: post #12

About the numbers, I feel like going through the commit diffs and counting all the + lines would be better (in some sense) metric than counting the final lines of code if we'd want some proxy for the amount of labor.

Indeed. Reminds me of arcfide's Co-dfns compiler:

>I think the first copyright on this compiler is around 2011. That's 6 years for 750 LoC. That's about 125 lines of code per year.

>But that doesn't tell the whole story. If you look at the GitHub contributions that I've made, I've made 2967 of about 3000 commits to the compiler source over that time frame. In that time I've added roughly 4,062,847 lines of code to the code base, and deleted roughly 3,753,677 line of code. And there's the real story...It means that for every one of those 750 lines, I've had to examine, rework, and reject around 5400 lines of code.

https://www.sacrideo.us/smaller-code-better-code/

Re: Going Fast Slowly

#16

Post by tudelo »

FreeFull wrote: post #14
drewm1980 wrote: post #8

Earlier quoted context omitted.

Interesting! Do have a link to an example?

Given the following code (and with optimisations on): pub fn no_assert(input: &mut [u8]) { for i in 0..10 { input[i] += input[i+1]; } } pub fn with_assert(input: &mut [u8]) { assert!(input.len() >= 11); for i in 0..10 { input[i] += input[i+1]; } } The no_assert function ends up doing a bounds check for every iteration, and the with_assert function only does a single check.

Still that assert has to be checked at some point right? I would assume that maybe the compiler could do this optimization without having to be told.

Re: Going Fast Slowly

#17

Post by FreeFull »

tudelo wrote: post #16
FreeFull wrote: post #14

Earlier quoted context omitted.

Given the following code (and with optimisations on): pub fn no_assert(input: &mut [u8]) { for i in 0..10 { input[i] += input[i+1]; } } pub fn with_assert(input: &mut [u8]) { assert!(input.len() >= 11); for i in 0..10 { input[i] += input[i+1]; } } The no_assert function ends up doing a bounds check for every iteration, and the with_assert function only does a single check.

Still that assert has to be checked at some point right? I would assume that maybe the compiler could do this optimization without having to be told.

In practice a small function like this would be inlined, which gives room for further optimisations. At any point, if the compiler knows that all accesses are in bounds, it can remove the bounds checks. The trick is actually having it figure that out.

Re: Going Fast Slowly

#18

Post by kardos »

nemo1618 wrote: post #15
zokier wrote: post #12

About the numbers, I feel like going through the commit diffs and counting all the + lines would be better (in some sense) metric than counting the final lines of code if we'd want some proxy for the amount of labor.

Indeed. Reminds me of arcfide's Co-dfns compiler: >I think the first copyright on this compiler is around 2011. That's 6 years for 750 LoC. That's about 125 lines of code per year. >But that doesn't tell the whole story. If you look at the GitHub contributions that I've made, I've made 2967 of about 3000 commits to the compiler source over that time frame. In that time I've added roughly 4,062,847 lines of code to th…

Is this [1] the code he speaks of?

[1] https://github.com/Co-dfns/Co-dfns/tree/master/cmp

Re: Going Fast Slowly

#19

Post by kzrdude »

tudelo wrote: post #16
FreeFull wrote: post #14

Earlier quoted context omitted.

Given the following code (and with optimisations on): pub fn no_assert(input: &mut [u8]) { for i in 0..10 { input[i] += input[i+1]; } } pub fn with_assert(input: &mut [u8]) { assert!(input.len() >= 11); for i in 0..10 { input[i] += input[i+1]; } } The no_assert function ends up doing a bounds check for every iteration, and the with_assert function only does a single check.

Still that assert has to be checked at some point right? I would assume that maybe the compiler could do this optimization without having to be told.

I believe the compiler can't do that, since the bounds check panic is a side effect that can be observed - the message tells which index that failed the check! For that reason, non-elided checks will not be reordered.

However, I believe a future Rust RFC could turn that around and validate the idea that in some cases such things could change execution order, even if it has noticeable side effects.

(No idea if it's technically feasible!)

Re: Going Fast Slowly

#20

Post by bt848 »

10 LOC/h is spectacularly good over a long time period. Congratulations, from a varnish user.

I recently tried to set expectations in a coding interview that was scheduled for 3 hours. I told them that was enough time to read the spec, develop a simple test case, and begin or possibly complete an implementation of part of the spec. I also told them that I wasn't interested in a shop that hired people based on their ability to dash off broken, untested code in half a day. It seems to me that this kind of coding test (especially for someone with 25 years of open-source contributions) can only lead to bad things. I'd be glad to meet people like the author who have a practical view on Brooks and LOC/h.

Post reply on HN