cloogshicer

Native iOS is significantly worse than SwiftKey and doesn't support multiple languages without having to switch the keyboard constantly. In SwiftKey you can mix languages.

I'd also be very interested in SwiftKey alternatives, since MS already almost killed it once.

I think that's a false dichotomy. The examples the author gives would not be slower in any way if done correctly.

This short video is the best response to what you wrote above:

https://youtu.be/q_Rqvd1ayUE

This attitude of "individual cases don't matter as long as the average case is somewhat covered" is exactly why the world's going to shit.

The parent post's worry is warranted, IMO.

What a reductive world view that is.

Super cool, thanks for explaining! Is the code available somewhere?

What an amazing article. I really like the presentation of text scrolling together with the code. Wonder how this is done under the hood.

But you have to know all of them to read other people's code.

To answer your question: I would immediately get rid of guard.

Also, I think the complexity and interplay of structs, classes, enums, protocols and now actors is staggering.

Could this be used for creating video editing software?

Imagine a Premiere plugin where you could say "remove all scenes containing cats" and it'll spit out an EDL (Edit Decision List) that you can still manually adjust.

Genuine question, will this actually give you the latest solid local model?

I would've thought no, because of the knowledge cutoff in whatever model you use to download it.

I think this could be very useful even for regular old programming. We could treat the diffs to the code as the main source of truth (instead of the textual snapshot each diff creates).

Jonathan Edwards (Subtext lang) has a lot of great research on this.

If you have a policy in place that forces engineers to wait for review before merging each PR, then yes, by definition they have less autonomy. It might still be worth the trade off in your situation, but I like the suggestion in the article where senior devs can decide themselves whether they want their code reviewed or not.

In the article, they specifically exclude juniors and people who are still being onboarded.

The author never suggested to eliminate code reviews entirely. Just to give individuals more autonomy, which is great in my book.

Your point of view is based on extreme reductionism.

I've had Claude Code write an entire unit/integration test suite in a few hours (300+ tests)

I'd love to see someone do this, or a similar task, live on stream. I always feel like an idiot when I read things like this because despite using Claude Code a lot I've never been able to get anything of that magnitude out of it that wasn't slop/completely unusable, to the point where I started to question if I hadn't been faster writing everything by hand.

Claiming that software is now 90% cheaper feels absurd to me and I'd love to understand better where this completely different worldview comes from. Am I using the tools incorrectly? Different domains/languages/ecosystems?

Thanks!

Genuine question, if you already own an Index, why would you also get this? Wireless functionality, or something else?

FYI, this crashes the tab in the latest iOS 18.5 Safari and Chrome.

There is a major difference at the call site.

try/catch has significantly more complex call sites because it affects control flow.

Thank you all for your recommendations!

Can someone point to a real life example or tutorial/guide of the ECS architecture he proposes?

I'd like to learn more about how to implement this.

The main cost isn't writing the tests themselves but the increased overall system complexity. And that never goes down.

I think what people really mean when they say "This can't be tested" is:

"The cost of writing these tests outweighs the benefit", which often is a valid argument, especially if you have to do major refactors that make the system overall more difficult to understand.

I do not agree with test zealots that argue that a more testable system is always also easier to understand, my experience has been the opposite.

Of course there are cases where this is still worth the trade-off, but it requires careful consideration.

It's "skill issue" or "git gud".

Thank you very much for the info!

Thanks for your response! Don't you lose the main advantage of the monorepo then, since you can no longer rely on the fact that all the code at any one commit in history fits together? Or are there other significant advantages that still remain?

Thank you for the response!

Genuine question: if you can't have one commit in production at any given time, what advantages for the monorepo remain?

Couldn't you just leave the other consumer at the old release (presumably well tested, stable)?

I don't see how being forced to upgrade all consumers is a good thing.

Thanks for the info!

Seems like a big restriction to me.