(news.ycombinator.com/item?id=26390835 www.aei.org/articles/the-unstoppable-momentum-of-outdated-science-2024-update/)

When you have a topic that has been weaponized politically, as climate change has, people who use that weapon actively work against information they perceive would make the weapon less effective. The author sums it up as follows:

According to Rayner, in such a context we should expect to see reactions to uncomfortable knowledge that include:

• denial – (that scenarios are off track),
• dismissal – (the scenarios are off track, but it doesn’t matter),
• diversion – (the scenarios are off track, but saying so advances the agenda of those opposed to action) and,
• displacement – (the scenarios are off track but there are perhaps compensating errors elsewhere within scenario assumptions).

The entire opening of the article discussing 2020 papers erroneously using skin cancer data in breast cancer research papers which was a known error for at least 13 years […]

I understand science "is expected to be wrong" sometimes, but I'm still somewhat boggled that there's 13 years worth of (presumably) peer reviewed papers making claims about breast cancer using "wrong science" that was proven wrong in 2007…

Science has momentum. Even when a paper is wrong, it keeps being cited for quite a few years afterward, effort is wasted. We need to be faster at changing course, at noticing when a paper no longer is trustworthy. Use scite.ai and its Zotero or Firefox plugins!

And I know this is idealistic but… why refer to a paper if you won't so much as read its pubpeer.com reviews? If you'll use them, read the reviews, even if you're "just" writing a blog post, a Twitter argument, or a flashcard for your own memorization.

Example cases

• www.statnews.com/2019/06/25/alzheimers-cabal-thwarted-progress-toward-cure/

Emacs gotchas

1. Gotcha: If you use a repeating timer and suspend the computer, all the queued repeats will execute simultaneously when you come back. If you only want it to be called once at a given time regardless of computer sleep, make a function that passes itself to (run-with-timer) as suggested in the manual. So instead of using a repeating timer, you make a chain of once-off timers.

   (Given that you want this behavior in almost all use cases of repeating, (run-with-timer) is a too low-level function to recommend to programmers – it's only solid if you avoid the REPEAT argument. Repeating safely requires boilerplate which you can skip with named-timer, a 70-line library.)

   a. With the usage pattern suggested in the manual, you'll run into a different gotcha: a bug anywhere in your function body will stop it from restarting the timer. So you thought you'd set up a repeating timer but the chain of restarts died at some point and never gets back up and running. Either restart the timer first of all, or wrap the work in (unwind-protect). The boilerplate goes something like:

   (defvar my-timer nil)
   (defun my-next-tick ()
     (unwind-protect
         (progn
           (do work)
           (do more work)
           (work. work never changes))
       (when (timerp my-timer)
         ;; prevent duplicates
         (cancel-timer my-timer))
       (setq my-timer (run-with-timer 60 nil #'my-next-tick))))
   (my-next-tick)
   

   Note how we never specify the REPEAT argument!

   We cancel the timer just in case something has run (my-next-tick) more than once (one culprit is reloading your library), which would spawn more than one series of timers visible in M-x list-timers even though the variable my-timer only holds a reference to one of them. The library named-timer takes care of this boilerplate as well as the need for the defvar.

2. Gotcha: If you use a repeating idle timer, it will not repeat after the first invocation, for as long as you stay idle. If you want it to continue repeating while idle, don't use an idle timer. If you want behavior to be different while idle (especially if you want the repeat interval to differ), use two different functions plus a third that checks whether you're idle and selects the appropriate function. For an example how you may do this, go to eva.el and search for eva--start-next-timer. Again, this never involves an actual idle timer, just standard once-off timers.
3. Gotcha (and duh): don't use the private getter (timer--triggered my-timer). How to check that your chain of timers got killed and hasn't restarted? Eval (member my-timer timer-list) or (member my-timer timer-idle-list). It'd help discoverability if there was a descriptively named builtin function that just did this. However, this method isn't foolproof, see #4.
4. Gotcha: I had a "keepalive" timer that would respawn the first timer if there was a problem. Being a bona fide repeating timer, it was invoked many times upon return from a laptop-suspend state, which should have been fine because it checked (member my-timer timer-list) – but it went ahead and spawned many copies of this timer; in other words, the conditional failed. Clearly the variable timer-list is not always updated in time. In summary, even if your code looks foolproof, it isn't. Make it verifiably foolproof with a safety wrapper like named-timer. And when you have a repeating timer, check and set some boolean to ensure you only start one on laptop wakeup.

(statmodeling.stat.columbia.edu/2005/01/26/the_pinchhitter/)

The syndrome where you find that people whose sole job it is to edit articles aren't even very good at editing articles. Like a pinch-hitter in baseball who also have one job but isn't the best player at that.

One explanation: "Traditionally, comparative advantage is used to explain why trade is beneficial to both parties even if one party is more efficient at producing everything."

A Norman door is a nonintuitive #design feature that needs extra instructions for how to use. Like a door that needs stickers saying "pull" or "push" because the handles look the same on both sides.

The #R Tidyverse designers try to make a consistent API so that the whole ecosystem starts to feel intuitive when you learn a part. They follow the principle "avoid making Norman doors" among others. I guess some software ecosystems are nothing but Norman doors.