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
If the agent is at least reasonably good at your language, the errors that are getting caught at compile time in a language with reasonably expressive types like Swift should be actually catching and eliminating bugs without having the run anything. It seems like the ceiling of how long an iteration takes would be lower, but the floor would be a lot higher, and then you're making a bet that the number of iterations needed won't be so high that it takes more time overall to get things working, which doesn't strike me as obviously true (and that's not getting into how fast the final product will be when the agent is finished, although both Lua and Swift seem like they're most heavily used in domains where you don't really have an alternative choice, so it's not easy to really compare these anyhow)
> 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
Ideally you'd want both. In this case though, if you're paying per token you'd prefer the typed language, since compiler invocations are presumably less expensive. So the interactive compilation strategy where it has to continually consume compiler output and run inference on it is going to be more expensive than letting the compiler do what it's good at. (I wonder at what point that math would invert and what would happen if it did.)
That's why something like Teal is perfect for AI, to answer the original question of "why this when there's AI now?" You'd want to add types to Lua to check what you can beforehand precisely because it helps give you the best of both worlds.
I started adding support for iPhone Duo in some of my apps. Here's an example of some of the work required https://mastodon.social/@simsaens/117296064810231465 — all my apps are hobby apps. Even though they all support iPad / resizability, it's still a large amount of work
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 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"
For me, it's that AI writing is always trying to be clever for every single point it makes (and constantly uses the same language patterns when doing so).
Its like listening to an insufferable clever dick, who is not as bright as they think they are. You would also find it incredibly irritating if a human talked like that
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…
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.
Unless… they’re not putting SIM cards in modern TVs or anything right?
reply