I am a little concerned that this would be totally unsingable for anybody who actually knows the original well (which is maybe not many people in the scheme of things, but the Bayesian Choir out here has done the original song before.)
gwillen
I mostly agree, but I’m particularly surprised at the results for the Hershey’s 45%. That’s not all that dark (i.e. children might want to eat it), and 2 oz is not all that much chocolate for a child to eat, and it looks like 2 oz would be enough to rise above the less stringent FDA limit for children.
Thanks for explaining! I feel like that call makes sense.
It seems like you could mitigate this a lot if you didn’t generate the preview until you were about to render the post for the first time. Surely the vast majority of these automated previews are being rendered zero times, and saving nothing. (This arguably links the fetch to a human action, as well.)
If you didn’t want to take the hit that would cause—since it would probably mean the first view of a post didn’t get a preview at all—you could at least limit it to posts that the server theoretically might someday have a good reason to render (i.e. require that there be someone on the server following the poster before doing automated link fetching on the post.)
This whole thing shades into another space I think a lot about, which is error handling in programming languages and systems.
Some parts of the stack I described above really seem to fall under “error handling”—what do you do if you can’t reach component A from component B? Others seem to fall under “data representation”—If you poll someone who they’re voting for, and they say “I’m not voting”, or “I don’t know”, or “fuck you”, or “je ne parle pas Anglais”, what do you write down on the form (and which of those cases do you want to distinguish versus merge?) But the two are closely related.
Nested layers of “options”
Here I use “option” in the sense of C++
std::optional<>
/ RustOption
/ HaskellMaybe
.It feels to me like “real-world data” often ends up nested in thick layers of “optionality”, with the number of layers limited mostly by how precisely we want to represent the state of our “un-knowledge” about it. When we get data from some source, which potentially got the data in turn from another source, and so on, there is some kind of fuzziness or uncertainty added at each step, which we may or may not need to represent.
I’m thinking about this because I’m feeding data from Home Assistant into Prometheus/Grafana to log and graph it, and ran across some weirdness in how HomeAssistant handles exporting datapoints from currently-unavailable devices.
Layers of optionality that seem to exist here:
The sensor itself can tell us that the thing it’s sensing is in an unknown state. (For example, the Home Assistant Android app has a “sensor” tracking the current exercise activity of the person using the phone, which is often “unknown”.)
The sensor itself could in theory tell us that it has had some kind of internal malfunction and is not sensing anything (but is still connected to the network.) I don’t have examples of this here.
The system only samples the sensor at certain times; this may not be one of those times, so the current state may be inferred from the previous state. (This is sort of a weird one, because it involves time-dependence, which is a whole other kettle of fish.)
The system’s most recent attempt to sample the sensor could have failed, so that the latest value is unknown. (This is the case that gives the weirdness I ran into above—the Home Assistant UI, and apparently also the Promethus exporter, will repeat the last-known value for some time when this happens, which I think is ugly and undesirable.)
The Prometheus scraper could receive some kind of error state from Home Assistant. (In practice this would be merged with the following item.)
The Prometheus scraper could fail to reach the Home Assistant instance, and so not know anything about its state for the current instant.
(From this point on, I’m talking about things you wouldn’t normally think of in this framework at all, but I think it fits:) Prometheus could display an error in the UI, because it can’t reach its own database to get the values of the datapoint.
My browser could get an HTTP error from Prometheus indicating a failure to even produce a webpage.
My browser could give an error indicating that it couldn’t reach Prometheus at all.
I have obviously added every conceivable layer I could think of here, including some that don’t usually get thought about in a uniform way, and some that we would in practice never bother to distinguish. But I’m a data packrat, and also an amateur type theorist, and so I think a lot about data representations.
Oh actually this is also happening for me on Edge on macos, separately from the perhaps-related Android Chrome bug I described below.
Good question, just did some fiddling around. Current best theory (this is on Android Chrome):
Scroll the page downward so that the top bar appears.
Tap a link, but drag away from it, so the tooltip appears but the link doesn’t activate. (Or otherwise do something that makes a tooltip appear, I think.)
Scroll the page upward so that the top bar disappears.
Tap to close the tooltip.
If this doesn’t reproduce the problem 100% of the time, it seems very close. I definitely have the intuition that it’s related to link clicks; I also note that it always seems to happen to me on Zvi’s posts, in case there’s something special about his links (but probably it’s just the sheer volume of them.)
I see a maybe-related problem in Chrome for Android. It’s very annoying, because on a narrow screen it’s inevitably covering up something I’m trying to read.
Importance vs Seriousness of projects
(Note: I’m not sure “serious” is the right word for what I mean here. As I was writing this, I overheard a random passerby say to someone, “that’s unprofessional!” Perhaps “professional” is a better word for it.)
While working on some code for my MIT Mystery Hunt team, I started thinking about sorting projects by importance (i.e how bad the consequences would be if they broke.)
The code I’m working on is kind of important, since if it breaks it will impair the team’s ability to work on puzzles. But it won’t totally prevent progress (just make it harder to track it), and it’s not like puzzles are a life-or-death issue. So it’s a bit important, but not that important.
It’s also possible to write code at Google that isn’t that important—for example, a side project with no external users and few internal ones. But even unimportant code at Google is typically “serious”. By that I mean… I guess that it does things “properly” and incurs all the overhead involved?
Code in source control is more “serious” than code not in source control. (I don’t even write hobby projects outside source control anymore, and haven’t really for years—that level of seriousness is table stakes now.) Code running in the cloud is more “serious” than code running on my desktop machine—it’s more effort to deploy, but it’s less likely to suffer from a power outage or an ISP failure.
And it’s also more possible to collaborate on “serious” projects—writing your own web framework can genuinely get you advantages over using an existing one, but collaborating with others will be a lot harder.
Of course, if your project is important but not “serious”, you have a big problem. You need it to keep working, but it’s running on your laptop, using an undocumented framework only you know how to work with, using your personal Amazon credentials, and you do most of your testing in production. Sooner or later, your important project will break, and it will suck. (And if you do manage to keep it going, this will sometimes require a heroic effort.)
On the other hand, the costs of being too “serious” are all about overhead. You have a perfectly good computer on your desk, but you pay for two servers in the cloud anyway, one to deploy and one to test on. You have separate project accounts on various services, separate from your personal ones, and manage lots of extra credentials. (And you don’t store them on your laptop, oh no; you store them in a credential storage service. Er, hm...)
“Don’t test in production” is good advice for important projects, but it’s defining advice for serious projects—if you don’t follow it, that’s inherently less serious than if you do. Your overhead is lower, but with a higher chance of catastrophe.
This musing brought to you by the entire day I have wasted today, trying to get a local development environment to match the behavior of a cloud environment, to reproduce a problem. I haven’t succeeded yet. The seriousness of this overhead really feels out of proportion to the project’s importance—it’s not even mystery hunt season, nobody’s even using it! Yet I would feel unserious leaving a trail of pushes to prod to diagnose the issue, without at least visibly struggling to do it “the right way” first.
(This also belatedly explains a number of annoyed disagreements I have had with other devs over project infrastructure. I each case, I was annoyed that their choices either seemed too serious—having excessive overhead—or else not serious enough.)
Why [not] ask why?
When someone asks for help, e.g. in a place like Stack Overflow, they are often met with the response “why do you want to do that?”
People like to talk about the “XY Problem”: when someone’s real problem is X, but their question is about how to do Y, which is a bad way to solve X. In response, some other, snarkier people sometimes talk about the “XY Problem Problem”: when someone’s problem is Y, and they ask about Y, but people refuse to help them with it because they’re too busy trying to figure out the (nonexistent) value of X.
The other day, I thought about a taxonomy of good responses to the kind of informally-specified request for help that one sees online. I came up with the following:
Straightforward answer to the question asked.
“Frame challenge” (This is Stack Overflow terminology; the others below are not.)
“I understood your question, and I also understood your underlying problem, and I would like to offer an explanation of why I think the straightforward answer to your question does not solve your underlying problem.”
Although this kind of response doesn’t directly answer the question, I think it’s good because (1) it’s required to directly address why not, which provides something for the asker to disagree with if appropriate; and (2) it provides something that the answerer thinks is more useful than an actual answer.
“Safety challenge”
“I think your question provides evidence that you are doing something dangerous to yourself or others, and you are not aware of that danger. A direct answer would endorse or contribute to that danger, so instead I want to warn you about the danger.”
This can be condescending if the danger is minor, or not real. But again, I think it’s good because (1) it directly states why it doesn’t answer the question, and (2) it provides some information the answerer thinks is more useful instead.
“Assumption challenge”
“I think it is not possible to answer your question, because it embeds an assumption that is not true, as follows: [...]”
Good, because it clarifies what the assumption is, which gives the asker the opportunity to argue or clarify.
“Ambiguity challenge”
“I did not understand your question, and I am unable to answer it because I can’t figure out what it’s asking.”
This one is interesting and I will discuss it below.
When someone responds to “how do I do X?” with “why do you want to do X?”, I think this creates conflict for a few reasons. Primarily, it tends to insult the asker. As certain people on this site would say, it’s a status grab: “I know better than you what question you actually need answered, and it is not the one you asked; try again.” It sets the answerer above the asker in status.
One of the reasons that “frame challenge” works so well on Stack Exchange is that you have to declare that you’re making one. Saying “I would like to challenge the assumptions of your question” comes across as more respectful, and less status-grabbing, than “why would you want to do that? Don’t do that.” I think “safety challenge” could work similarly. Saying “you shouldn’t do that, it’s dangerous” will always come with some amount of status assertion, but saying “I think that’s dangerous, and here’s why” is less of a status grab than “Why would you want to do that?”, because it provides an explanation, rather than assuming it’s obvious and putting all the burden of communication on the asker.
Another reason is that it provides more information to the asker. For a “frame challenge” to be a valid answer on Stack Exchange, it has to include an explanation of why the answerer thinks the asker’s frame is bad. The ball is in the answerer’s court to provide the asker with useful information. A bare “why would you want that?” does not.
Stack Exchange’s question/answer structure really helps here, compared to other types of discussion fora. In unstructured discussion fora, it’s easy for a “Why?” to turn into an angry argument between the original asker and the responder. On Stack Exchange, each answer is a separate conversation thread, meaning that (1) conversation in response to one answer can’t prevent someone from giving a better answer, and (2) multiple independent answers can be voted up, so there’s room for BOTH “here’s the answer to your question” and “here’s why I think that won’t help you” to be upvoted and discussed separately, on the same question (and I’ve seen this happen.)
Above I mentioned “the burden of communication”, which I think is a big part of what’s going on here. It is roughly always the case that a question is ambiguous in some way, or requires some context to understand. This means there will be some burden of negotiating the necessary context between asker and answerer. “Why do you want to do that?” tosses 100% of the burden back on the asker; it expresses “I don’t like your question”, but makes no effort to bridge the gap. “Why? Well, it all started about 14 billion years ago...” There are always infinite layers of “why”, and this is no help in figuring out what the responder feels is missing from the question.
“Ambiguity challenge”, which I suggested above, is the least helpful of my suggested responses—to be helpful, I think it needs to come with some effort to explain what about the question is ambiguous. What form that will take depends on the question. It still beats “why?” because “the problem is ambiguity” is still some information. It means the problem is not safety, or clearly false assumptions. And it’s a direct statement that the responder does not understand the question, which implies they aren’t being totally condescending (“I understand you, but I refuse to help because I think your request is stupid.”)
I’m surprised your kettle is only 1000W. You should be able to find a 1500W one. (The max power possible on a 15A circuit is higher, but I believe 1500W is the maximum permitted “continuous” power draw, and seems to be the typical maximum for heating appliances.)
As you say, if the circuit is shared, you may not be able to draw the max, but kitchen counter circuits are required to be separate from the rest of the house, so if you’re not running other 120V kitchen appliances at the same time, you should have the full power of the circuit.
It seems like you misunderstood something here: the “virus with 100% lethality in mice” was the original wild-type (“Wuhan”) sars-cov-2 virus. It was the mice that were engineered for their susceptibility to it. That’s why the 80% headline number is meaningless and alarmist to report in isolation: The new strain is 80% fatal in mice which were genetically engineered to be susceptible to original-flavor COVID, which is 100% fatal to them.
I feel that the Robin Hanson tweet demands a reply, with what I thought was a classic LW-ism: “Humans aren’t agents!”
But I can’t actually find the post it comes from, and I think I actually got it from Eneasz Brodski’s “Shit Rationalists Say” video. (https://youtu.be/jlT3MeCzVao)
Does anybody know where it originated? (And what Robin thinks of the idea?)
This didn’t get attached to the “Apollo Almanac” sequence right (unless I just got here too early, and you’re about to do that.)
Or the newer version, “one weird trick”, where the purpose of the negative-sounding adjective “weird” is to explain why you haven’t heard the trick before, if it’s so great.
Tragically I gave up on the Plate Tectonics study before answering my most important question: “Is Alfred Wegener the Balto of plate tectonics?”
Let me back up.
Tangential to the main point, but I love your opening.
I also suppose that it’s possible for those without the context to enjoy the dialogue of the high context parts, even if they don’t quite understand it.
That’s pretty much where I’m at on it. Although, I have played enough poker that I know all the vocabulary, just not any strategy—I know what the button is but I don’t remember how its location affects strategy, I don’t know what a highjack is, but I know the words “flush”, “offsuit”, “big blind”, “preflop”, “rainbow” (had to think about it), “fold”, etc. etc.
But it’s maybe telling that I have played this game, and I found your example flavorful but mostly skimmed and didn’t try to follow it. For someone who has never played I think it’s just word salad, and probably fails to convey flavor or really anything at all.
EDIT to add: Perhaps to some degree a case of https://xkcd.com/2501/ ?
One thing to keep in mind: If you sample by interview rather than by candidate—which is how an interviewer sees the world—the worst candidates will be massively overrepresented, because they have to do way more interviews to get a job (and then again when they fail to keep it.)
(This isn’t an original insight—it was pointed out to me by an essay, probably by Joel Spolsky or one of the similar bloggers of his era.)
(EDIT: found it. https://www.joelonsoftware.com/2005/01/27/news-58/ )
This makes sense, but my instinctive response is to point out that humans are only approximate reasoners (sometimes very approximate). So I think there can still be a meaningful conceptual difference between common knowledge and shared knowledge, even if you can prove that every inference of true common knowledge is technically invalid. That doesn’t mean we’re not still in some sense making them. …. And if everybody is doing the same thing, kind of paradoxically, it seems like we sometimes can correctly conclude we have common knowledge, even though this is impossible to determine with certainty. The cost is that we can be certain to sometimes conclude it falsely.
EDIT: This is not actually that different from p-common knowledge, I think. It’s just giving a slightly different account of how you get to a similar place.