Back in the day, Eliezer spoke of 2-place words:

I have previously spoken of the ancient, pulp-era magazine covers that showed a bug-eyed monster carrying off a girl in a torn dress; and about how people think as if sexiness is an inherent property of a sexy entity, without dependence on the admirer.

"Of course the bug-eyed monster will prefer human females to its own kind," says the artist (who we'll call Fred); "it can see that human females have soft, pleasant skin instead of slimy scales.  It may be an alien, but it's not stupid—why are you expecting it to make such a basic mistake about sexiness?"

What is Fred's error?  It is treating a function of 2 arguments ("2-place function"):

Sexiness: Admirer, Entity—> [0, ∞)

As though it were a function of 1 argument ("1-place function"):

Sexiness: Entity—> [0, ∞)

I think that this is such a great distinction, 1-place words vs 2-place words. And more generally, to think about how many "arguments" a word "accepts".^[1]

Next Friday

I ran into this yesterday. I was hanging out with a friend who asked if I'm interested in coming to any of his poker nights on Fridays. I was like, "let me see, next Friday I'll be away for..." and then I caught myself. What exactly does "next Friday" mean?

This happened on Saturday 3/29/25. I was trying to refer to Friday, 4/4/25. But I was using "next" as a 1-place word when really, I think it is a 2-place word. One argument is the entity: in this case "Friday". But I think there is a second argument that answers the question: "next relative to what?".

• Some people think of 4/4/25 as "this Friday", and so "next Friday" would be the Friday that comes "next" relative to "this Friday". In which case "next Friday" refers to 4/11/25.
• Other people think of 4/4/25 as "next Friday" because it comes next relative to the most recent Friday (3/28/25).
• And then there are other people who have more complicated rules. Like on 3/29/25 they'd think of 4/4/25 as "next Friday" but on 4/3/25, since 4/4/25 is so close, they'd assume that if you wanted to refer to 4/4/25, you'd say "tomorrow", and thus "next Friday" would have to refer to 4/11/25.

Personally, I like to avoid all of this and talk about "this upcoming Friday" or "the Friday after this upcoming Friday", or, especially when I'm writing, I'll just say the actual date: "Friday the 4th" or "Friday the 11th".

Efficiency and my startup

I think the word "efficiency" is another good example of something that is a 2-place word but where people frequently use it as a 1-place word. I ran into an example of this recently.

I am currently working on a startup where the product is admin software for small urban design firms. A few months ago I was at something of a crossroads and was unsure of what my path forward should be. After seeking advice from various people, I arrived at the conclusion that, to oversimplify, I should divide my time about evenly between 1) building an MVP and 2) talking to users.

But when I started to execute on this plan, I ran into some difficulties. Basically, I just found myself wanting to spend all of my time coding and none of it talking to users.

• I have one, maybe two prospective users who I've been in close contact with and who are eager to start using an MVP. Building such an MVP should take maybe three months or so and I just am really excited about getting it done.
• Before this I was spending basically all of my time talking to users and none of it coding. I think that experience kinda lead to a pent up desire to code building up in me.
• I have a full time job, as well as various other things I need to spend time on: exercise, chores, sleep, my girlfriend, my dog, my friends, myself, etc. Ideally I'd also do more writing, reading, play more sports, maybe learn Clojure or Haskell. I generally kinda struggle with time management. I always "feel behind". Anyway, adding "talking to users" to the list on top of "building an MVP" and everything else feels especially overwhelming to me right now.

If you have any experience with startups, you may be facepalming pretty hard right now. Spending too much time coding and not enough of it talking to users (amongst other things) is a classic failure mode for founders. It's very inefficient. You may be on your way to the comments section right now, ready to explain this to me. Before you do that, hear me out.

Efficiency is a 2-place word, not a 1-place word. It doesn't make sense to say that X is efficient. You have to say that X is an efficient way of achieving Y.

In practice, I think most people understand this and when they use "efficient" as a 1-place word it's because they think the Y is obvious.^[2] Like with startups, it's obvious that Y = "chances of being successful", or "chances of being successful multiplied by magnitude of success", or maybe even that last one with utility functions factored in. After all, diminishing marginal utility is a thing.

But I actually think that these values of Y are missing something important. They are all focusing on the destination. They're looking at the chances you reach a "good" destination and also ask the question of how good each destination is.

