SoylentNews is people
SoylentNews
posted by
cmn32480
on Monday October 31 2016, @06:16PM
from the explosions-killing-everybody-isn't-a-choice dept.
from the explosions-killing-everybody-isn't-a-choice dept.
Researchers at MIT have put together a pictorial survey http://moralmachine.mit.edu/ -- if the self-driving car loses its brakes, should it go straight or turn? Various scenarios are presented with either occupants or pedestrians dying, and there are a variety of peds in the road from strollers to thieves, even pets.
This AC found that I quickly began to develop my own simplistic criteria and the decisions got easier the further I went in the survey.
While the survey is very much idealized, it may have just enough complexity to give some useful results?
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Madness takes its toll.
(Score: 2) by maxwell demon on Tuesday November 01 2016, @05:34AM
Well, you are using two different definitions of "bug-free". Code can be bug-free as in "works exactly as specified." But that is usually not what the end user is concerned about; the end user doesn't care if the code doesn't do what it should because a programmer did not correctly implement the spec, or if it doesn't do what it should do because the spec didn't cover that scenario, or because the spec specified incorrect behaviour. All the end user cares about is whether the software does what it is meant to do. And from a certain complexity, that is impossible to guarantee.
A code that perfectly implements the spec may still be buggy, it's just that it's not the programmer who is at fault in that case (unless the programmer is also the one who wrote the spec).
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by Arik on Tuesday November 01 2016, @06:43AM
Now sure as you point out you can have good code that implements a crappy spec. That's exactly why I pointed out that you have to wall off marketing from making the spec. Most likely their contributions won't just be bad, they'll be so bad they aren't even wrong. They'll be on another planet.
And no I am not using two definitions of bug free. I am using one definition, a bug is a bug is a bug. A bug is faulty logic, on a computer.
"And from a certain complexity, that is impossible to guarantee."
I disagree. It's not impossible. It just requires a long and disciplined development path. You can't just hack together a large and complex system and then polish it to perfection like you can do with a simpler function. But you can, with careful planning, assemble very large and complex systems from those simpler functions, with the functions themselves as well as their interactions all tightly defined and verifiable.
If we'd spent the last 3 decades doing that instead of playing with IPOs and endlessly reinventing the wheel, each time with more studs and sparkles and this years colors! we'd certainly have a very different sort of experience with our computers today.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by maxwell demon on Tuesday November 01 2016, @09:12AM
I was using the plural "you", referring to both [singular] you and the one you responded to.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by maxwell demon on Tuesday November 01 2016, @09:20AM
It is impossible in practice. For it to be possible, you would have to know what's right for the user better than the user himself. That is not possible (and software written by programmers who think they do is often a pain to use).
I don't doubt that. But then, that's not what I'm speaking about. Well defined and verifiable is not the same as correct.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1) by Arik on Tuesday November 01 2016, @10:12PM
Ahh, ok, now I understand you.
Still not sure you are right though. I know exactly what a bug is, the other gent may be squishy on it but I don't think he has any distinct and viable definition.
"For it to be possible, you would have to know what's right for the user better than the user himself."
I don't agree at all. You're confusing things that have to be kept distinct here.
The programmer can and should know exactly what his program is supposed to do, and at least can with sufficient effort know that his program does exactly that and no more.
It's not the programmers job to know what the user needs. It's the users job to find the tool the user needs. It's the programmers job to build tools that work correctly. It's the businessman's job to figure out what tools the users need, and pay programmers to produce them in a timely fashion. Everyone has to do their part and no one can be reasonably expected to do everyone else's part as well.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by maxwell demon on Wednesday November 02 2016, @07:37AM
You are contradicting yourself:
On one hand, you claim:
On the other hand you claim:
Either the programmer's just is to produce correct code, or the programmer's job is to implement whatever the businessman wants (and note: The businessman's job most decidedly is not to find out what the user needs, but what gives the most profit to the company. The two have some correlation, but are far from the same).
Note that a programmer accurately implementing an incorrect specification still produces an incorrect program. And the user couldn't care less who exactly fucked up; an incorrect program is a program that behaves incorrectly, no matter whether due to a programming error, a wrong specification, or whatever else.
You seem to be of the illusion that it is only the programmer that produces the software. For a company it's the whole company that is involved in that process (well, there are probably a few departments that aren't, like payroll accounting), not just the programmers. And it doesn't matter where exactly the problem is introduced, an incorrect program is an incorrect program is an incorrect program.
Oh, and you also seem to think only companies produce software; for some software there is no businessman involved at all.
The Tao of math: The numbers you can count are not the real numbers.