Absolutely anything that you would have to worry about an artificial intelligence doing that might be troublesome to our society, you would have to also need to reasonably worry about a malicious person doing exact the same thing, albeit perhaps only more slowly.
A lot more slowly. A coordinated action would be much easier for an AI than for humans, and much harder for us to spot.
Also, we can somewhat anticipate and understand human reasoning, even when it's couched in different cultural values because we share most biological features. AI reasoning might very well be completely alien and unpredictable to us, and it's environment completely inscrutable. That's a good reason to be very cautious. I think the movie Ex Machina did a decent job highlighting this.
Further, AIs can be effectively immortal if any copies exist. That kind of opponent is incredibly dangerous.
Humans are at a huge disadvantage compared to AIs, so there's plenty of rational reasons to fear them. I don't think we're anywhere near the point where this fear is rationally justified on a daily basis, but it's not inconceivable that it could happen sometime in the 21st century.
Yes, just make your users your testers, great idea.
User acceptance testing is the only meaningful testing of this sort. There's no way around it really. Black box testers don't have the domain knowledge that end users have, nearly any usability feedback is practically meaningless. How could a blackbox tester possibly really know whether a particular screen layout, or information organization, would make sense to an end user?
Developers are frequently not very much in tune with their target end user perspective. Hence why I see my fellow developers get frustrated with testers and even clients, wondering why the users can't do things the way the developer thinks they should do.
If users are confused, it's an impedance mismatch between what a developer thinks the user knows, and what the user actually knows. Which is a spec failure. The developer can't divine what a hypothetical user would know at any given moment by magic. How could a QA team know this information? And if they somehow know, why not just communicate this to the dev in the spec in the first place?
Please point out where I said "unit tests" anywhere in my comment. I specifically said automated tests, which encompasses any testing procedure that can be conceivably run on a computer (which is conceivably just about anything a human can do).
And automated tests follow a fixed procedure by definition, as they're computer programs. People following tedious, repetitive tasks, like testing programs, make frequent mistakes. This is a well known fact from the manufacturing industry.
By all means add more automated testing and hopefully make the QA process smoother, but skipping it entirely (they fired the QA team) is a recipe for disaster, and the only thing they have to measure the effectiveness of this is the number of issues in their issue tracker, which was *fed* by the QA tea.
Which can be replaced by an easy issue submission process embedded in the program itself. Combined with a program trace of the user's actions, which Yahoo already uses as part of its distributed architecture, the developer would be able to reproduce precisely any behaviour seen.
The testers are using the software much like a human would, and they do unexpected human things like the end user would be doing. This particularly helps identify usability issues, which isn't really an automation sort of thing.
But you can automate entry of unexpected data too, without having to generate the data/tests yourself. See QuickCheck and other testing tools inspired by it, which invokes functions with a large set of permutations over the full domain of its parameters, starting with upper and lower bounds, ie. if your function accepts an int, it will invoke it thousands of times int.MaxValue, int.MinValue, and a number of randomly selected values between.
Sometimes single minded march toward matching the spec is a bad idea, because the spec is bad and needs to be revisited.
Sure, but you can't fix spec problems in the testing phase with a QA team that aren't domain experts. Only end users can validate something like this, which is where shorter feedback cycles with end users are key delivering a good result.
Re: humans having a hard time using an interface, this is generally obvious to the developers too while they're writing and testing their own code. They generally just don't have a process available via which they can question the viability of the spec and be taken seriously.
We were tired of being constantly bogged down by all these mistakes and bugs, so we got rid of the people who kept telling us about all the mistakes and bugs.
His argument is sound though. Testers don't always follow proper testing procedure, so you'll still get plenty of bugs passing through it, and it takes way too much time for this to feed back into the develop-test cycle. Better to spend all that QA time writing more automated tests of various types, which the devs can run themselves during their much shorter develop-test feedback cycle. This obviously increases robustness towards matching the spec, and you're just left with acceptance testing to ensure your spec matches client expectations.
Not to create scarcity means most creators are valueless, at more or less the valuation of a person capable of doing what you can do with a simple shell script.
Not at all. Post-scarcity on IP makes reproductions valueless, which is a whole different point. People willingly pay money to see artists perform their work live (like concerts), or commission work just for them (the way artists used to make a living when they had patrons).
That "will" part expresses perhaps an excess of expectation. A post-scarcity economy is in the apprx. "never will" happen category.
I disagree. They "never will" work at jobs they hate, which means those menial jobs that nearly everyone hates to do will require more incentives. Seems perfectly reasonable.
Jurors are not supposed to be complete blank slates, and it's possible to be impartial even if you have some prior knowledge.
Complete bank slates is certainly the ideal, even if it's impossible even in principle. Most people form their opinions from things they've been told, or things they've experienced, neither of which are impartial sources of fact. Hence, "do they know something is true, or do they merely think something is true?".
Furthermore, establishing legal fact is a different process from establishing scientific fact. Even if they were a gender research scientist, that doesn't necessarily make them sufficiently unbiased to judge whether sexism happened in this case.
Suppose that there is some sexism in tech. In that case, filtering out people who claim there is some gets rid of the people who know what's going on
Do they know, or do they just think they know? The whole point of this jury selection process is to filter out such assumptions and establish an impartial jury, to let the each side present their case and let the facts speak for themselves.
I would think it would be reasonable to have some jurors who can acknowledge that sexism exists in tech, and then decide whether sexism was at play in this particular case.
You're only describing one side of this. Yes, jurors who are already convinced sexism is happening were filtered out, but so were those that are convinced that sexism isn't happening. The point is to have a set of people that have little to no information or opinion on the topic, to provide them the facts of this case, define sexism as enshrined in law, and to let them reach an unbiased verdict whether the facts entail that the law was violated.
Autonomy, Mastery, Purpose: you'll be happy with your job to the extent it has these qualities. How much autonomy do most engineering jobs give you? Not much I imagine. How much mastery? Well you're certainly not going to be exploring many new skills, or even masterting particularly difficult ones on average; it's mostly repetitive scaffolding with glue.
Purpose is pretty much the only one that technology work has plenty of. Everything runs on information technology now, so if you're interested in tech, which you probably are, you'll find lots of purpose in developing or administering information systems. This only goes so far before the lack of autonomy gets to you, or you hit the mastery ceiling pretty quickly at any given job.
"If you create encryption, it makes it harder for the American government to do its job — while protecting civil liberties — to make sure that evildoers aren't in our midst."
Oh the face-slapping irony. The freedom to create encryption is a civil liberty.
maybe the fact that Javascript doesn't even have integers?
That's indeed a problem.
Or that (other than in asm.js) it doesn't support C-style malloc/free heap-based allocation? Or that (again, other than in asm.js) the runtime is garbage collected? Or that it doesn't properly support threads (a huge deal given the demands of modern computing), or sharing of memory between WebWorkers and the main thread?
Those aren't problems. Shared memory concurrency is hard, and we don't want the resulting bugs in our browser. Event loops are perfect in this domain.
Manual memory allocation should never be the default; I'm not even sure it should be an option at all. If you're using JS for games, then what's really needed is simply latency annotations to indicate that low latency is more important than throughput in this context.
The biggest JS problem IMO: weird implicit coercions resulting in surprising equalities and inequalities.
I coach an after school program in robotics and programming at my local elementary school, and I agree that this is baloney. The parents are pushing hard for their girls to pursue tech, and it is the girls themselves that are disinterested.
This is only a meaningful data point if you can demonstrate that such families aren't already biased towards selecting for parents more interested in tech careers.
I rather think it's quite biased towards such parents. After all, why would you be hearing from parents not interested in tech for their daughters? So your ancedote wouldn't be meaningful in the face of rigourous data (assuming Google's study has such data).
Further, "Like many of new languages, Rust is walking the path of simplification. I can generally understand why it doesn't have a decent inheritance and exceptions [...]
Spoken like someone who has no clue about the breadth and depth of the various programming paradigms available. The fact that he still considers inheritance as somehow essential just reveals his ignorance on the progress on comp sci over the past 20+ years.
Exceptions are more debatable, since we don't yet have a better error handling abstraction that scales from local to global error handling (checked exceptions are the best we have so far).
[...] but the fact itself that someone is making decisions for me regarding things like that makes me feel somewhat displeased. C++ doesn't restrict programmers regarding what they can or cannot use."
I don't even... So by this argument, C++ restricts me from using generators and first-class delimited continuations, so it's not good enough either.
This argument is both a contradiction because C++ also makes such decisions thus disqualifying it despite the author's claims, AND it's tautological because every language makes opinionated decisions about acceptable idioms. Really, no language could possibly satisfy the author's requirements.
Given its goals, I think Rust made a pretty good set of opinionated choices though. Certainly better than C++ overall.
Slashdot Mirror
You are correct. At least, it certainly looks that way. Or they were simply unusually intimidated by his stare and waving hand.
I said immortal, not immoral.
I think you're downplaying the danger. AIs are like intelligent, immortal children that can communicate and coordinate across the globe faster than you can blink and whose values and perceptions of the world are completely inscrutable.
A lot more slowly. A coordinated action would be much easier for an AI than for humans, and much harder for us to spot.
Also, we can somewhat anticipate and understand human reasoning, even when it's couched in different cultural values because we share most biological features. AI reasoning might very well be completely alien and unpredictable to us, and it's environment completely inscrutable. That's a good reason to be very cautious. I think the movie Ex Machina did a decent job highlighting this.
Further, AIs can be effectively immortal if any copies exist. That kind of opponent is incredibly dangerous.
Humans are at a huge disadvantage compared to AIs, so there's plenty of rational reasons to fear them. I don't think we're anywhere near the point where this fear is rationally justified on a daily basis, but it's not inconceivable that it could happen sometime in the 21st century.
Totally. Is there an edition that's just cleaned up to HD quality, with no extra CG?
User acceptance testing is the only meaningful testing of this sort. There's no way around it really. Black box testers don't have the domain knowledge that end users have, nearly any usability feedback is practically meaningless. How could a blackbox tester possibly really know whether a particular screen layout, or information organization, would make sense to an end user?
If users are confused, it's an impedance mismatch between what a developer thinks the user knows, and what the user actually knows. Which is a spec failure. The developer can't divine what a hypothetical user would know at any given moment by magic. How could a QA team know this information? And if they somehow know, why not just communicate this to the dev in the spec in the first place?
Please point out where I said "unit tests" anywhere in my comment. I specifically said automated tests, which encompasses any testing procedure that can be conceivably run on a computer (which is conceivably just about anything a human can do).
And automated tests follow a fixed procedure by definition, as they're computer programs. People following tedious, repetitive tasks, like testing programs, make frequent mistakes. This is a well known fact from the manufacturing industry.
Which can be replaced by an easy issue submission process embedded in the program itself. Combined with a program trace of the user's actions, which Yahoo already uses as part of its distributed architecture, the developer would be able to reproduce precisely any behaviour seen.
But you can automate entry of unexpected data too, without having to generate the data/tests yourself. See QuickCheck and other testing tools inspired by it, which invokes functions with a large set of permutations over the full domain of its parameters, starting with upper and lower bounds, ie. if your function accepts an int, it will invoke it thousands of times int.MaxValue, int.MinValue, and a number of randomly selected values between.
Sure, but you can't fix spec problems in the testing phase with a QA team that aren't domain experts. Only end users can validate something like this, which is where shorter feedback cycles with end users are key delivering a good result.
Re: humans having a hard time using an interface, this is generally obvious to the developers too while they're writing and testing their own code. They generally just don't have a process available via which they can question the viability of the spec and be taken seriously.
His argument is sound though. Testers don't always follow proper testing procedure, so you'll still get plenty of bugs passing through it, and it takes way too much time for this to feed back into the develop-test cycle. Better to spend all that QA time writing more automated tests of various types, which the devs can run themselves during their much shorter develop-test feedback cycle. This obviously increases robustness towards matching the spec, and you're just left with acceptance testing to ensure your spec matches client expectations.
It's ordinary pressure, not light pressure that keeps stars from collapsing.
A post-scarcity society for basic living needs leads to exactly a scarcity of menial labourers.
Not at all. Post-scarcity on IP makes reproductions valueless, which is a whole different point. People willingly pay money to see artists perform their work live (like concerts), or commission work just for them (the way artists used to make a living when they had patrons).
I disagree. They "never will" work at jobs they hate, which means those menial jobs that nearly everyone hates to do will require more incentives. Seems perfectly reasonable.
Complete bank slates is certainly the ideal, even if it's impossible even in principle. Most people form their opinions from things they've been told, or things they've experienced, neither of which are impartial sources of fact. Hence, "do they know something is true, or do they merely think something is true?".
Furthermore, establishing legal fact is a different process from establishing scientific fact. Even if they were a gender research scientist, that doesn't necessarily make them sufficiently unbiased to judge whether sexism happened in this case.
Do they know, or do they just think they know? The whole point of this jury selection process is to filter out such assumptions and establish an impartial jury, to let the each side present their case and let the facts speak for themselves.
You're only describing one side of this. Yes, jurors who are already convinced sexism is happening were filtered out, but so were those that are convinced that sexism isn't happening. The point is to have a set of people that have little to no information or opinion on the topic, to provide them the facts of this case, define sexism as enshrined in law, and to let them reach an unbiased verdict whether the facts entail that the law was violated.
In other words, they filtered out those who were biased? Sounds like a good idea to me. The jury is ideally supposed to be impartial.
Autonomy, Mastery, Purpose: you'll be happy with your job to the extent it has these qualities. How much autonomy do most engineering jobs give you? Not much I imagine. How much mastery? Well you're certainly not going to be exploring many new skills, or even masterting particularly difficult ones on average; it's mostly repetitive scaffolding with glue.
Purpose is pretty much the only one that technology work has plenty of. Everything runs on information technology now, so if you're interested in tech, which you probably are, you'll find lots of purpose in developing or administering information systems. This only goes so far before the lack of autonomy gets to you, or you hit the mastery ceiling pretty quickly at any given job.
Oh the face-slapping irony. The freedom to create encryption is a civil liberty.
That's indeed a problem.
Those aren't problems. Shared memory concurrency is hard, and we don't want the resulting bugs in our browser. Event loops are perfect in this domain.
Manual memory allocation should never be the default; I'm not even sure it should be an option at all. If you're using JS for games, then what's really needed is simply latency annotations to indicate that low latency is more important than throughput in this context.
The biggest JS problem IMO: weird implicit coercions resulting in surprising equalities and inequalities.
They aren't minor, and some of MS's libraries are unparalleled on Java because of the syntactic choices they made.
There are patent issues with every technology.
He can sue the police, which is the recourse available everyone should exploit for being wrongfully arrested.
This is only a meaningful data point if you can demonstrate that such families aren't already biased towards selecting for parents more interested in tech careers.
I rather think it's quite biased towards such parents. After all, why would you be hearing from parents not interested in tech for their daughters? So your ancedote wouldn't be meaningful in the face of rigourous data (assuming Google's study has such data).
Spoken like someone who has no clue about the breadth and depth of the various programming paradigms available. The fact that he still considers inheritance as somehow essential just reveals his ignorance on the progress on comp sci over the past 20+ years.
Exceptions are more debatable, since we don't yet have a better error handling abstraction that scales from local to global error handling (checked exceptions are the best we have so far).
I don't even... So by this argument, C++ restricts me from using generators and first-class delimited continuations, so it's not good enough either.
This argument is both a contradiction because C++ also makes such decisions thus disqualifying it despite the author's claims, AND it's tautological because every language makes opinionated decisions about acceptable idioms. Really, no language could possibly satisfy the author's requirements.
Given its goals, I think Rust made a pretty good set of opinionated choices though. Certainly better than C++ overall.