Paul Haddad 
ObjC is so hard to read!!! Meanwhile…
I'm stuck in Swift land for at least the next week, so expect a lot of moaning and groaning. There's for sure some parts that I like about it, if they had a version with maybe 1/4 of the features (i.e. needless complexity) I might actually say I'd enjoy using it.
Yesterday's Swift week highlight was spending at least an hour trying to find the right annotations to tell the compiler/concurrency stuff what a couple methods do threading wise. Turns out I had the right combo from the get go but it’s broken in both Xcode 26.2/4 and fixed in the .5 beta. Couldn't tell in older Xcodes because Apple blocks old Xcodes from running in current OSes for "reasons”.
Swift's concurrency approach is emblematic of its complete lack of pragmatism. Runtime sees hey I think this code is running in the wrong thread (or context if you must) what do I do? Warn and ignore, because it's probably OK 99% of the time, nope. Warn and correct, because you have enough info to infer what is probably needed, nope. How about crash 100% of the time, yep, that's the one.
Steve Tibbett@paul There are domains where you probably want that (kernel stuff, secure code) and domains where leniency would be better. But Swift is everywhere.
@stevex 100% and even times where you want it (debugging) and times when you don't (AppStore).
Frank Reiff@paul they reason about (other) developers like this: if they were any good they would be writing the swift core. So how do we force them to address their concurrency problems? Make it crash. They’ll have to sort it out then. It’s not pragmatism they lack, it’s an excess of self righteous arrogance. It’s just a bunch of language nerds who never build anything.
Timothy Wood@paul “warn and ignore” will get ignored by nearly every developer even those with good intentions (especially with the spam factory that is revealed in Console.app). Not sure if "warn and correct" is feasible, you'd know better than me since I nope’d out. Crashing unambiguously is almost always the best option since the developer can more easily find and fix the issue. As annoying as it is, it's 1000x better than some very rare bug that can't be reproduced and only manifests visibly minutes or hours after the problem and potentially corrupts user data along the way.