interpol_p

The main thing is getting feedback. I've been doing some intense agent iteration on Lua projects, and so long as the error output is clear and it's easy for the harness to restart/inspect/stream logs it seems to do very well with Lua

In fact, I'd say it's more "fun" watching an agent work on something in Lua as the iteration loop is tighter: more restarts, more feedback, instant running. When I deal with typed languages (in my case, Swift) the feedback loop is dragged-out by the compile time which makes the whole process feel slower

Me too! Best $1 I've ever spent

They used to support that. Isn’t possible to do unified memory in those configurations? If not, then I expect it’s a headache Apple does not want to deal with. For example, earlier versions of Metal have unified/discrete memory modes with different API availability and behaviour in each - what a nightmare to support and maintain and keep bugs out it would be

I've always used em-dash. I got familiar with the hotkeys when I started using Mac OS X in 2002. Option+Hyphen for en-dash, Option+Shift+Hyphen for em-dash. It's unfortunate that it's an LLM tell. I'm glad the LLMs haven't subsumed proper ellipses yet…

I stopped reading almost immediately. The stylistic choices in the writing just felt like LLM to me. Examples:

"depth estimation that beats PyTorch on CPU in half the memory" — "…beats X in Y…"

"Most LocalAI backends wrap somebody else’s engine, and that is the right default." — "…and that is the right"

"MLX and the rest are maintained by people who are better at those models than we are" — "better at those models than we are" — it's this thing that LLMs do where they are kind of weirdly confident but overly deferential

"This post is about what those ports buy" — "…buy" used in this context

"Same model, 1.31x the speed" — "Same X, something Y" — it's this overconfident yet deferential writing style

The further I read, the more tells there are. I find it incredibly tiring to read LLM generated prose and I'm not sure why. Is it because I'm aware it's not human written and have an unconscious bias? Or is it because the style is just full-on, "Not X but Y. Those performance gains are bought, not earned. This stops, that starts. Read on, or don't, that's the follow-up"

SwiftUI has a lot of failings, but it can also do a lot of things that are really tricky in UIKit.

I can render Metal shaders trivially in SwiftUI. Rendering glows, and blurs, and animated effects is much easier in SwiftUI than in UIKit, just use `.blur(radius:)` or `.blendMode(...)`

I have used AppKit and then UIKit since its inception. Creating visual effects like layer masks that modulate the opacity of underlying views is trivially easy in SwiftUI — far easier than the boilerplate and constant bookkeeping that CALayer's mask requires.

So a lot of the advanced full-screen animations in some of my games and apps are SwiftUI, because they are performant, provide the cool effects and animations, and work great. A lot of the simple get-the-job-done views and tool palettes in my apps are also SwiftUI, again because they don't ask much and get the job done, and look great.

However, where SwiftUI falls down is exactly what was demoed in the video: large collections of thumbnails that fetch asynchronously? Use UIKit. Multi-thousands of items in large, complicated lists? You can try SwiftUI, but you'll need to learn how to optimize it.

Other things, not mentioned in the video, that are more annoying in SwiftUI: want to take control of a transition between views, end-to-end? Not really possible in SwiftUI. There are bugs with ZoomNavigationTransition that affect all of Apple's own apps, and you aren't gonna be able to fix them without switching to UIKit.

It’s incredible some of the little details in LEGO instructions.

My son and I were assembling a set, and one of the corner pieces was strangely absent. My son asked, “why can’t we put this piece in yet?”

The answer came when we turned the page and saw the model had to be flipped. That missing corner piece was the only thing we could use to guide our placement of pieces on the underside of the model.

Similar things in more complex sets include using different, bright colours for bricks on the left/right sides of the internal parts of models. It makes it easy to keep your place as the model rotates through the steps.

Their docs seem entirely LLM written. It seems especially obvious in the FAQ. While I'm not against using LLMs for writing assistance, they've left a lot of the unnecessary language and typical stylistic choices in there, which erodes my trust in the project a bit. Perhaps it's a very good game-oriented version control system, but the lack of human attention on the docs makes me wonder how much they care