Patrick Smith @patrickgwsmith

@rfleury Look at what people can create with pixel shaders, that are really just a mathematical formula, to see how true this is. Constraints help you stay close to the zero point so you don’t wander off into the wilderness.

@cramforce Which city? That doesn’t look like where I live in Melbourne, so I’m guessing Sydney?

@noio_games youtu.be/heZFx8WRKac

The natural progression of React is to take it even further and do real immediate mode. HTML-in-canvas is the key to that. That will then have upstream effects where state management can be simpler and not need things like fine grained observability or fancy compilers to make it fast. And we can focus on the immovable hard parts of web development like syncing and distributed system problems. We need to use the DOM what it is good for but not default to it for everything. That’s what’s holding React and all it’s would be successors back: it’s trying to find the best state system for managing a retained object graph and it would be best if we really took ui = f(state) literally instead of trying to optimize it.

@MichaelArnaldi What about a bridge factory? en.wikipedia.org/wiki/George_C.…

Constraints help you stay close to the zero point so you don’t wander off into the wilderness. youtu.be/_mnLsSbuC6k

I used to think I was fairly clever because I knew how to code. Then a decade ago I taught a coding bootcamp and discovered that pretty much anyone can learn to code. It wasn’t even hard to make a working app! On reflection the main thing my students struggled with was managing complexity. They didn’t have strong opinions on how to architect things and where to place boundaries within a system. They’d carry around books like “Clean Code” hoping it would tell them the secrets to writing “good” code. I tried to stay away from being too opinionated about what “good” was because I felt much of it was dogma and I wanted students to feel good about whatever code they were writing so they’d keep up momentum. It’s through experience that you built your most meaningful sense of taste. Now we have coding agents that really make coding easy and can give you a working app in minutes. They do this by producing reams of code, probably at a faster pace than even a classroom of 30 students! Yet is producing countless lines of code actually helpful? How many different ways can the working code stop working? The more code, the more bugs are present (they are usually appear around a constant rate per line of code), and the more context has to be uploaded back-and-forth to cloud LLMs. This leads to more latency during agentic coding sessions and prolonged rounds of code review even if you automated it with AI: the more code, the more issues the reviewer AI will find, the more commits have to be made, the more rounds of continuous integration have to be run, and then because LLMs are probabilistic even Fable will keep finding novel issues it missed before and round it goes more times than a heavy-duty cycle of a washing machine. The struggle still seems to be in managing complexity. The proven methods I’ve found are in seeking constraints: finding simplifications in the user experience, removing moving parts and state from the backend, making the frontend that sits in the middle between user and system-of-record out of as basic parts as possible. It’s not in hastily adopting the latest framework that promises to solve everything (and more!), it’s not in some new AI tool that promises to solve planning, project management, code review, and user feedback in a supersystem of central planning that would make the Soviet Union blush. Instead hit the minus button and zoom out and research what’s necessary and what’s not. And then build well only what you decide is necessary. The brilliant thing is AI tools can help research what’s necessary! I love ping-ponging back with ChatGPT to explore the many different angles for a concept, referencing prior art or knowledge about competitors. Or with Codex and simmering a solution down to a high concentrated form, evaporating what’s slow or extraneous. People pay for software because they want to solve a problem they have, and it’s preferable to them if it reduces the complexity of that problem along the way. We help users manage complexity in their lives, and the best avenue is by reducing complexity in what we make for them.

@housecor Curious how deploy frequency benefits customers in your mind?

@thdxr unknown is what any should have been

@RyanCarniato Do you find Fable ever dialled down at busy times? Or it’s pretty consistent in its quality?

@davepl1968 Sandboxing continues to suck on the Mac. I made a project file manager Mac app and the sandboxing was by far the most painful part. I understand the need for isolation but they’ve just bolted on a system in a quite-un-Mac-like way. It needs to be redesigned IMO.

how shaders work- using Excel =LET(x,(COLUMN()-24)/15,y,(ROW()-15)/15,SIN(SQRT(x*x+y*y)*10-t)) Each cell (pixel) computes its colour just from its coordinates- so the GPU can massively parallelise them. The trick is writing the formula to draw the picture you want

@sebastienlorber @jaworek3211 Holy moly that is a big week!

@MichaelArnaldi @mitsuhiko The advantages are speed? Correctness?

“Composability limits complexity” is super interesting to me. I’m working on WebAssembly tools and I’m breaking everything into wasm components that pipeline together like the unix philosophy (previous output pipes into next input). Because of this constraint I can share memory. Each tool in a pipeline must use fixed memory, and I can max() each memory and allocate that in a single buffer that is reused between each step in the pipeline. The constraints allow an optimisation like that. I know the memory and runtime of each wasm component is finite and I can then take advantage of that in the next layer above.

@SahilBloom Intelligence is multi dimensional. Much has to be learned. You have to forage for it. There will be lots of dead ends. Intelligence takes courage.

@__tinygrad__ And that’s why we should use coding agents to reduce complexity

@davepl1968 Could each cell fade, so instead of being able to go from fully-on-to-fully-off, it would go from 1.0 to 0.9 to 0.8 etc? You could record for each cell the last frame it was on, and then lerp() between the current frame n and that last active frame.

Code review has gotten so blown up in importance the past several years. We forget that code is mutable like wet clay, and isn’t permanent once merged. It’s been exacerbated because management doesn’t allow paying down tech debt. Rewriting is seen as a sin. So we have this window where many rewrites are actually allowed as long as it’s in a pull request. But once it’s merged it gains a higher status and must see out its tenure like an elite no one likes. We’ve got to stop micromanaging people and barraging them for making code better because “the ticket is closed”. Coding agents now make refactoring much cheaper. Trust the people who are experts in the medium. Encourage people to write code to a high standard, educate them on what that means (put days aside for training), give them tools that boost quality, and bias towards merging. Then review the code that’s in main as a group. Talk about patterns you like and don’t like, and what’s working about the chosen architecture. Don’t spend weeks creating style guides no one reads (not even your LLM), make main great and repeatedly put your focus there. And stop treating pull requests like you’re adding a chapter to the bible.

@BennettBuhner @theo I do the same, when we’ve made an edit I can turn into a rule, I ask Codex CLI to add it to AGENTS .md I also get it to prune anything that disagrees with what we’ve mentioned in the last session or the rest of the work