This honestly just reads as “this model failed exactly where the company said it would but I’m very special and deserve special treatment rather than the same overactive guardrails I and everyone else were told we would get.”
I just think that Anthropic's usage of the word "classifier", which implies a minimum level of intelligence, was very misleading. Fact is, you cannot use Fable for anything remotely connected to even elementary school biology or medical topics. There is no attempt whatsoever to distinguish between legitimate and dangerous tasks, except an extremely broad and non-specific rejection of anything related to security or biology.
If you feed their "pure math" question to Fable, in its reasoning it rightly determines that it is the sort of thing you find in phylogenetics / algebraic-combinatorics complexity papers. That is what triggers the classifier.
Anthropic is 100% to blame for fear-mongering, but they said it would be blocked from any biology questions -- even high school level -- and they meant it. If the classifier sees anything related to biology, even in its own reasoning about the question, it blocks it.
Saying it's therefore not useful generally is of course ridiculous. Is it annoying? Of course it is.
The abstract problem absolutely has legitimate interpretations outside of phylogenetics, and there are other ways to formulate the problem that directly relate to linear algebra over GF(2). Reformulating the problem in those contexts also failed. It is a legitimate, pure CS theory question, that itself relates quite closely so several other known results including in computational geometry
The problem in the post is right at the edge of variants that are known to be in P and variants that have been proven NP-complete. So, in this case, it is simply Fable refusing to engage with a theory question.
Also, as I note in the post:
This may not be true for everyone, but for anyone working in Bioinformatics, Genomics, Computational Biology, Biology, Cybersecurity, and, seemingly Computer Science, this seems to be the case.
Of course it can go on a tear for various coding challenges. However, the more that I learn the more that I also suspect that it rejects not just prompts that may relate tenuously to biology or cybersecurity, but also otherwise completely innocuous prompts that are issued by people who work in areas adjacent to biology and cybersecurity. If true, I think that is certainly a bridge too far, and a hard policy to defend.
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.
