The time lost estimates here are comically implausible--if Apple bugs were wasting 32m person-years per year, with around 1.5b Apple product users total, this would imply that the average Apple product user loses 32m/1.5b ~= 2% of their life, or about 11 16-hour days, to Apple bugs. If that were happening to you you'd, uh, notice :)
I'm not an evolutionary biologist, but it seems to me that the claimed magnitude of the change is wildly implausibly fast from an evolutionary perspective. I'm confused that neither the article, nor the paper it cites, addresses this.
To go from 10% to 30% in ~5 generations, the median-artery-having population would have had to expand by (30/10)^(1/5) = 25% more than the non-median artery population over each generation. It just seems totally implausible that median artery carriers could have that much more offspring.
This makes me pretty suspicious that the paper may be wrong.
It's also really easy to have high quality audio! The author recommends a "podcasting" microphone, but a $35 standalone headset mic[1] is almost as good and much easier to use. If you want to hear a comparison, I got kind of obsessed with this problem at one point and took some comparison recordings here[2].
(You need a standalone mic since most headsets, even really nice ones, have really bad mics because most headset buyers don't care about or even know how good their mic sounds. The one I linked is wired because wireless is evil[3] and in particular, Bluetooth will silently degrade your audio quality. If you want a pair of wired headphones, I like these[4] which are "open back" and therefore sound more natural + cool your ears better, although the open back also means they "leak" sound and are only suitable for working without people next to you. But you shouldn't be having calls with people next to you anyway!)
Shot in the dark, but many of my Linux coworkers have a problem where their video chat software sets their mic volume/gain to 100%, which causes horrible sounding clipping. Check your mic gain settings and perhaps disable the automatic volume equalization in whatever video call software you're using.
For more concrete data: If you look at their current "key ideas" page,[1] they go over 4 categories of high-impact careers (notably including government/policy) and then say "if you think none of the categories above are a great fit for you, we’d encourage you to consider earning to give. It’s also worth considering this option if you have an unusually good fit for a very high-earning career."
This post[2] suggests 80k's key researchers think about 15% of people interested in EA would be the best fit for earning to give, while 10% of people attending an EA-themed conference were perfectly planning to.
I don't think criticizing effective altruism based on the assertion that it's mostly about earning-to-give is reasonable given those numbers or the framing in 80k's "key ideas" post.
This article completely mischaracterizes the beliefs of most of the people quoted or referenced, then engages with those beliefs only via asserting the opposite without any supporting argument. I'm disappointed.
For example:
> The most charitable explanation of Singer’s dismissal of political action is that he is trying to sell being an altruist and he thinks a consumer -hero version is the one people are most likely to buy. Singer and other effective altruist philosophers believe that their most likely customers find institutional reform too complicated and political action too impersonal and hit and miss to be attractive.
Interestingly, the author quotes part of Singer providing an argument against the effectiveness of institutional reform, but does not himself provide an argument for it, just an assertion that political change is "the most obvious and powerful tool we have." (I think that's far from obvious!) Instead, he jumps straight to accusing Singer of arguing in bad faith. This is actually the opposite of charitable.
For another example, I'm deeply confused about how the author of this piece could cite Will MacAskill and Toby Ord, then write:
> The underlying problem is that effective altruism's distinctive combination of political pessimism and consumer-hero hubris forecloses the consideration of promising possibilities for achieving far more good.
Ord and MacAskill co-founded an organization, 80,000 Hours[1], which advocates mostly not for effective giving (which the author derides as a "consumer hero" approach) but rather for spending your career working on one of the world's most pressing problems; notably including for instance several types of policy change.
EDIT: and I missed this one the first time around:
> One could spend at most a few tens of millions of dollars on anti-mosquito bed nets before returns start dramatically diminishing because everyone who can be helped by them already has one.
I think you took me to be arguing for a stronger claim than I actually was. My preferred paradigm is also roughly “idiomatic go or rust.” But the OP isn’t arguing for idiomatic-go-or-rust, as far as I can tell they’re arguing against ever using methods or virtual dispatch (which are core features of both of those languages)! My claim is that the OP’s diagnosis of the problem—“virtual dispatch causes your code to be confusing, get rid of it”—is incorrect.
The author’s OO example is hard to understand, but they’re wrong about why. It’s not bad because it’s OO, but that it’s very badly done OO: the class couples two different concerns (network API client and database). That’s why it makes more sense as a bag of functions.
The general version of the point doesn’t work very well, and many of the other OO use-cases the author discusses actually work much better than alternatives.
For example, on abstract base classes: if you replace this with a bag of functions I think you end up reinventing virtual dispatch—that is, each function’s top level is a bunch of `if isinstance(...)` branches. This is much harder to read, and harder to add new implementations to, than abstract methods. It’s also no easier to understand.
(There is a subset of this advice that I think does improve your code’s understandability, which is “only ever override abstract methods,” but that is very different from “don’t use OO.”)
For impure classes, the author suggests e.g. using `responses` (an HTTP-level mocking library) instead of encapsulating these behind an interface. This is a fine pattern for simple stuff, but it is not more understandable than a fake interface. The hand-written fake HTTP responses you end up having to write are a lot less readable than a mock implementation of a purpose-built Python interface. (Source: I once mocked a lot of XML-RPC APIs with `responses` before I knew better; it was not understandable.)
Sorry, that was imprecise. My impression is that, at least on some prediction markets, transaction fees (and maybe also inflation?) make it low-return to buy high-probability contracts. I don't bet on prediction markets myself so I may be wrong about this though!
1. There's a statistical gadget specifically for doing this—a "scoring rule" [1] which is a principled way to compare different probabilistic predictions. A bunch of scatterplots of random quantities against each other are... not that.
By comparing only binary win/loss predictions instead of probabilities, like in the first chart, you throw away almost all information contained in the probabilistic estimates—if Democrats win a state, there's no bonus for predicting (say) 95% Dem instead of 55% dem.
It's plausible that 538 would actually win under a proper scoring rule, because betting markets were underconfident (relative to 538) in deep dem/rep states (predicting e.g. <95% Dem win in VT, vs 538's >99%). [2]
2. The calibration analysis assumes that different state win/loss rates are independent, but that's really untrue: 538's predictions were specifically not independent because they assumed polling errors were correlated between states.
3. Many of the other scatterplots look outlier-driven and don't include r^2 or p-values. With so few datapoints, it's unclear if they are meaningful at all.
[2]: Maybe we should cut prediction markets some slack here because liquidity constraints make them inaccurate for small probabilities. If that's the article's position, though, they should address this instead of just... not using a scoring rule.