Pedantic pet peeve: the past tense of “lead” as in “leader” is "led". NOT "LEAD". Lead is a metal. “When Curiosity Lead the Way” is a nonsensical phrase.
There were also mistakes in using “it’s” instead of “its”.
But these things are ignored by most people anyway. I guess my problem with the article is that it’s a bit confusing. It started talking about people not being curious and using tech they hate, then later he’s annoyed that people like to experiment and tinker with new frameworks. Then later it’s talking about some other thing, and there doesn’t seem to be anything tying all of the author’s complaints. As if it’s just a freestyle rambling instead of trying to get to a point.
This drives me crazy, too, but it seems like the misspelled version is now more common than the correct one. I imagine the dictionaries will eventually cave to common usage and say both versions are correct, and I'll remain bitter about it for the rest of my days.
An enthusiastic and muddle-headed person might get inspired by disposable Internet chatter, and then go and get themselves sent to federal prison (or worse).
Also, I suspect that an attack like that would only justify (or be used as a pretext for) additional actions that are undesirable to the perpetrator.
Maybe best not to even reply to such jokes. An enthusiastic and muddle-headed person might be a contrarian and might get challenged by disposable Internet chatter to not do something and still do that and get themselves in trouble. Staying silent is the timeless strategy of having no effect on the world
PSA: Things have indeed gotten pretty bad, which is also why were are discussing tech to detect (and some are discussing the possibility of countering) elements of the forces doing the disappearances.
Is running a fake cell tower technically against FCC regulations? Any possibility of just reporting them to the FCC and causing them to incur fines or take them down?
The people at FCC are just government officials. They'd be foolish to antagonize the leadership of the executive branch based on just principles (I know how unscrupulous this sounds. But such are times). Besides, they are up against one of the most heavily funded rogue forces in the world that is also known to go after people outside their jurisdiction (citizens) with impunity.
Likewise. This sort of manager would immediately trigger my instinct to "manage up" and start documenting every scrap of communication as they're likely to have an unrealistic understanding of current capabilities and will over-promise deliverables.
Sounds like the typical know it all, drives the thing into the ground while not re questioning either the why or the how, then attempts to scapegoat the team and try to save their own skin.
Swift is in the process of fixing this, but it’s a slow and painful transition; there’s an awful lot of unsafe code in the wild that wasn’t unsafe until recently.
Swift 6 is only painful if you wrote a ton of terrible Swift 5, and even then Swift 5 has had modes where you could gracefully adopt the Swift 6 safety mechanisms for a long time (years?)
~130k LoC Swift app was converted from 5 -> 6 for us in about 3 days.
Yes and no, our app is considerably larger than 130k LoC. While we’ve migrated some modules there are some parts that do a lot of multithreaded work that we probably will never migrate because they’d need to essentially be rewritten and the tradeoff isn’t really worth it for us.
It's also painful if you wrote good Swift 5 code but now suddenly you need to closely follow Apple's progress on porting their own frameworks, filling your code base with #if and control flow just to make the compiler happy.
It is still incomplete and a mess. I don't think they thought through the actual main cases Swift is used for (ios apps), and built a hypothetical generic way which is failing on most clients.
Hence lots of workarounds, and ways to get around it (The actor system). The isolated/nonisolated types are a bit contrived and causing real productivity loss, when the old way was really just 'everything ui in main thread, everything that takes time, use a dispatch queue, and call main when done'.
Swift is strating to look more like old java beans. (if you are old enough to remember this, most swift developers are too young). Doing some of the same mistakes.
Anyways, they are trying to reinvent 'safe concurrency' while almost throwing the baby with the bathwater, and making swift even more complex and harder to get into.
There is ways to go. For simple apps, the new concurrency is easy to adopt. But for anything that is less than trivial, it becomes a lot of work, to the point that it might not make it worth it.
Their goal was always to be able to evolve to the point of being able fully replace C, Objective-C and C++ with Swift, it has been on their documentation and plenty of WWDC sessions since the early days.
You're getting downvoted but I fully agree. The problem with Swift's safety has now moved to the tooling. While your code doesn't fail so often at runtime (still does, because the underlying system SDKs are not all migrated), the compiler itself often fails. Even the latest developer snapshot with Swift 6.2 it's quite easy to make it panic with just... "weird syntax".
A much bigger problem I think are the way concurrency settings are provided via flags. It's no longer possible to know what a piece of code does without knowing the exact build settings. For example, depending on Xcode project flags, a snippet may always run on the main loop, or not at all or on a dedicated actor all together.
A piece of code in a library (SPM) can build just fine in one project but fail to build in another project due to concurrency settings. The amount of overhead makes this very much unusable in a production / high pressure environment.
One of the biggest hurdles is just getting all the iOS/macOS/etc APIs up to speed with the thread safety improvements. It won’t make refactoring all that application code any easier, but as things stand even if you’ve done that, you’re going to run into problems anywhere your code makes contact with UI code because there’s a lot of AppKit and UIKit that have yet to make the transition.
I was in the same boat for many years (as in, my whole 35 year life), and today I still hate “coffee-flavored” stuff. But one day I was really tired and had to get stuff done, and asked for a recommendation for a coffee drink for someone who doesn’t like coffee. The suggestion was a vanilla latte. Fast forward a year and a half, and now I drink coffee almost every day.
If you haven’t given that or a caramel macchiato a try, I’d highly recommend it. You might be surprised. I was.
I have. I can tolerate them. But I still don't like them, and most places that serve coffee also have tea which I can drink without having to add large amounts of something to mask the flavor.
Just a quick shout-out; I was one of the many many students you taught at Lambda School, and just wanted to say your instruction was one of the highlights of my time there. Thanks for doing what you do!
