I have a similar story, but perhaps even stranger.
I work for a startup. We often bring a wooden arcade with us to conferences as a marketing gimmick.
The arcade runs a single side-scrolling video game. You're running from a monster and dodging obstacles. The goal is to survive as long as possible, and your result is measured in meters.
There are always a few competitive guys who spend the entire conference taking turns to play it. And every single time, the same thing happens.
Say the current high score is around 200m. Everybody fails somewhere around that number: 190m, 186m... Maybe someone manages 210m. And the high score moves up at a snail's pace.
Then, a new guy shows up and gets something like 500m on his third try. From their next turn on, everybody easily does 450 or more, even though they were struggling to get past 200 just one turn ago.
What makes it stranger is that the game is dead simple. It's not like the new guy discovered a move that unlocked this capability. And it wasn't a lack of motivation either - they'd all been playing for an hour already. They just started performing better after seeing it was possible. There has to be a name for this phenomenon.
Climbers know this phenomenon as the "send train". A group of climbers has been working on a problem for a while. When the first person sends it, it often happens that multiple people are successful in the immediate attempts that follow. Part of it is watching the successful beta, but it happens even when everyone knows the moves. Once you've seen it's possible, you stop climbing tentatively and commit to the hard move instead of hedging for a fall.
Reminds me of amateur table tennis. There is a strange dynamic where you down regulate your performance unconsciously when the opponent is playing worse and vice versa.
I am pretty sure if you play at pro level you train this out of yourself. But then, the marathon / running examples where certain milestones get broken by one person and then suddenly by a host of others, is a counterargument.
I think the difference is that, in the table tennis example, it happens unconsciously and you can't help it. But you're right, it likely happens in most sports.
The mixed boys/girls classes example is, as you said, deliberate. And I too remember holding back on purpose in such situations when I was a kid.
With the arcade, no one was deliberately holding back. I'm sure of it.
Is it that you’re holding back against weaker opponents, or that you’re more excited and engaged when you’re playing against someone that forces you closer to the edge of your ability?
I think it's largely due to psychology. If 210m is considered the best, then as they approach it they may start to tense up and choke. When the goal and possibility is known as 500m, then there's no point being concerned near 210m.
There's little reason to aim for a score a lot higher than the current best; and when getting close to the score you're aiming for, it's easy to get agitated and make a mistake.
And if you do beat the high score, you're likely to loosen your attention right after that, and it's even annoying to keep going for much more.
I like to leverage that when brainstorming solutions to hard problems. Instead of contemplating small percentage improvements, try to think about what's in the way of improvements that are orders of magnitude better (e.g., don't take time to run a big task from 100s to 90s, take it to milliseconds). Sometimes it unlocks big ideas.
I work in software deployment for large orgs. I use this technique to optimize. "How can I provision or deploy this with one package install, and launch instance." Typically take multi-page or multi-step deployments down to fully automated.
Reference-dependent effort ("bunching" around a target) [1] is probably
the closest thing. The existing high score was acting as everyone's reference
point. Anchoring [2] is the more general cognitive version.
You could, but that would just dodge the problem they want to solve.
They're not actually interested in determining who goes first or anything practical like that. The article even implicitly admits as much. After all, you could just use normal dice and roll again on ties or, like you suggested, come up with an extra protocol built on top of them.
"We want dice that determine who goes first without a tie" is just a catchier way of saying "We want N dice that all have the same probability of showing the higher number but zero probability of a tie," which is an interesting mathematical problem.
I show it when I teach Haskell, and it's what usually makes it "click" for students. Probably because motivating examples are in normal imperative pseudocode.
Your linked article hints at the advantages of using Monads and therefor ADTs (Algebraic Data Types), and does it really well.
The wiki entry on effect systems[0] tells me that a focus of an effect system is something different from a focus of monads. "The term algebraic effect follows from the type system", where an effect system is effectively a type and effect system. It links to Monadic encapsulation of effects[1] and mentions the runST monad when it mentions support in Haskell, as that one seem to "simulate a type and effect system".
One thing this page makes clear is that do-syntax could mean all kinds of things, which seems like a disadvantage for readability. Assuming you know the specialized syntax, elvis operators looking different from async code or a nested for loop seems like an advantage? The performance implications are entirely different.
The problem with monads is their composition. Ie. questions like how is the do notation supposed to work if I want to return:
* an Option<Async> or Async<Option>?
* both an Option and an Async (a product, or tuple type)?
* either an Option or an Async (a sum, or tagged union type)?
Monad transformers can be written for wrapping monads into other monads (as a simple example, an Option is equivalent a List with exactly zero or one elements), but they're something of an ad hoc solution and do not generalize well.
This is fundamentally an issue similar to the "function color" problem, or the fact that exceptions in most languages are a limited, ad hoc effect system and do not compose well. Java gave checked exceptions a bad name largely because of their lack of compositionality, but it's more that the particular implementation is poor.
To be fair, that was in 1994 and nobody had worked out these things yet even in the academia. Algebraic effects are the attempt to do just that.
Right, I understand the history (although I'm not sure I'd say that exception don't compose well) and I understand that "algebraic effects" are an attempt at something better. But I don't understand whether they're something that can be precisely defined or just informal terminology for "a better sort thing for dealing with effects".
You can precisely define any particular model, but not all work in the area shares the same model. I think you know about the capability-passing model, which is quite different to the algebraic effects (e.g. row types) models.
The general ideas are:
* effects are handled by handlers (called capabilities in the capability-passing model)
* function signatures describe the effects that are used
* effectful code is written in direct style, not monadic style
OK, and in the general case a handler allows its body to "perform" an action, and when the action is performed it has the ability to "respond" to it in (in some cases) a very flexible way, running it never, or multiple times, or in a modified environment, or possibly even passing it out of the scope of the handler entirely.
> function signatures describe the effects that are used
Would you say this is not possible in an untyped language then?
> effectful code is written in direct style, not monadic style
> OK, and in the general case a handler allows its body to "perform" an action...
Yes, although not all systems allow this, as implementing full continuations is involved and can hurt performance.
> Would you say this is not possible in an untyped language then?
You can definitely implement the ideas of algebraic effects in an untyped language, but you lose one of the benefits.
> I don't understand the distinction here
Monadic code is code where the order of evaluation is specified by bind / flatMap. Direct-style just uses the language's built-in control flow. See https://noelwelsh.com/posts/direct-style/ for more
I have the same problem. If my sandbox includes `denyRead: ["~"]`, claude consistently tries to do things inside my home directory. For example, every time I start claude I tell it to "run pwd".
And every time it says this:
Bash(pwd)
⎿ /home/<username>
⎿ Shell cwd was reset to /home/<username>/Projects/<current-working-dir>
This breaks a bunch of features in inconsistent ways (e.g., `git status` sometimes works and sometimes doesn't).
There are issues reporting this problem to Anthropic but they are all closed with no helpful comments:
> However having worked with Typescript for 8 years now... I'm not sure I could go back to Ruby without types.
Very true for me as well. I've never worked with Ruby but feel the same way about Django.
Btw, if you're looking for a "Rails but with TypeScript," my colleagues and I are working on almost just that: https://wasp.sh/.
The main difference, besides the ecosystem, is that we're more in the "configuration over convention" camp. Wasp has a simple DSL for specifying said configuration, but it's about to be replaced with a TypeScript file.
Wasp is still in beta and nowhere near Rails-level polish. But, depending on your early adopter tendencies, you might find it interesting regardless. If you do try it out, please reach out and share your thoughts.
> TS is very AI-native, to the point I'd agree it's near magical in terms of contracts.
I agree.
Not only that, I feel like TypeScript is currently the only popular high-level language with a type system capable of communicating all meaningful information. It seems to have hit an LLM sweet spot.
Looking at other candidates:
- Rust is popular and has a powerful type system, but it forces you to program at a level that's lower than necessary for most projects, hindering usability.
- Go is much more usable and very popular, but its type system can't communicate much.
- Haskell has an excellent type system, but it's nowhere near popular enough, and its usability suffers due to esoteric constraints (laziness, purity).
- etc.
I don't know the recent developments in Python's and Ruby's type systems. They may be able to compete these days, but they were nowhere near TS's level in terms of contract a few years ago when I last tried them out.
And I admittedly have no idea what's going on with C# and Java, but I'd love to hear about it.
This looks like a compilation of emails made available through various court cases and leaks over the past 15+ years. Each conversation lists a source (look for small text after all the messages). There's a bunch of different sources.
As to why it's relevant now - I don't think it is. It's likely just a spin-off of similar renders that started popping out in relation to the Epstein files.
I work for a startup. We often bring a wooden arcade with us to conferences as a marketing gimmick.
The arcade runs a single side-scrolling video game. You're running from a monster and dodging obstacles. The goal is to survive as long as possible, and your result is measured in meters.
There are always a few competitive guys who spend the entire conference taking turns to play it. And every single time, the same thing happens.
Say the current high score is around 200m. Everybody fails somewhere around that number: 190m, 186m... Maybe someone manages 210m. And the high score moves up at a snail's pace.
Then, a new guy shows up and gets something like 500m on his third try. From their next turn on, everybody easily does 450 or more, even though they were struggling to get past 200 just one turn ago.
What makes it stranger is that the game is dead simple. It's not like the new guy discovered a move that unlocked this capability. And it wasn't a lack of motivation either - they'd all been playing for an hour already. They just started performing better after seeing it was possible. There has to be a name for this phenomenon.