But what about the journey? I think you gotta factor the journey in. Y needs to incorporate it.

And with that said, I feel pretty good about my decision to spend all of my time coding right now. I think that in doing so I am sacrificing some "destination points", but what I gain in "journey points" outweighs this sacrifice.^[3]

Efficiency in route planning

I don't want to imply that you always need to "pass two arguments" when you use the term "efficient". Sometimes the Y is in fact pretty obvious and it is appropriate to just omit Y and use "efficient" as a 1-place word.

For example, if I said that "taking Broadway is a more efficient way to bike downtown than taking Naito", you'd probably understand what I mean. You'd probably understand that I'm saying that Broadway is more direct and will get you there faster.

So then, I wouldn't necessarily object to using it as a 1-place word here. However, even if people can correctly infer what value you're using for Y and the communication is successful — the other person successfully receives the message you are sending^[4] and understands what it is pointing to — I'd warn against using this societal default normatively.

Let me explain. The socially agreed upon default value of Y in this context is something like "get to your destination ASAP". So when I say that taking Natio is inefficient, it's implied that I'm really saying that it's an inefficient way to get downtown ASAP.

But should my goal be to get downtown ASAP? Shouldn't I also think about how dangerous a particular route is? How comfortable it is? How pleasant and scenic it is? I certainly care about all of those things and after factoring them in, prefer Naito despite it taking an extra three minutes.

But I think that it's easy to jump from "taking Broadway is more efficient" to "taking Broadway is better". What I'm warning against is taking that jump. I think that such jumps are not infrequent.

I, for one, made this mistake both with my startup and with bike route planning. With my startup it took me some time to realize that I should factor the journey in along with the destination.

With bike route planning, for the longest time I just took the path that seemed most direct. Then I did the Bike Buddy program where an experienced rider rode along with me and gave me advice. He said that most inexperienced riders just take the most direct route too. Then he explained that some routes are a lot more comfortable than others and so it often makes sense to sacrifice a few minutes and take a less direct route. To this end, it's often helpful to use a site like portlandbikemap.com to plan your route in advance.

Efficiency in software engineering

In everyday life people are often too loose with 2-place words like "efficiency". Even in the world of academia, especially in softer fields like urban design, people are still too loose. However, in the world of software engineering, this excessive looseness doesn't really happen.

Programmers are generally very, very smart people. They tend to understand when a word "takes multiple arguments", both because they are very, very, very smart, and because they can just viscerally feel it. After all, in their world, when they pass the incorrect number of arguments to a function, they get a compiler error. So then, programmers are never too loose with 2-place words.

Just kidding! One of my biggest pet peeves about this 2-place word stuff actually comes from the field of software engineering. And beyond this pet peeve, I don't really find that programmers are much better than other people are.

Here's my pet peeve: in the world of software engineering, when you talk about how efficient a piece of code is, you almost certainly are talking about how fast it is. Or maybe you're talking about how much memory it uses. But it's usually one of those two things. And it's often assumed that you're talking about situations where input sizes are ginormous.

Furthermore, it isn't uncommon for people to take the jump of assuming that "more efficient" code is better code.

Well, all else equal, it is better code. I think what I'm trying to say is that a lot of people will place a large burden of proof on showing that it is actually worth taking the inefficient approach. I disagree with this burden of proof as a heuristic in most contexts.

I've found that people can be quite attached to this heuristic though. I've had numerous disagreements during code review where it was clear that the actual difference in speed is only a few milliseconds or something, and that given realistic input sizes the difference in speed is unlikely to meaningfully grow, yet people will still feel that it is important to "be efficient". Efficiency, with the default value of Y, has probably become a lost purpose in a lot of these situations.

More generally, even if they're a convenient way to communicate, I think that "default arguments" are often a slippery slope towards more normative judgements, and I think it's worth keeping an eye out for this.

1. ^{^}

   And even more generally, to think about the argument type.

2. ^{^}

   For the programmers out there, it's as if they assume that there is a default value for the argument, and so the argument is actually optional. Something like const efficiencyInContextOfStartups = (action, goal = "maximizeExpectedMonetaryValue") => { ... }.

3. ^{^}

   And for various reasons, I'm more optimistic about my ability to divide my time in the future than I am right now. So moving forward, I think I'll be able to bounce between building, user research, sales, marketing, etc.

4. ^{^}

   See "vibratory telepathy".