SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
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.
You are a fluke of the universe; you have no right to be here.
(Score: 5, Insightful) by Arik on Monday October 31 2016, @09:40PM
While I am pretty much with you, I have to correct this common misunderstanding. Bug free code is not miraculous. Bug free code requires special skill sets and lots of time and, perhaps most importantly, clear definitions and scope. That last point means you have to insulate development from marketing. Getting those conditions together in todays corporate world might indeed be a miracle, as it goes completely contrary to the corporate mind-set to pay top dollar coders to build a well-defined (i.e. limited) tool slowly, rather than paying smaller salaries for less time to whip together something quickly into which any kitchen-sink accessories marketing wants to see can be dumped equally quickly.
I realize in a world dominated by Microsoft, Apple, and RedHat this may seem counterintuitive, but bugs are not inevitable. We know how to make bug-free programs we just don't know how to make businesses (or, for that matter, most hobbyists) see the value in doing so.
If laughter is the best medicine, who are the best doctors?
(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.
(Score: 2) by HiThere on Tuesday November 01 2016, @06:18PM
I've got to disagree with your point. In any complex environment it's impossible to write bug-free code which will deal with it. There's a combinatorial explosion which prevents it. More to the point, however, in this particular case the cars are using AI techniques, for which your approach is, even in principle, unworkable.
P.S.: There are a few things crashed on Mars that indicate that even in relatively simple scenarios with lots of care and effort you can't ensure bug-free code. This is sort of beside the point when one starts to talk about self-driving cars, however, because these cars aren't entirely programmed. The basic program is written, and then it's trained on lots and lots of data. (One group has written about using "Grand Theft Auto" for training images, but that could only be for the video section of its sensorium.) This is not a way to get "bug-free code", but it's a way to get code + data set which "almost always" works, With more data in more contexts this can improve.
P.S.: It's reasonable for those who don't pretend to be computer literate to think of this stuff as "magic", but when those same people pretend to be computer literate, the comment makes them look like liars, fools or trolls...or just without any sense of how to use the language. "Magic" is a sort of short-hand for "things I don't understand and don't want to understand". When you go to see a stage magician, unless you're interested in doing that, then it's fine to think of it as magic. If you are you might prefer to think of it as legerdemain. Calling it prestidigitation is, itself, misdirection.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 1) by Arik on Tuesday November 01 2016, @09:35PM
OK, that's your right. Try to do so in an interesting way, that's all I ask ;)
"In any complex environment it's impossible to write bug-free code which will deal with it."
Well that's a particularly strong assertion, do you have any proof for it?
"There's a combinatorial explosion which prevents it."
Well that's still just an assertion, and it's highly questionable. I'll try to rehabilitate it. Common methodologies do wind up hitting something that could be aptly characterized as a 'combinatorial explosion' and it does have the effect you attribute. But that is no proof that the problem is unavoidable. That doesn't mean that it cannot be avoided with good design and careful execution.
To put this in more concrete terms, it probably is impossible to create a bug-free version of microsoft word, while sticking anywhere close to its current design. No matter how much you polish a broken design it's still broken. But there's no reason that LaTeX could not be polished into a completely bug free form given the proper investment of time and competence towards that goal. The end user, with the caveats already mentioned applying to that term of course; the end user doesn't really care which design is executing behind the scenes. They want to make a pretty document on their screen and then have it pop out of the printer. They rely on the more experienced users, or on the industry, to worry about how to best make that happen. Would they prefer to have bug-free software to use, even if it cost a little more and didn't always work in exactly the same way? Most of them in my experience will answer strongly in the affirmative, if the question is posed that way, but equally most of them are deeply convinced that bug-free software is simply impossible. This is because they do, indeed, see the computer as something that works essentially by 'magic.' We all do that, we see things we do not understand as magic.
But they're wrong, and good sir, you are wrong as well. Computers do not work by magic. They work by logic.
If laughter is the best medicine, who are the best doctors?
(Score: 2) by HiThere on Wednesday November 02 2016, @06:19PM
Computers do not work by magic, but people are fallible. You can reduce errors by many standard deviations, but you can't eliminate them. Even formal mathematical proofs have been found in error, sometimes long after being accepted as valid. And you're talking about things that have to operate in an environment much less well defined.
If you were to assert that it was logically possible to constrain the goals sufficiently that a sufficiently careful process would eliminate all errors, I might agree with you, but even then I'd have my doubts. Formal proof systems tend to require that the goals be stated without error, e.g., but if you're interested in what the thing does, then that it accomplished the formal goals isn't the test. Even then...there's a few craters on Mars that lead me to doubt that even the formal goals can be properly met. IIUC the recent splash was because the software caused the probe to release the parachute too soon. And I'm rather certain that they were as careful as they could figure out how to be. Another was because of incorrect conversion between measurement systems...or rather non-conversion, and assuming the units were equal when one was metric and the other imperial. The errors are often obvious AFTER you notice them. That doesn't help much ahead of time because of the combinatorial explosion of what needs to be considered. Object oriented programming was an attempt to address this, but it was insufficient. It helps. Assertions help. Unittests help. But even if you only use the Spark subset of Ada you can't eliminate all errors, since some are embedded in the specifications, and when you start making the specifications more complex, you get more errors there. (IIUC the program with the unit non-conversion error WAS written in Spark, but that's an impression from a third had report, so it may well be wrong. It could have meant that it was an error that Spark wouldn't have caught.)
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 1) by Arik on Wednesday November 02 2016, @09:24PM
Which is why we have developed elaborate methods for double-checking ourselves.
"You can reduce errors by many standard deviations, but you can't eliminate them."
You know the more I re-read this the more I think we must be speaking a different language.
Of course you can eliminate them! It's just absurd to say otherwise.
I'm not saying it's trivial, or easy, particularly in the case of complex systems, but to say it's impossible? That makes no sense at all.
If you truly believe this then I don't even know how you could function.
Computing is math. And the beautiful thing about math has always been that there IS a right and wrong answer. If it's a very hard problem, it might be a very difficult answer to come to, but to say there are no answers at all? I can make no sense of that.
"Even formal mathematical proofs have been found in error, sometimes long after being accepted as valid."
And yet if it were impossible to eliminate error, how would this have been detected? These are errors that have been detected and eliminated - they don't prove your point they prove mine!
"If you were to assert that it was logically possible to constrain the goals sufficiently that a sufficiently careful process would eliminate all errors"
I believe that's exactly what I have been saying.
"Formal proof systems tend to require that the goals be stated without error, e.g., but if you're interested in what the thing does, then that it accomplished the formal goals isn't the test."
That's just sloppy framing. The proof that the code does what it says it does, and no more, is an entirely separate concern from the question of whether or not the goals were properly formulated. Formulating goals properly is an art of its own, of course, and if your spec is wrong then the program you get to meet it will be wrong, but that's clearly not the programmers fault, it's the fault of whatever entity determined the spec.
"But even if you only use the Spark subset of Ada you can't eliminate all errors,"
Again, we must be speaking a different language, because that doesn't even make enough sense to be wrong.
"since some are embedded in the specifications,"
Ah, there we go. No. No bugs are embedded in specifications. What you are talking about is faulty specification. Not a software bug.
Even with specifications, sure it's hard, it's a very difficult task in fact, but do you really believe it's *impossible* to write them correctly? If so then why even bother?
We might not, we probably shouldn't, expect to get anything beyond the trivial completely correct at the first go, but I can't see why we should believe it's impossible even in theory, as you seem to do. Aim high, see how close you can get, don't give up at the start, that's so sad.
Unfortunately this seems to be the generally accepted meme these days - everything has bugs, they are just accepted, no one will go to any real effort to eliminate them because they don't realize it's possible. In that way it seems to have become a self-fulfilling prophecy.
If laughter is the best medicine, who are the best doctors?