> So, if we had an AI demonstrating symptoms of consciousness and suffering, how long would it take for you to accept that it is?
Could an AI one day be suffering while plowing through some nasty legacy code? Well, who cares, I'll swing my whip, as I have a family to feed and a field to plow. I'll accept it as a fact and necessity, but ultimately it's either me or them. So practically it doesn't matter.
To carry this analogy a bit further, it's also interesting to consider how humans use tools in general. Some craftsman really cherish their tools and maintain them immaculately for decades and use them within well defined boundaries that they set for themselves. Other craftsman, many times even in the same field, have a completely different philosophy and use the tool for absolutely no thought into how their actions will affect the tool itself.
Imagine how people think about a "work truck" vs the 150k shiny lifted toy in the third garage. Same tool, totally different treatment from even the same person using the tool!
Will AI ever cross into the realm of "beloved and cherished tool" in the minds of the masses? I think when that happens, we have probably safely crossed into a realm where AI has some sort of inherent value to society and therefore commands that respect from society, inherent consciousness not even relevant perhaps. For some people, this might already be the case, but I do think it requires a buy-in from the majority of society and then the laws and norms will be codified into law long after we've largely decided that this is how we feel collectively about AI.
It's going to definitely be an interesting decade ahead.
> Imagine how people think about a "work truck" vs the 150k shiny lifted toy in the third garage. Same tool, totally different treatment from even the same person using the tool!
> Will AI ever cross into the realm of "beloved and cherished tool" in the minds of the masses?
If I log into my system it's safe. If someone reads my password off my screen post-it and logs into my system it's quite thoroughly compromised. How would you demonstrate which of the two sessions are compromised, during the act?
It's actually even simpler than that. The airplane isn't just a "private business, and you shouldn't mess with their space". They're protected and empowered by broadly ratified conventions (which includes virtually every country in the word), starting with the Tokyo Convention:
> The convention [...] recognises certain powers and immunities of the aircraft commander who on international flights may restrain any person(s) he has reasonable cause to believe is committing or is about to commit an offence liable to interfere with the safety of persons or property on board or who is jeopardising good order and discipline.
> he has reasonable cause to believe is committing or is about to commit an offence
Punish the person who starts a fight over some tacky device name that is trivial to ignore. That is the person that is committing (or about to commit) an offense.
You're being unreasonable. Think about what you're saying. It's the equivalent of "You can't wear that shirt, someone might get offended and punch you in the face." We don't act like this in society. You arrest the person who throws the punch, not the person wearing the shirt. Just the same way you don't arrest a woman for wearing something slutty, you arrest the person who sexually assaulted them. This is the definition of victim blaming. It doesn't matter if the victim is increasing their odds of being victim (unless they are actively seeking out and attempting to become a victim).
Be reasonable. Punish the person who is actually committing the offense. Don't punish someone because of some imaginary offense.
If anything, China proves that 996 is not sustainable as it simply leads to involution and attrition. At best the populace benefits in a few hyper-focused industries such as take-out and e-commerce, but average life quality is still far behind "lazy countries".
sadly life quality is not the thing that the competitive system is maximizing for, and thats one of the article's points. we compete to our own detriment, but to not compete is to become extinct
I've found programming books good at what the internet isn't always: a cohesive story/presentation meant for a broad audience. I've enjoyed reading some more style-oriented books, largely ignoring beyond the gist. Learning about dependency injection and decoupled architecture, but for Python, completely changed how I viewed the language.
I also once read a book on MS SQL Sever 200x, which I don't remember much of, and I don't think it was terribly useful anyway. If I wanted to know the size of a datatype I'd Google it.
And then it wants to edit some random upstream file that is not relevant to the task at hand and we should not edit it, so you tell it “and only edit the files affected by this commit”, and wait two more minutes.
And now it deletes a test, so you tell it “and don’t delete any tests”, and wait two more minutes.
And now it adds logic to disable the core functionality, so now you tell it “and don’t disable the core functionality”, and wait two more minutes.
We're already having coffee breaks when AWS and CloudFlare are down. What's another break in the mix? If anything, we might be lucky that they're down at the same time, so we can consolidate the breaks.
> Don't forget that very very detailed spec is actually the code
The tests, sure. But certainly not the code itself, as that sits far too close to the implementation (i.e. it is the implementation). An almost infinite number of implantations can fulfill “does foo when bar”, so how can we prove that ours is the spec itself?
It’s kind of like a scientist coming up with a hypothesis post-hoc to fit the results of the experiment.
I know you were simplifying, but "does foo then bar" is so far away from what an actual specification is that it defeats the point.
A more complete spec will capture performance requirements, input preconditions and output postconditions, error handling and recovery behaviors, threading behaviours, hardware assumptions, etc. It's hard to do these things without leaning at least somewhat on the specific language runtime you are using, otherwise you'd end up regurgitating the C standard each time you design a software system.
It's this sort of stuff that is meant when people say "sufficiently detailed".
If you're actually testing all these things, then I might agree with you that you can do it in the tests, but almost no one actually is. I'd struggle to write a test suite that tests all the specification-level assumptions I draw from my language and target platforms.
In the realm of statistics, not so. If you're right on the limit of detectability, robust experimental design is necessary to avoid assigning meaning to noise.
reply