seventh-chord

Not quite sure what point the author is trying to make? He agrees that lines of code are a bad measure of productivity because, yet claims that the average he computes can help him predict future development times. Then he explicitly points out that different parts of the codebase required different amounts of work, apparently unrelated to their code line count, yet does not relate this to the previously mentioned points. Also, what is up with the random comment about code coverage at the end? That doesnt fit in with the rest of the article either...

Whenever I try to use linux on hardware, either audio doesn't work without stuttering, video doesn't work without tearing or some package manager dependency issue rears its ugly head. From my perspective, it seems inconceivable to run linux on (personal) hardware.

That being said, I am very unhappy with windows 10 at work, and would much rather have some older windows version. At some point windows probably will become shitty enough that linux might seem like a viable alternative.

There is absolutely no requirement from the hardware that the stack be any particular size

in languages like c, rust or go, where you can put arbitrary data on the stack, it seems to me as if such issues are less common because you dont have to worry about initializing pointers and allocating memory unless you actually want to put something on the heap. Thus if you make everything a reference in your language its no wonder you run into issues like null-pointers more often

"Making everything a reference: The Billion Dollar Mistake" is the talk I want to see

For norway, our central statistics agency[1] keeps track of anual traffic fatalities. They provide numbers for each year since 1946, though detailed statistics are only available since ~2000.

In 1946, there were 161 fatalities and 675 gravely injured. This grew more or less linearly to 1971, with 533 fatalities and 4069 gravely injured. Since then it has fallen, again more or less linearly, to 108 fatalities and 602 gravely injured in 2018.

Numbers for 2019 are not out yet, as statistics for december have yet to be released.

[1]: ssb.no

Regarding having tons of exit points, I find it actually adds no more cognitive load to use only a single return per function, compared to having multiple returns and keeping resource-freeing up-to-date for each.

Most of the challenge in writing code with a single return seems to come from the fact that I'm not used to doing it. Of course, sometimes it leads to heavily nested control flow, although I'm not sure yet whether or not I mind that. It does certainly simplify reasoning about control flow though, especially in large functions.

That all being said, I'd still rather just have defer.