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.

Ah, I see. Maybe: somebody says they love audio cassette players, and start talking about the super tactile mechanical buttons and switches that go chunk in a satisfying way. You could rightly object that that you can put buttons like that on an mp3 player. But it's a historical fact that these things are actually linked, in a way that's meaningful to people, namely in their personal nostalgic experiences.

> But it's a historical fact that these things are actually linked

You might think that if you didn't know about the breadth of cassette players, but you'd be wrong on the technical merits, because cassette players existed that did not have those buttons (and also those buttons predate cassette players).

Describing your love of a certain kind of button as a love of things that play cassettes is a misattribution. If you had said "I like the audio cassette players that have those kinds of buttons because those buttons are amazing" you'd have hit the truth encased in the trappings of your nostalgia.

Cassette players and chunky buttons are historically linked though. That there's no intrinsic fundamental technological connection and counter-examples exist doesn't change the fact that most people with memories of cassette players will have memories of chunky buttons connected to that. You're hung up on technicalities when the discussion is actually about nostalgia.

In an case, the author specifically cites the example of Ion Fury, a game which ships with a hardware renderer enabled by default but also uses nearest neighbor interpolation, so the premise that the author isn't aware that the aesthetic isn't possible with hardware rendering is mistaken. He knows. He's calling it software rendering because that's what the aesthetic is historically connected to.

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.

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.”

> 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?

yes and has nothing to do with prompting congratulations

The question was clearly about whether or not you felt joy from something that you didn't take part in creating. The fact that you're now playing dumb and obsessively returning to the topic of prompting shows you don't have a good counterargument.

I'll remind you again: it's none of your business what gives people joy.

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.

Ok let's try to argue you said

> 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?

What has to do with prompting? you don't prompt for experiences like that, we are lucky that we live in a world full of authentic unexpected experiences. WTH has to do with prompting.

> 1.5 Only activities that involve creation can lead to joy.

Exactly, joy and meaning, like basically ALL psychiatrist and what not they're telling us since the start of the 21st century.

If you happen to like something that got out of a prompt, then imo you're a mediocre who doesn't know better, the same that listen to shit music, movies, games and what not. The same miserable mediocre that doom scrolls social, ingest fake news, propaganda and ai slop and doesn't know better.

I'm not saying mediocre as derogatory term to the person it's just what it is.

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.

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.

hmm.. can you try it again please. it's just the simple animation on the homepage.

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
  }

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.

In rust this would simply be

   enum ConnectionStste {
        Connected(u32),
        Disconnected
    }

or

   struct Connected { peer_ip: u32 }
   struct Disconnected;
   struct Connection { state: State }

But you can't hold both a `Connection` and a `Connection` in the same variable or pass them to the same function, which defeats the point.

It's the typestate pattern. The compiler enforces valid state transitions and so you can't just pass to the same function. It's useful to ensure that only some transitions are allowed. To be honest, the connection state presented by GP is a bad example. But you shouldn't say "it defeats the point".

A better example is an HTTP writer. One state is `Headers` with the methods `add_header()` and `body()` which returns the response in state `Body`. This enforces that one can't add headers after `body()` has been called. But you can finish the response in the `Body` state. If you do something not in this order, you get a compile error.

Thanks. This had me thinking to myself some. I found this https://cliffle.com/blog/rust-typestate/ too, which others may find useful..

Wouldn’t peer: Option be enough to represent this?

None = disconnected

Personally I don’t like using nil to represent specific states in my domain. I try to only judiciously use it to represent the lack of knowledge about some state, like if I need to reach out to some external service I don’t control, that may or may not give me an answer for my query (and conversely, I don’t like putting “unknown” cases into my enums).

Yes, the type I wrote down is isomorphic to Option, 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. So if you have a function that takes a Connection and some other Option, 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.

Yes, it'd probably be compiled into very machine code. However defining an enum for it puts the intention into the source code more explicitly, so that's considered the more idiomatic way. You'd probably have a `fn peer_id(&self) -> Option` accessor that you'd use in the case where you'd want the Option.

This opens you to the possible mistake of accidentally passing something of value None that then is mistakenly interpreted as a valid disconnect.

In some cases using None that way is totally fine, but it is a trade off and the cleaner way is to use a separate type

it's just a minimal example, in reality you would typically have various other data that exists exclusively in connected/unconnected states

Rawwrr, use dependent types and write your entire program in the signature!

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!

> 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.”?

There is no use for something like Jev on a singular document from a single source; it's use comes from concatenating multiple sources into a single document and asking for an answer. What they did here is the most common workflow for something like Jev: "here's all the data we have and know about, now give us a go/no-go decision"

In that workflow, you only need a single bad actor to poison the results.

Most likely the chip running at the core temperature of the sun.

We'll have to figure out how to read and right to the surface of a black hole to get speeds that high.

I think you switched 2 and 3.

People are willing to lose a small but predictable amount of money to avoid occasionally and unpredictably losing a massive amount of money. The former is a loss they can plan for and absorb. The latter might kill their business.

Traders are often happy to take the other side of that trade because they can trade against many counterparties, collect a small premium from each one, and try to ensure their counterparties won’t all fail in a correlated way.

Yes, it's not about onions.