actuallyalys

It's very situational. If you're talking about writing a static site generator or handcoding a web page, that's mostly true, although if you're trying to not just be efficient, but as efficient as possible, things like optimizing assets are a small but additional step.

If you're maintaining a web app over a period of years, it takes at least some effort and time to keep it slim and efficient because small inefficiencies here and there start to accumulate and these tend to be more demanding even in the best case.

There are some antifeatures that Dan Luu identifies, like dynamically unloading content, that probably take a considerable amount of time to implement while degrading both the user experience and efficiency, but I doubt avoiding those is enough to ensure good performance on more complicated projects.

The U.S. government already funds a lot of research including some on conditions (or non-medical problems) that don’t affect the majority so that doesn’t seem to be an actual barrier. Polls tend to show Americans support existing funding [0].

Obviously there is a limit to how much spending the public will support, but I don’t think it’s a complete nonstarter.

[0]: https://www.pewresearch.org/short-reads/2018/07/03/americans...

While of course COVID is real, the disappearance of this strain has more to do with the response to COVID than the disease itself. If you already believe that people isolated for a fake or minor illness, this wouldn’t convince you otherwise, unless I’m missing something.

I don’t think it would have been unusable. The first distributed version control systems are more than 20 years old. Plus, the size of hard drives was in the 10s of GBs [0] then and a lot of large projects have repositories that are a few GBs or less. [1]

So I think keeping the entire version history on a local hard drive was doable 20 years ago, but I think you’re ultimately right that keeping history locally would have been a less appealing solution.

[0]: https://www.tomshardware.com/reviews/15-years-of-hard-drive-...

[1]: This is just based on what I happen to have checked out locally, but it includes Rust and CPython.

It's unfortunate that the author used the word "testing" because I think the underlying point is correct: By the time you've compiled Rust, there's been a significant number of automated checks against your code, which less true of a language like Python.

It's also unfortunate the author describes features of static typing as "unit tests" when there's already confusion over the term. I think it works as an analogy, but I think this is a place where not being clear it's an analogy invites confusion.

Debugging skills transfer somewhat to solving problems in other domains. However, the reverse is also true and also you often need substantial expertise to actually apply your debugging skills.

Honestly I could imagine a mechanic writing the opposite sentiment, saying they don’t respect software developers because they called a support line and the only advice was to restart the computer and then to reinstall it from scratch.

Yeah, economists sometimes call it "prime age."

I'm not sure what you mean by "represented"? Someone who doesn't have a job in order to be a caretaker or keep up a household would count as not employed, even though those people are still doing work. (The same would apply for people without jobs and spend their time in school or volunteering.)

They do ask why people aren't working in government surveys, so that information is available to analyze. I wasn't able to quickly find an overall recent figure, but there is a figure for people who are technically in the labor force but haven't looked for work in the last month: https://www.bls.gov/web/empsit/cpseea38.htm. And I also found an older figure: https://www.bls.gov/opub/btn/volume-4/people-who-are-not-in-....

I think this perspective is simplistic, but the U.S. government does produce basically this number (although I think they exclude children): https://fred.stlouisfed.org/series/EMRATIO. Currently it's 60.2 percent, a value higher than immediately after the major COVID layoffs or the 2008 financial crisis but lower than peaks in the 80s, 90s, or 00s. Most of this drop is because of the U.S.'s aging population. Looking at the same ratio from people between 25 and 54 shows it's 80.6 percent, about as high as ever: https://fred.stlouisfed.org/series/LNS12300060.

Even if you don't want to treat increased expected loss of life as the same as time saved, it does seem like this could be a good way of (ahem) driving home how much you're risking by driving faster.

Many of the results had error bars overlapping zero or were fairly close (see figure 1). For results like this, it's not too surprising that other researchers would detect a faint positive or a faint negative instead. That doesn't really undermine the usefulness research, though. After all, it's not that uncommon for studies to end up with small effects. When reading a paper with that magnitude of result, it's good to remember that different researcher decisions could nudge that range into statistical insignificance.

I also noticed most teams produced multiple models, so it seems like part of the variation could be down to that. For example, most teams produced at least one model per survey question. It could be that basically all models based on question one showed a negative AME and all models based on question six produce a positive AME, resulting in the models disagreeing but the teams basically agreeing. Presumably their analysis to identify particular decisions explaining the variance between models would have picked that out if it were down to something that simple.

It seems like that would only work for platforms where music, TV, and movies are central to why people buy it, like smart TVs or smart speakers. That doesn't seem true for a VR headset.

I wonder if there’s some way to mitigate this by either only keeping the uniqueness database long enough to identify duplicates and then deleting it or by using this on lower priority systems that people may reuse passwords from for your higher security one. In either case, the small number of bad passwords you would identify that you couldn’t come up with yourself or find on common password lists probably makes this a bad tradeoff.

The safe way to do this is to check a password against a list of common passwords, as Jeff Atwood suggests [0] rather than against your other passwords. As other replies point out, you shouldn’t be able to compare your passwords’ plaintext to each other like you’re proposing[1].

[0]: https://blog.codinghorror.com/the-god-login/

[1]: I suppose you could salt and hash the user’s password against every other user’s password and their salt, but if you chose an appropriate password hash function and parameters, that would take infeasibly long.

Edit: I missed that you essentially suggested this already. Sorry about that. However, I think the way Atwood explains it is useful.

The post you’re responding to said that there are many Python packaging options, not that they don’t work. Pip freeze works reasonably well for a lot of situations but that doesn’t necessarily mean it’s the best option for their notebook tool, especially if they want to attract users who are used to conda.

