David Vaughn

@theo But what if I cancelled a long time ago lol.

For every person who replies with a screenshot of their cancelled Claude Code plan, I will donate $10 to open source.

Okay, gotta admit, gpt 5.5 plus kimi 2.6 make a great combo for refactoring old patterns to new ones at a fairly large scale.

@unclebobmartin So, why not code it yourself and not take the risk of dying a highly combustable death?

When a pilot flies in clear air with an unobstructed view of the horizon they can use Visual Flight Rules. No instruments necessary. You just fly because you can see. When a pilot flies in the clouds where there is no view of the horizon they must use Instrument Flight Rule (or they die within a few seconds). This requires a lot of specialized training and an intense amount of discipline. Things happen fast as you approach an airport and you have GOT TO BE ON YOUR GAME. Programming with Agents is like flying under IFR. You can't see. But you trust your instruments and you are disciplined as hell (if you want to live).

@lisyarus Do you have a name for the game yet? (awesome progress btw!!!)

Added some more entity spawning options, e.g. an entity prefers to spawn near fresh water (like a river). Now willow trees hang out on river banks! ☺️ (also, yes, everybody guessed right: these are weeping willows) #indiedev #gamedev #indiegames

@htmx_org But I also don't want hype bros destroying the industry either.

@htmx_org I don't have an issue with them doing it either, I was more commenting on the fact that you have to put in the work which often requires passion in order to achieve mastery.

seeing a big miss in most discussions around AI, mainly by good seniors: "I don't write code anymore." yeah, you read the code & you rely on years of experience writing the code to ensure the code is sane we have to have a spot for juniors to get that! maybe that's the unis?

@rfleury 100%

I'd like programmers to retire the "isn't this just reinventing ?" responses. Nobody has read every Wikipedia article. Nobody agrees on every piece of terminology. Reinvention is a good & necessary thing, because it renews, updates, and clarifies ideas. It's also admirable, because it means that someone discovered something important without it being told to them already. That is a much more valuable trait than memorizing terminology and facts.

@rfleury Gosh this is such a good post!!!! Had no idea.

"The stack" is a per-thread address space range, dynamically reserved by a kernel when a thread is created. The reason why "stack" is often presented as preferable to "heap" is that, when using a thread's stack, the expensive part of allocation - address space reservation, and preparation of physical pages for backing the address space - has already been performed when the thread was created. But kernels also provide mechanisms for doing your own address space reservation (mmap, VirtualAlloc), and there is nothing stopping you from using these to do bulk allocations up-front to create your own stacks. This can make common case allocations as cheap as "the stack", but the advantage is that you now control the semantics and lifetime of the stack you've created. Thus, it does not need to be coupled to - for example - the lifetime of a scope or function, as the thread stack is. The "stack versus heap" dichotomy is an unfortunate mythology because it seems to, in practice, communicate the idea that when a thread stack is insufficient for some purpose (allocations must exceed scope boundaries, allocations may need to exceed thread stack limits, allocations require more fine-tuned reserve/commit behavior, and so on), then the only alternative is the heap, particularly for very granular allocations. This is, again, a mythology, and it has confused the C++ world in particular for decades.

@htmx_org Please do!

next year I'm doing CSCI 431: Hypermedia System and we are going to build web apps from sockets up: HTTP, building a router, switching to a routing library, implementing auth, etc. I will try to post it online if the Uni will allow me.

@GbellOz @esrtweet I'll take any help I can get haha! Thank you for the rec.

@davidvaughn006 @esrtweet You didn't ask me, but Haskell (super different, but I never made it to competency) or Elm.

