isaiah
i'm a software developer. primarily for macOS. primarily in Obj-C. primarily working on https://yourhead.com/stacks
but it hasn't always been that way. i used to write other software, in other languages. and before that i designed microchips.
in other personal news…
i was pointed to a foundation that hand weaves wigs for kids with cancer. they are always in need of hair donations.
they accept gray, but need hair that's never been colored or heat-damaged. and they need a full 12" from your whole head. not many qualify.
i have plenty to spare. mine's about 18" long. and it (annoyingly!) grows 6" a year. so i'll have a very temporary crew cut.
help me out here. i need to work up some nerve for a big chop.
(2 of 3-ish)
i've found (with Codex 5.3 and 5.4) that discussing architectural tradeoffs is immensely helpful.
in the past couple weeks i've been trying to wedge my proxy-objects implementation into the gap between my live objects and the rest of the lazily loaded project file chunks.
but it's fragile. breath on it and some corner case breaks down. finding those bugs is a nightmare.
but Codex not only understood my problematic code — but understood the larger problem too.
@stefanpauwels@mastodon.social @ctietze@mastodon.social @czottmann@norden.social
also: you might find my posts over the past week interesting. i gave Copilot, Codex, and Claude a head-to-head test: the same prompt, same setup/style prompts, and the same project in a clean repot. (Codex used GPT 5.4)
- short prompt
- easy to understand
- simply code. < 100 lines.
- but requires understanding of several overlapping AppKit protocols.
spoiler: none of the above. they all failed to build the feature — even with A LOT of hand-holding.
(3 of 4)
i didn't ask it to implement the change, but asked it to suggest alternative architectures.
in under a minute it was done alazying and made a very subtle change: add some specific info to my page manifests. that was enough to avoid proxying every archived object.
i had even considered this architecture — i already build similar manifests — so it's not a large change. i just hadn't really considered the broader implication and how much of the complexity it obviated.
i always find it a bit strange when building something akin to a component of an Apple app, but it isn’t really represented well by Foundation or Appkit. it feels like if Xcode finds it useful, then that would be useful to other Mac devs too — so a good component for Cocoa in general.
(1 of 3-ish)
i know i whine about using AI agents for coding too much. i find it frustrating most of the time — and posting about it is kind of cathartic. for many tasks it seems like i'm just dumping my time and money into a hole.
so, i'm trying to make a change here:
instead of more whining, here's something i've found it does insanely well…
basically what i want is Xcode’s xcuserdata. it’s not part of the project data per se — which is why most folks put it in their git ignore file — but it saves the state of that project the last time it was opened — even if you don’t explicitly change the project itself or change/save any source files.