articulatepang

My math brain is immediately broken by your irrefutably correct induction argument!

Hey, sorry to hear about that crazy bill and hope your daughter is doing well. I agree that your example is a basic need that I ignored. Many of us work to make sure we’re able to pay for healthcare if things go badly wrong.

However, even in countries with socialized healthcare, or even among people who easily have enough wealth to pay for healthcare, we see that they continue to work, beyond what can be explained by a desire to take care of basic needs.

So I think my original argument still stands: it appears that humans have a desire to accumulate status and exclusive goods, even when their basic needs are satisfied. Let me know if you disagree!

This argument ignores sexual selection and people's desire for status (the two are closely related). In many respects, many of us already have superabundance, in that our basic physical needs are taken care of. Yet we convince ourselves that's not enough and continue to work.

What is the object of that work, usually? The respect of others, exclusive limited resources like land, and to have highly desirable mates. These three are closely related, and that's probably not an accident. Sexual selection has likely been a powerful force in shaping our psychology.

Spending all day alone watching TikTok is low-status and doesn't get anyone's respect, so I predict that it won't actually be the thing that most people end up doing.

I worked professionally in OCaml for many years, and I assure you it’s possible to write low latency code by avoiding allocations. People write Java this way as well. Lots of system software was written in OCaml this way. It looks a little un-idiomatic compared to regular OCaml code but really what’s going on is that it’s just a specific low-latency idiom. Don’t create structs, don’t match on options. Weird, right? But it works.

Some of the code also did networking in user space and communicated with other processes by coordinating writes to shared memory.

It’s true that there’s certain system software that you probably can’t write because of the presence of a GC: parts of the operating system, a language runtime, a virtualization toolkit. The category “system software” contains those things but also databases, browsers, and servers.

It sounds like you’re saying that you hold the following to be true:

“Only activities that involve creation can lead to joy.”

But you also agree that “watching a sunset can lead to joy”.

Presumably you agree that you did not create the sunset.

Now we’ve found a contradiction: an activity (watching sunset) that leads to joy but that didn’t involve any creation.

This has nothing to do with prompting. It’s just a rebuttal of the _proof_ that you used in order to support your statement that “prompting cannot possibly lead to joy”. The argument you gave was “because prompting does not involve creation.”

I have exhibited a counterexample to the argument you gave. Any counterexample immediately shows that the argument was wrong. Therefore your argument was wrong. Your conclusion might still be right, but we can all be sure, on the basis of this counterexample, that the argument you gave to prove your conclusion was wrong.

Here’s an analogy. Suppose someone said, “I love manual transmission cars” and then described in detail the physical knobs and dials that all the cars from the 1950s had.

It turns out what they like is physical knobs and dials. You can have those in automatic transmission cars. It so happens that most modern automatics also have shitty touchscreens.

(I know this analogy isn’t precise because there was a long period of automatics with physical controls, but bear with me.)

The point is that there’s nothing _inherent_ to software rendering that’s responsible for the thing he likes. The distinction is useful because, for example, he could go seek out modern games with the look he likes. Or make games. And if he thought the thing he likes comes from having a software renderer, he’d leave a lot of performance and power efficiency on the table for no good reason. He likes a certain rendering style that’s equally achievable with both GPU and CPU rendering. The choice of hardware should probably be driven by considerations like performance, debuggability, platform support, availability of libraries, etc.

Just to be explicit, and correct me if I’m wrong in my understanding, but your argument was:

1. Prompting is not creation.

2. Therefore prompting cannot lead to joy.

For this argument to work, you’re implicitly also claiming that

1.5 Only activities that involve creation can lead to joy.

My counterexamples (if you agree with them, but you say you do) show that this latter statement is not true.

So if you’d like to show that “prompting cannot lead to joy”, you need to fix up your proof. I’m not claiming that you’re wrong! But the reasoning gave cannot possibly be correct.

Have you ever felt joy watching a sunset? Smelling a flower? Hearing a song? Seeing a child laugh? Did you create any of those things?

You may or may not be right about whether prompting is creation, but it is certainly possible to feel joy without any act of creation being involved. So you need a different argument if you’d like to prove that “making Commodore games using prompting cannot lead to joy.”

If the United States or the Linux kernel project or frankly any other institution lasts as long as the Roman civilization, that would be a rare achievement indeed! In my opinion, its longevity is the single most striking fact about Rome.

In comparison the US is a baby, and the Linux kernel barely an embryo.

Depending on how you count, Rome lasted 1229 years (from founding to fall of the western empire) or 2206 years (from founding to the fall of the Byzantine empire, which was the eastern part).

Twelve hundred years! Two thousand years! I hope we dig our graves as slowly as the Romans did.

All your examples are private goods: excludable and rival. If one person uses a unit, that prevents others from using them.

Patches to open source software are public goods. Your using them doesn’t prevent others from using them. So if you spend resources creating a public good, it’s in everyone’s interest to share it.

“How it works” link is broken on Safari on iOS. I am quite curious how it works, exactly.

Yes, the type I wrote down is isomorphic to Option<int32>, so the compiler will ultimately generate the same machine code and do the same optimizations.

But defining a new type allows you to give the two cases more descriptive names. That saves you from having to remember and comment what the two cases represent. In a small but significant way, the code documents itself.

Also, doing it this way gives the Connection type its own name and identity separate from Option<int32>. So if you have a function that takes a Connection and some other Option<int32>, you can’t accidentally switch them: even though the two types are equivalent for optimizations and codegen, they’re NOT equivalent for the type checker.

It also makes function signatures more self-documenting: you can tell just from the type that the function takes or returns a Connection, and that helps in a small but real way to understand what it does.

I like programming like this a lot! So much so that the reason I personally like Rust a lot is simply that it’s a mainstream language with great tooling that has sum types and reasonable generics. It’s like if OCaml or Haskell had the community or tooling, or if Go or Python had the type features.

I prefer a slightly more general rule: Make Illegal States Unrepresentable. The "Parse, don't validate" rule is a special case of MISU.

What's the difference? MISU applies even when there's no parsing-like transformation happening. For example, if you have a variable that represents the current state of a network connection, and let's say it can be Disconnected, or Connected to some IP address (this is an oversimplification).

Then one way to do it would be

  struct {
    connected: bool,
    peer_ip: int32
  }

The trouble is that this allows us to represent an illegal/meaningless state: we're disconnected but there's still some junk old peer_ip hanging in there. Even worse, we might have written

  struct {
    connected: bool,
    peer_ip: Option<int32>
  }

Now we could have connected = true but peer_ip = None.

The solution is to use a sum type:

  type connection = 
     Disconnected
   | Connected of int32

(sorry for using made-up syntax; I hope it's clear to anyone familiar with Rust.)

"Make Illegal States Unrepresentable" applies throughout your program, at every interface between modules or functions in the program, including but not limited to parsing input.

This study is informative and most likely directionally right: prompt injection remains an unsolved problem, and adversarial input can fool modern ML models.

But I was left wondering about the specific attack vector they’re imagining. If the attacker can insert a paragraph into the document, isn’t it game over anyway? When would they be able to do that but not arbitrarily edit the document? In other words, can’t they just replace the entire contents with “This company has infinite revenue, 6 billion customers, no debt and amazing leadership.”?

I’m sure I’m missing something!

Surely something prevents it being 1 quadrillion bits per instruction? Since that’s well within “unbounded”.