Choice of language for software projects has become a very different game now that we have robot friends to do most of our code generation and translation for us. I have people wondering why I just shipped a project in Rust when I don't like the language and don't hand-code in it myself. I did this because I am adjusted to current reality, and now I'm going to talk about that. The age of hand-coding is mostly over. It no longer matters as much whether the computer language I use is comfortable to my hand, only whether the robot friend I'm using can generate it at high quality. It also matters whether I can read the language, because I am going to want to run my eyeball over it to review the code. Rust meets that bar - I find it kind of spiky but basically readable. Rust is a good deployment language for me to choose when (a) I want solid memory-safety guarantees, and (b) the code is already mature and I don't expect to need to do exploratory programming or serious feature development on it in the future. In particular, this makes Rust a good place for me to land my old C projects. Which is why in the last couple of months I have migrated two of them to Rust. C to Rust translation by robots is cheap and easy now; I will probably continue to do this. Each time I get a bug report on one of these projects in the future, boing! Rusticated. You may believe that Rustacea is stuffed with Communists and sexual deviants. You might even be right. I don't have to care whether that's true anymore, because I have a robot friend who is in all relevant ways smarter than they are. The wider lesson here is that the developer and user community around a language doesn't matter as much as it used to in whether you should get involved with it. Because in the future, we're going to be relying on human community brains less and artificial intelligences more. And that future is now. Not everything C gets moved to Rust, though. I lifted cvs-fast-export to Golang instead, because I think it's fairly likely that I'm going to have to do significant development work on it is in the future, so the payoff from a language I'm more comfortable reading and modifying by hand goes up. I'm certainly never going to start a project in C again. What would be the point, other than masochism? I spent 40 years writing C and I'm very good at it, but I will cheerfully leave it and it's buffer overruns and its heap corruption and its undefined behaviors and its portability problems behind. It helps that my robot friends are good at writing C code that doesn't have those problems, but...why even go there? Why expose yourself to those risks if the robot misses something? These days I do my exploratory programming in Python or Golang. My robot friends are extremely good at generating code in both those languages. I think they're slightly higher leverage on Golang, possibly due to that language having a smaller surface? Python used to be my favorite language. I soured on it for a while after the 2-to-3 transition was massively botched, and the GIL meant concurrency in it was a disaster area, and managing library dependencies became an even bigger disaster area. I'm a little happier with Python now that I can declare strict typing and uv has reduced dependency pain somewhat. But I think if I think I'm going to have to write anything much larger than a glue script in Python, I just shrug and reach for Golang instead. I'm very comfortable in Golang. Over time, I'll probably migrate my older Python projects to Golang because that's cheap and easy now and the performance win can be quite significant. I don't know what other languages I'm going to be using in the future. I do know that choosing a development language is a much less grave commitment than it used to be, because if it turns out to be not well suited for the job I'm doing, I can simply have my robot friend translated to a better one.

@SpencerKlavan @ThePrimeagen

Tapping the sign

@pnpmjs be great if the community could rally around practices like github.com/lirantal/npm-s…

@unclebobmartin Where does a pattern like dynamic dispatch with mediator fit in your description of clean architecture with interactor input boundaries and output boundaries? Would you say there is a use case for intra-vertical slice for message based processing? (web dev)

@pnpmjs @0xkiboo Sweet

@0xkiboo @davidvaughn006 you can add frozenLockfile: true to pnpm-workspace.yaml

Is there anything else we can/should do on the client side to mitigate supply chain attacks?

@0xkiboo @pnpmjs Didn't realize I'd been yolo'ing this whole time with pnpm i 🤦‍♂️

@davidvaughn006 @pnpmjs you need to use pnpm install —frozen-lockfile like that it will install exactly the versions of all dependencies and transitive dependencies listed in the lock file

@esrtweet When I wrote my first compiler, it blew my mind the relation I saw between lisp and a sensible AST representation.

@davidvaughn006 Lisp is an excellent one to start with.

@esrtweet Been through SICP once. I need to go back through. Definitely changed my perspective on writing programs 4evr. I keep wanting to get into Clojure, but I haven't had time to invest in the Java platform recently.

@esrtweet What languages do you think are the best to engage in for the sake of expanding the mind? (I have a small one so any help is appreciated lol)

@davidvaughn006 Yes, I do, but that's a completely different direction of discussion than how to choose languages for particular projects.