The high end estimate would be for 25 million households and would mostly go to customer service [0]. It may well be too high, but "absolutely absurd" doesn't seem fair.

[0]: https://www.irs.gov/pub/irs-pdf/p5788.pdf#page=18

There's certainly room to debate how the IRS is spending its money, but they've spent some of it on responding to taxpayer questions, resulting in a decrease in wait times and other improvements: https://home.treasury.gov/news/press-releases/jy1421. These are their own metrics, so it's possible they're being gamed in some way, but it's not true no money is going toward helping taxpayers.

They did just get a big boost, but this was after years of stagnant funding, as the link in the comment you replied to shows.

Comparing government agencies' efficiency to private entities' is tricky since they tend to have different goals and constraints, but I'm not sure 87,000 agents is that many considering the number of households and business that have to pay taxes, and the number of non-profits that don't pay taxes but still file financial information.

It’s a reimplementation of Microsoft‘s popular XNA framework that was used for a number of successful games. Monogame itself has been around for a while and my impression is that it’s a mature and stable project. I would put it in between libraries like SDL that are often used as infrastructure and full engines like Unity.

Konto goes a long way in my experience: https://kinto.sh/

Untreated mental illness and substance abuse problems could cause someone to be not of sound mind to the extent they irrationally refuse help, but they’re not synonymous with it.

To me the implausible claim is not that some homeless people are not of sound mind to the extent they refuse any and all help, but that there’s a significant number of them. It’s especially implausible given that homelessness varies so much by area and is linked to housing costs.

13 years past how long a contributor to the obituary lived. The contributor may have started work on the obituary even earlier and probably did, as Kissinger was 87 and it probably would have made sense to pre-write the obituary sooner.

Programming is probably an extreme case, since some people begin it as a hobby in middle school or high school and others go into introductory CS classes having done no programming at all, but it's not hard to imagine similar factors happening in other subjects. For example, I did well in high school English courses, which I and my peers obviously had years of classes in already—but I also did extra curricular reading and writing, mostly because it was something I enjoyed.

Now, would I say natural aptitude is negligible or non-existent, as the headline does? No, I don't think a single study is that definitive (and it did find a difference, just a small one).

As far as I can tell from reading the discussion section of the original paper, they unfortunately didn't address either a compounding effect or the fact that a small difference could accumulate over time. With the caveat that I may be misinterpreting the table, they did show that students with higher initial knowledge had faster learning rates [0]. That seems to be consistent with some students gradually accumulating an edge that grows over time, even if prior knowledge due to having more opportunities is also a factor, which is the authors' hypothesis. However, those rates were in log odds, meaning they decreased over time in percentage terms. That's only within the same task, so I don't think that rules out other types of compounding.

I will say that a student who consistently learns slightly faster and over the course of their entire education ends up drastically more skilled as a result would definitely be a faster learner, but that seems more muted than most people's intuitions of a "fast learner" or someone with a "knack" for a subject.

[0]: https://www.pnas.org/doi/10.1073/pnas.2221311120#t02

I’ve been really liking Zotero, but I don’t use it for webpage bookmarks outside of topics I’m researching. Maybe I should rethink that.

There are pros and cons to every statistic. Percent of GDP accounts for the fact that the economy is growing, which means more to tax. I used it primarily because the article does. I think percent of receipts makes more sense as receipts are essentially the agency’s product.

The article presents an interesting case study, but it's unclear how generalizable it is from a single example.

One idea the author suggests is that tax agencies will grow to take up roughly 1 percent because 1 percent of the budget is so negligible. The U.S. provides an interesting contrast. In 1955, the IRS was 0.08 percent of GDP [0] [2]. In 2008, it was 0.093 percent of GDP [0] [1]. So it's much lower, but also has remained fairly steady between 1955 and 2008. Looking ahead, the new IRS budget is around $20 billion, which is 0.072 percent of GDP [0]. To pick another example, the Canadian Revenue Service was about 0.2 percent of GDP in 2018 [3] [4].

One other assumption is that the Australian Tax Office does the same, at least when normalized to GDP. I'm not sure that's true, but investigating that would take more time.

[0] https://taxfoundation.org/blog/irs-budget-increase-technolog... [1] https://fred.stlouisfed.org/series/FYGDP [2] https://fraser.stlouisfed.org/title/budget-united-states-gov... See page 1000

If you're curious how Sam Altman's principles translate into donations, you can look up his contributions on Open Secrets: https://www.opensecrets.org/donor-lookup/results?cand=&cycle....

I don’t necessarily disagree with the author that the “prefer composition over inheritance” advice is taken too far, but I don’t find this example to be too persuasive. Most of the simplification comes from using a list and named triple instead of new classes. Those are good techniques, but they aren’t inheritance. (Well, data classes tend to be better, but named tuples are perfectly fine here.)

One thing your initial reasoning left out is that human concepts are not simple, either. Money may seem simple until you start to consider currencies, rounding, taxes, fees, etc. Text may seem simple until you consider punctuation, different alphabets, math symbols, emoji, and other special symbols, glyphs, or characters. Names may seem simple until you consider suffixes, names that consist of multiple words, middle names, cultures that place the family name first, nicknames, name changes, various accents and other "special" characters (that probably are perfectly normal to the person with the name), etc. As a programmer you often have to deal with other programmers' solutions to handle all this complexity, which may be flawed or simply different.

I mention all this not to pick holes in your logic but because it sounded like you were trying to look more closely at your intuition.