This reminds of this article which contends that this mistake has carried across time, in every era people described the workings of the brain similar to the machines they knew how to build, which is why we have "ridiculous" descriptions that changed over time.
I like Leibniz's comparison of the brain to a mill, which he invokes in an argument[1] that seems to be the predecessor of the modern "hard problem:"
> supposing that there were a mechanism so constructed as to think, feel and have perception, we might enter it as into a mill. And this granted, we should only find on visiting it, pieces which push one against another, but never anything by which to explain a perception.
That's a better link, thanks. Not much substance there about this though!
> One of the areas where he personally had been wide of the mark was on AI’s short-term impact on entry-level white-collar jobs, which had not been nearly as bad as he had once predicted, he said. “I’m delighted to be wrong about that.”
I'm not sure that justifies a whole "Sam Altman ... walking back AI jobs apocalypse predictions" headline, personally. It's pretty thin.
But... we still haven't seen the full interview, so there might be more to it. The Fortune article also includes:
> Altman added that he’s taken a lot of flack for his hype, but better safe than sorry.”People are like, ‘Oh you could have saved the world a lot of fear mongering and a lot of doom and gloom’ but at the time I was like, ‘I see this is a real risk we should probably talk about it.’ and it still may.”
People with lots of power and clout contribute to making predictions reality by all making predictions that make similar assumptions. The predictions become more likely because people already behave as if they're likely.
Marketing people like the features they're getting, and Google and Meta are dominant, so big that they're the default, in the same way that we talk about github being the default option, and "no one ever got fired for choosing IBM / (big tech company of your choosing)". I wouldn't dream of saying they should choose something else, without researching and guaranteeing that nothing they'd ever want from GA (and they may not know everything they'll want in the future right now) is missing in the alternative. In a role (marketing) that's completely out of my wheelhouse. So I don't even bother.
The problem with old Python code is that you then have to hunt for exactly the right version of the right libraries that can work together when the stars are aligned.
Isn't that true of any packaging system? (npm, RubyGems, etc) Perhaps it's a bit easier, with the respective spec files, but it's still a bit of a hunt.
No. Decent packaging systems like used in the Java world have deterministic or mostly-deterministic dependency resolution; semi-decent packaging systems like the ones you mention have lockfiles. Pre-uv Python packaging is uniquely awful.
You don't need them. Maven has deterministic dependency resolution (unless you use version ranges, but don't do that), so you just write your dependencies. (The flipside is you may want to get in the habit of doing something like versions:use-latest-releases as a regular housekeeping task so that you pick up any security updates, but that tends to be less of an issue in Java-land for other reasons)
Why don’t I need them? I can’t make every third-party package do exact version pins and it’d be miserable if I could because then I couldn’t patch a transitive dependency faster than the upstream even if there’s a drop-in patch release which is 100% compatible.
Even if that worked, I’d also want hashes to avoid file modification, although that’s less of a concern for anything on Maven Central where the releases are immutable.
> I can’t make every third-party package do exact version pins
Every third-party package already uses exact version dependencies, you don't need to do anything.
> then I couldn’t patch a transitive dependency faster than the upstream even if there’s a drop-in patch release which is 100% compatible.
You can always override the transitive dependency version if you want to.
> I’d also want hashes to avoid file modification, although that’s less of a concern for anything on Maven Central where the releases are immutable.
It's not just Maven Central, there's a strong norm of releases being immutable everywhere. If you're worried about attacks, there's a plugin you can enable to check the GPG signatures.
Depends on exactly how the project is managed. Older python tooling (`pip` module) doesn't have a native mechanism to differentiate between the spec (direct dependencies) and freeze (all dependencies, including transitive).
For us, yes - and likely for a lot of other users. I'm not certain who else has dealt with the headache of being migrated off their legacy pricing plan but it ends up pushing those internal offerings a lot harder than the old approach did so if they're seeing successful conversions it's likely they're seeing significantly more load from mature codebases with expensive CI/CD pipelines.
The important part was the following paragraph(s) that explained why this coupling is a compelling problem. It's not the same as just having a platform API.
This reminds of the conversation the other day about the deleted production database at railway. "this person obviously didn't follow best practice of being hyper distrusting of LLM agents", and the response "yeah but every company is marketing it as safe. someone is gonna fall for it".
(Well-regulated) free markets are sort of built on the principle of educated consumerism. Your choice matters; its not up to the government to make illegal every non-optimal product. However, we do expect some minimum level of safety.
What does that mean for llms? Their nondeterminism does seem to incline them toward a legal safety requirement. Can you buy a fire extinguisher that 1/1000 times burns your house down? Or can your car brakes instead increase acceleration in rare cases?
Im using llms much more than i used to, but i still cant shake the fundamental stochastic nature of the technology.
Wherever I'm going, I'll be there to apply the formula. I'll keep the secret intact.
It's simple arithmetic.
It's a story problem.
If a new car built by my company leaves Chicago traveling west at 60 miles per hour, and the rear differential locks up, and the car crashes and burns with everyone trapped inside, does my company initiate a recall?
You take the population of vehicles in the field (A) and multiple it by the probable rate of failure (B), then multiply the result by the average cost of an out-of-court settlement (C).
A times B times C equals X. This is what it will cost if we don't initiate a recall.
If X is greater than the cost of a recall, we recall the cars and no one gets hurt.
If X is less than the cost of a recall, then we don't recall.
Or not, because telling the agent is misbehaving may predispose it to misbehaving behavior, even though you point told it so to tell it to not behave that way.
I remember this discussed when a similar issue went viral with someone building a product using replit's AI and it deleted his prod database.
https://aeon.co/essays/your-brain-does-not-process-informati...
reply