kajkojednojajko

It's uncanny that they picked the term "Corps", which is exactly what Kurt Vonnegut used for the "Reconstruction and Reclamation Corps" in his 1952 novel, Player Piano. Also known as "Reeks and Wrecks" in the book, it's one of the two career paths, aside from joining the Army, for the workers displaced by machines and artificial intelligence. The irony seems to be lost on Anthropic.

I enjoyed Vonnegut's Cat's Cradle very much, so I've been slowly reading my way through his earlier works, and while his first novel is not as entertaining, it's surprisingly relevant today. There's Vonnegut's prescience about the impact of technology on society, of course, but even the description of a corporate retreat in the book, that he wrote with almost 75 years ago, hits too close to home.

I love this idea! I'll try it today.

This resonates with me because I've been looking for a way to detect when I would make a different decision than the LLM. These divergence points generally happen because I'm thinking about future changes as I code, and the LLM just needs to pick something to make progress.

Prompts like "list your assumptions and do not write any code yet" help during planning. I've been experimenting with "list the decisions you've made during implementation that were not established upfront in the plan" after it makes a change, before I review it, because when eyeballing the diff alone, I often miss subtle decisions.

Thanks for sharing the suggestion to slow it down and walk the forking path with the LLM :)

I enjoyed playing Teardown when it first came out. It was already a technological marvel back then, so it's even more impressive that they managed to make the simulation deterministic to add multiplayer several years after release. Clearly top tier engineers.

Cool to see that the game is owned by Coffee Stain now, too. Satisfactory has been handled well by them, so I'm optimistic about the future of Teardown as well.

There's a neat mental model that there are four kinds of documentation: tutorials, how-to guides, explanation, and reference.

I think that examples fit into the first or the second kind; I'm not too concerned which category they belong to, because the point is that all kinds all have their place.

Source: https://docs.divio.com/documentation-system/ - someone has already linked it in another comment, but I think it's worth replying because the comments in this thread are arguing about which kind they like the most.

kurzgesagt has an awesome video on this topic: https://www.youtube.com/watch?v=dKm7T13X7n4

the most important thing I've learned about [bash] is: don't. Sure, it can be done, and even done well, but why? There are better languages.

This. Bash gives you all the tools to dig a hole and none to climb out. It's quick and easy to copy commands from your terminal to a file, and it beats not saving them at all.

Support for digging: once you have a shell script, adding one more line conditioned on some env var is more pragmatic than rewriting the script in another language. Apply mathematical induction to grow the script to 1000 lines. Split into multiple files when one becomes too large and repeat.

Missing support for climbing out: janky functions, no modules, user types, or tests; no debugger and no standard library. I've successfully refactored messy python code in the past, but with bash I've had no idea where to even start.

There is hope that LLMs can be used to convert shell scripts to other languages, because they can make the jump that experienced devs have learned to avoid: rewriting from scratch. What else do you do when refactoring in small steps is not feasible?

please do the promptful

Insane deep-dive! Framing texture sampling as "Ideally, we’d like to integrate over the projection of the screen pixel onto the texture" was enlightening for me. I particularly enjoyed the explanation of anisotropic filtering because it always seemed like magic to me, and in the context of aligning ellipses on textures it just makes sense :D

Me: I couldn't write anything longer than 20 lines in make - there's just one type (string), no debugger, no data structures, no standard library, and not even modules.

Buildroot developers: let's write a build system in make!

SmarterEveryDay has a great video with astronauts training in this fashion: https://www.youtube.com/watch?v=AiZd5yBWvYY

I love the fact that he records voiceovers of his articles! I listen to podcasts on a regular basis, and this substitutes for podcast perfectly: it's shorter, but 10x higher quality.

There's always the source :) It's easier to follow if you git clone and open it in vscode. Here's Main::iteration - https://github.com/godotengine/godot/blob/e0f644a48da49843ad...