Notices by Rob Napier (cocoaphony@mastodon.social)

@whitequark I agree that today, coding assistants are broadly net-negative on productivity outside of some fairly simple and low-risk use cases, where they excel. I'm seeing value there already; things like report generation.

I think their future is the replacement of 3GLs for general purpose programming, but that will likely take at least years and possibly decades to occur (just like 3GLs did).

But today, I'm doing what I've always done. Experiment to see what works, and share what I find.

@whitequark The same reason I work on teams where we code review each others' work. Together we're faster and better than alone.

So far, getting AI to *write* good code has been challenging, but I'm learning how to use it better and so keep trying.

On the other hand, getting AI to *review* code well has been extremely easy, and it very often finds things I miss (and I find things it misses). It's a multiplier, not a replacement.

(Next experiments will probably be to have AI review AI code.)

I think people underestimate just how inefficient AI code (especially "vibe code") often is these days. Even with the latest Claude Sonnet 4, I need to be extremely explicit that it MUST stick to public APIs. It likes to guess at the API, and when it's wrong, rather than read the docs, it likes to add more and more "in case that failed, try this" logic. If it can find a hacky workaround based on internal details, it will use it, even if it's incredibly fragile and slow. You MUST code-review.

https://github.com/hxu296/tariff

@inthehands and I think when you go down that path a little further you work yourself into the current await semantics to achieve exactly that.

@inthehands think about whether logging is “mutable state.” (Then think about it again remembering that OSLogStore is readable.) That’s probably the best way to come to grips with the difficulty we always run into with defining “pure.”

Is generating random number legal in an async function if it modifies the RNG state? State is so pervasive.

@inthehands How is "non-local state mutation" statically defined in this story?

@nathanw @inthehands @mattia @dmarti This is something I quite like about Vanguard. They're not about these kinds of tricky derivatives.

Even so, I'm in for $5k TSLZ through Fidelity.

I lost $300 today.

In practice, I don't think it's incredibly effective. It indirectly funds short sellers, and once short sellers push a stock below its fundamentals, there's strong pressure for buyers to push the price back up.

But I think TSLA is way above its fundamentals. And I'm willing to make a point.

@inthehands @arroz hmmm. Hadn’t thought about the SSID specifically. I named my networks the same thing here as in Raleigh. I’m wondering if it’s put that into the database and it’ll stay locked for some time until it gets some data telling it it’s changed.

I'm having trouble getting macOS to update its current location. It still thinks I'm in North Carolina, even though I'm in Connecticut. Can't find GPS maybe? (Is there somewhere to see error messages for that?) My phone knows where I am, but two MacBooks, about 5 ft apart, both are having trouble updating location.

I'm at the "How does this ever work?" stage of debugging…

oh wow, yes, I just broke out one of my 30-pin connectors to charge up this iOS 5.1 iPad because I don't have any other iPads with large, unbroken screens handy…

Do I miss skeuomorphism?

Hmm…

Hmmmmmm…

Yes. Yes I do. We've fallen so far.

This really drives home something about LLM systems. They’re very expensive to run, both to train and per-query, and hard to make cheaper. I expect them to get more expensive to run. They’re currently sold at a big loss to establish monopoly power and then raise prices dramatically. That’s the *stated* business plan.

If you’re building your business to rely on LLM, you need to factor in what you‘ll do when they pivot to making money, or they pull back because they can’t.
https://geeknews.chat/@theregister/112116266764229145

Trying to get things to build in Xcode is infuriating, yes...

But have you tried getting things to build in Android Studio?

Also infuriating.

Fight all day with SwiftPM…

Turns out I also fight all day with Maven.

Maybe it's just our whole profession? I don't know… Good grief. How is it we ever ship software? Truly, we are heroes.

oh no. Seriously, while I was typing this post:

apk:dexBuilderBetaDebug -- java.lang.OutOfMemoryError: Java heap space

😭

A reminder: When that major security bug shows up in one of your dependencies, and you need to ship a fix right now, that's not the time to discover you're 3 years and 6 API-breaking changes behind the version that has the fix.

Upgrade your dependencies when you don't *have* to. That way, when it is critical, it will be fast and low-risk.

This is *especially* true about that risky upgrade you've been avoiding. Take the hit now when you can schedule it. Don't let others schedule it for you.

@mergesort @kylebshr @jsq and yet still, I can’t say 3 sentences about Swift concurrency without making 2 misstatements. Check the replies from @rjmccall and @justkwin who actually know what they’re talking about.

@justkwin @mergesort @kylebshr @jsq @rjmccall true for the community. But Apple is saying explicitly up on stage that it is “the best way to write apps.” So we’re kind of struggling. I’ve recently backed off my push in my team for “no more non-actor classes.” It turned out almost everything I tried to write required hours of research and no definite answer. So now it’s closer to “if you feel like doing the hard work of figuring it out, then it would be nice if you tried some async/await.”

@rjmccall @jsq @kylebshr @justkwin @mergesort I’ve been treating MainActor classes as just another kind of actor. (Maybe that’s confusing terminology?)

But in large programs, “just not sending between concurrent domains” sounds a lot like what we’ve been doing and failing to do correctly (and the problem actors are supposed to help).

How did I wind up writing C++ again?

@crazybutable @inthehands I've heard many devs say "I don't know how this feature will be used. It seems dumb, but the product managers are the ones who know the customer, so I have to do what they say."

My answer is always the same. It's our job to learn those things, and they're learnable. We may have different skills; Swift or SQL or graphic design or testing or analyzing user feedback. But every one of us is responsible for delighting our users, and we can only do that if we know them.