In case you want to know what’s going on in the left side of that chart, they gave a log scale in appendix a. I was thinking it was silly to not just use that version on the top, but I guess log scales make big differences ’feel’ smaller.
A log scale is actually appropriate in this context from a first-principles perspective. Per scaling laws (and also general behavior of epsilon-probability of failure multiplied N times), you would generally expect more vs. less effective techniques to have multiplicatively greater or fewer steps until failure, not additively greater/fewer. Figure 1 is comical, but the appendix figure is the more scientifically appropriate one.
I think an important thing to note is the MCP client is a distinct thing from the ‘LLM’ architecturally, though many LLM providers also have MCP client implementations (via their chat ui or desktop / cli implementations).
In general, I’d say it’s not a good idea to pass bearer tokens to the LLM provider and keep that to the MCP client. But your client has to be interoperable with the MCP server at the auth level, which is flakey at the moment across the ecosystem of generic MCP clients and servers as noted.
This is true, but sadly the customer isn’t always the user and thus nonsensical products (now powered by AI!) continue to sell instead of being displaced quickly by something better.
Even if it’s only 1 sentence per room (it’s not), that’s still 4000 sentences. I’d guess this is at least a few hundred pages of written work (without downloading it and just based on what you’ve shared). That seems pretty substantial to me.
Not sure what the length has to do with handcraftedness though. This comment is handcrafted even if it is short.
Going by the sample rooms above, (27, 21, 24, 28, 27) words multiplied by 4000 rooms divided by 350–450 words per page yields 200–300 pages indeed. But if it's mainly exposition and not interactable I can see how it would become dull reading quickly.
The first program I ever wrote was a choose your own adventure, I think written on my family’s IBM PC jr in Basic. It’s pretty amazing how far a kid can get with GOTO statements and a lot of patience. But for some reason I couldn’t (or didn’t know how to) save it, so I’d work on it all day, have my sister and mom play it, and then shut off the computer thus losing my days work.
Or at least, that’s how I remember it. It’s been a good 40 years though and I wouldn’t be surprised if reality was quite a bit different.
Edit: I’ve been thinking about this a bit and honestly my motivation for writing software hasn’t really changed. The users, sure, but not the motivation. It’s just thrilling to share things I built with other people.
When I was first introduced to BASIC in elementary school, I was spending a lazy afternoon reading in the built-in QBasic docs (being able to hit F1 and get immediate help is still one of the coolest things ever IMHO) about the SOUND keyword, which let you set a frequency and duration.
I remember irritating the hell out of my parents (and our dog) with it until one day, by accident, I noticed they couldn’t hear the tone anymore. The frequency was somewhere in the range of 15-20 kHz IIRC.
So I wrote a “PASSWORD.BAS” source that would play that high pitched sound in short, one-tick intervals continuously while polling the keyboard for input but then stop after a random amount of time. To authenticate, the user had to hit the spacebar within a one second window of the sound’s termination. Hitting the spacebar too early would also result in access denied. Fun times!
I used to mess with sound on my commodore 64. 3 voices. ASDR. Square, sine, triangle. Chords were frequencies with common factors. The world of strange sounds is vast.
Nice! I still love that one of the ways that C64 composers worked around the limitations of 3 independent sound channels was to use a single voice to simulate a chord by playing the triad of notes in an continual extremely rapid arpeggiation.
Incidentally, if you're ever interested in playing around with one again, there's a really accurate VST emulator called Chipsynth C64 [1].
I made some text adventures in elementary school on the school's Apple II machines in the early 80's after playing Scott Adams' games (as a side note, it was amazing to be able to tell him directly many years later how much he influenced my learning to program). Anyway, a few years after I graduated from the school, I went back to visit, and some kids figured out it was me who's adventures they'd been playing and asked how to get past the one point in one that they couldn't figure out. I had to tell them, much to their disappointment, that I hadn't actually finished that game.
When I was in Jr. High, we had an Atari 400. Mostly I used it to play Missile Command and Star Raiders, but it also came with a BASIC cartridge.
In the back of the manual were four BASIC programs. The first three were very simple, stuff like a loop that prints your name 10 times and then exits.
The last program balanced your checkbook. It was 4 pages long. I laboriously typed it in, hunt-and-peck style, which took hours... then I hit "run".
Nothing.
I couldn't debug it. Not only did I not really understand software, I didn't have a checkbook — hell I didn't even know what "balance your checkbook" meant.
We didn't have the exorbitantly expensive Atari floppy disk drive, nor the cassette drive, so I couldn't save my work. Still, I left that BASIC cartridge in there for several days, foregoing my games, because I didn't want to lose my investment.
Eventually, I turned off the computer and the program disappeared forever.
In my experience, a core skill of programmers is that they are people who are able to deal with setbacks and frustration in a good way. Those come with the territory.
I've always wondered if there is a correlation between developers and people that can enjoy tough but fair games like Super Meat Boy because of this.
Hmm, I’ve had a highly successful career in software despite getting derailed and starting late, so maybe not the best example haha.
I agree that resilience is important, but in my experience it emerges from a complex mix of temperament, environment, structural advantages, and mentoring, rather than being intrinsic to the individual. For illustration: I’ve trained a bunch of people from nothing on software and I always prioritized helping them find a project they cared about, because that motivation was what would power the through the inevitable frustrations.
Maybe if the Atari manual had taught me how to write a branching adventure game rather than a checkbook-balancing program, I would have stuck with programming back then. But I’m not dissatisfied with the path my life took.
Similar background here. The public library had Apple II machines and I became quite enamored with making proto-text adventures in Applesoft BASIC. Because you had to sign-up for time I wrote a lot of my programs longhand on nth generation photocopies of "program template" sheets that they handed out at the library (lined paper with columns for line numbers, statements, comments, etc).
The spaghetti code was astounding, and I remember squeezing line numbers between existing code-- adding a "31 GOTO 40" so I could squeeze a "room" into lines 32-39.
I never did grok the idea of building an "engine". Mostly I had PRINTs, INPUTs, and IF/GOTOs.
One of the most humbling moments in my life was learning from a friend what a object was, and how that differed from GOTO statements. I had already done something similar by inventing abstraction, when I figured out that I could pre-define certain musical notes and then use those defined notes more simply in my BASIC code. I had not, however, made the leap between re-using notes and re-using rooms in a text adventure. That realization that all re-used things can be abstracted was formative, and I am very thankful to my friend for having explained what he was doing with rooms. At some level, I regret that I learned BASIC before an object-oriented language; at another, I'm glad that I did, because my training in stupidity made very obvious to me my shortcoming in logic when I learned a better way.
By the time I was a kid, most of the x86 computers I was exposed to were running DOS with the included QBasic IDE so I never had to worry about things like this.
However, we had old stacks of Compute magazine [1] lying around with BASIC source games printed out - and I remember initially being confused as to why all the line numbers were separated by intervals of 10...
>The spaghetti code was astounding, and I remember squeezing line numbers between existing code-- adding a "31 GOTO 40" so I could squeeze a "room" into lines 32-39.
I spent too many nights trying to implement complex text adventures in Commodore 64 Basic and I'm sure that instead of permanently damaging me (at least in the sense that Dijkstra meant) it just made me appreciate more all the abstractions later languages introduced to me.
Love it! It really is a good first program to write as a kid (at least those from a certain generation).
And my memory might be from our Apple 2gs and AppleScript, actually (hence my caveat in the comment). But I’m sure the program was just PRINTs, INPUTs, IFs and GOTOs :)
I made a game in the 80s in my Commodore 128, was a super rudimentary maze, you moved the sprite and need to reach the center of the maze. That was it. It was very basic, but I was proud and showed it to some folks. I'd love to see the code and game now.
It was the same for me, except I grew up slightly later and did it with HTML documents and hyperlinks! (And in one case, I even think I got some help with an imagemap. Clicking the little hole in the foundation to the house led to an easter egg.)
I got into coding at home when I realized ctrl-break gave me a BASIC command prompt on my Apple //c. It was really cool, and I spent a lot of time learning to code. There was one small problem: doing so on startup meant I didn't get a DOS. In other words, every program I wrote like that meant I couldn't keep it.
I eventually learned to get a ProDOS disk setup, and save my work, but it was still fun.
I think my shirts just automatically get inside-outted
in my washer/dryer? I certainly don’t put them in that way, and it seems like I spend a lot of righting them when putting away laundry.
Netscape 4 was the bane of my existence, moreso than IE6 ever was, as an important client standardized internally on that forever so our entire platform had to be completely compatible with it. At least with IE you could do things in a user friendly way (perhaps at 2x the development and maintenance cost). Netscape 4 simply didn’t have the capability to do things we wanted to do experience-wise (like getting pushed content, I think?) without doing some extremely crazy and brittle workarounds at best (making it feel more like 5x the cost).
Also, IE4 was such a magnificent leap forward in the web that effectively enabled support for modern apps, which bought IE a ton of goodwill from me that didn’t wear off for a decade or so.
agreed*. You often hear this assumption today that Netscape was always the better browser and that people using IE were simply making a mistake. If anything they were just shit in different ways. For a while Netscape refused to implement CSS and wanted people to use their own JavaScript Style Sheets https://en.wikipedia.org/wiki/JavaScript_Style_Sheets technology which no-one did.
Well I lived through it, and you are absolutely right. Netscape 4 was terrible. Internet Explorer was much better and more standards compliant in comparison. Netscape 4 was hated by web designers just like IE6 later came to be hated. The difference was that Netscapes marked share dwindled pretty fast, while IE6 lived on for an eternity.
Exactly, and in my sad and unfortunate case I had to support it because of that one stubborn client, even though the rest of the world moved on. Actually, it might have just been their CEO accessing the site from his home machine or something?
Oh, what the heck, it’s been 20 years. Vertex Pharmaceuticals: shame on you. In the mid-2000s you had very poor taste in browsers ;-)
> The issue isn’t that the bathtub curve is wrong—it’s that it’s incomplete.
Well, yeah. The bathtub curve is a simplified model that is ‘wrong’, but it is also a very useful concept regarding time to failure (with some pretty big and obvious caveats) that you can broadly apply to many manufactured things.
Just like Newtonian physics breaks down when you get closer to the speed of light, the bathtub curve breaks down when you introduce firmware into the mix or create dependencies between units so they can fail together.
I know the article mentions these things, and I hate to be pedantic, but the bathtub curve is still a useful construct and is alive and well. Just use it properly.
David Byrne is currently on tour and my wife took me to the show as a bit of a backup plan (her usual concert-going friends fell through). I think concerts are okay, but I usually get bored after awhile, which is why I serve as a backup guest. I’m much more of a visual person, I suppose.
I was unprepared for how wonderful the show was. I was quite literally tearing up during the very first song from the beauty of the visuals that accompanied the musical performance, and it maintained almost that level for the entire show.
reply