41–50 of 77 posts
Slow enough to not offer Varnish for Buster, 2 months after Debian release... ;-)
What are you talking about that they did 'not offer Varnish for Buster?' Was there a packaging problem or more context you could add here?
Footnote 6 is interesting: “I prefer asserts over comments for this, since the compiler can also see them. The good news is, the compiler can also see that they don't do anything so a lot fewer are present in the binary program. Interestingly, a couple of them allows the compiler to optimize much harder. No, I won't tell you which those are.” I appreciate the pattern of having “comments” that are equally useful to co…
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.
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?
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/
Earlier quoted context omitted.
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…
Software-as-art has lost a lot of ground to software-as-business, and in software-as-business, somewhere up the chain there is a management-level individual who isn't really sure how to measure either progress or code quality. There are myriad tools designed for these people though, and they all chose the simplest (and wrong) solutions to the problem: progress is SLOC added and bug reports clsoed per day. The height…
Besides postcardware ("if you like the program, send me a postcard"), I have to think of Phone Me NOW!!!:
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 a…
That said, occasionally we have people who work very quickly and somehow still have great code. Thats an even better signal.
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/
There's also this from Bill Gates: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
/**
I'd agree
that counting the occurrences of 0x0a
can be
misleading
*/Earlier quoted context omitted.
Is this [1] the code he speaks of? [1] https://github.com/Co-dfns/Co-dfns/tree/master/cmp
It's an APL compiler, written in another APL dialect, which is about as dense as you can get in terms of lines-of-code. APL is one of the few really high level languages.
https://github.com/Co-dfns/Co-dfns/commit/78d0e38f8ba2e1de9f...