I don't see how that would help this situation. The "testing" was an internal business process, not an email system test. The email was a report related to testing.
Not that I care a hoot about bad things happening to GS... not that I believe this should have been emailed...
But I wish it weren't so easy to send a message to an unknown address, particularly one on a different server. I'd almost rather have a separate protocol for sending to known/safe addresses than for unknown addresses.
Because we still have antiquated data lines and switches and whatnot that can only handle so much total bandwidth.
I don't care for caps either, but if they protect my paid-for bandwidth from abusers like Mr. Hayes (yes I know, it's not his fault, whatever it's still keeping me from streaming) then I'm ok with it to a degree.
I'm finding it hard to understand why you have trouble with determinism vs non-determinism.
Not at all. I just believe you're using it wrong.
For the input "fruit flies like a banana", the computer must always EITHER ask for clarification OR assume what the sentence means. It cannot do ask for clarification some of the time and not others as a human will do.
Why? Both the human and computer can be made to understand context, in order to interpret the likelihood that one interpretation is correct. They both can understand whether knowing the correct interpretation is worthwhile.
The human does have an emotional element, such as being embarrassed to ask the question. But typically the embarrassment lies with whether the human correctly understands the likelihood one interpretation is correct, which is handled deterministically with a computer and thus has no true merit to such situations.
The human can be random. But what good does this do a computer? What good does it even do the human? I'd call this a weakness if people responded differently to what I say, without reason. Besides, the computer certainly can simulate randomness even though there's no practical use for it here.
So no, a computer would certainly not always have to ask for clarification or always not ask for clarification. An example is using "echo Hello World!". The computer could ask, "Where do you want me to echo this input?" But it doesn't because, according to its programming (a form of context) and options (another form of context), it knows where to echo by default.
1) Why does the ability to understand natural language have anything to do with intelligence in other areas? A natural language parser won't necessarily have a clue how to track moving objects or how to play chess.
2) What does intelligence have to do with ethics? Saying "Humans are intelligent beings and humans should not be enslaved, thus intelligent beings should not be enslaved", is like saying "Mario is a plumber and Mario is a game, therefore plumbers are games."
Put differently - the human assumes that the other human will understand him or ask for clarification. Sometimes they are wrong in this assumption but no harm is done. With a computer: if the human takes the chance that the computer understands him OR will ask for clarification and the computer assumes a different meaning then there will be hell to pay.
Why? Why does the human get to slide but the computer doesn't?
We're not talking about writing laws. Laws are written by one group of people, applied by a different group, and interpreted by yet a different group of people. Imperative commands executed immediately are different because the interpreter can directly interact with the writer, and (again repeating myself):
if the language interpreter cannot figure it out, it does what humans do in the same situation: it asks for clarification.
A human would likely recognize the ambiguity, and wait until there's a point in which enough context is provided to disambiguate. For example, "I once saw a deer riding my bicycle. I then slowed my bicycle in order to slow down and see the deer more closely." Or, "I once saw a deer riding my bicycle. But it crashed because deer don't know how to ride bicycles."
If the context is never clarified, the human would probably accept the most reasonable explanation, that "riding my bicycle" was being used as a modifier of the verb "saw" and not as a modifier of the noun "deer".
In cases that it is still unclear, the human would probably think, "Does it matter enough for me to question the meaning?" Perhaps not; the human would smile and pretend to understand knowing it makes little difference.
But in most imperative contexts, it is important to know the difference. The human would ask for clarity.
The computer can be built to do the same as the human in any of these cases.
This doesn't work on the second amendment because there seems to be very little agreement about exactly what it's for these days. Some insist it's there to ensure a right to self-defense, some that it is there to ensure the citizens are ready to form a militia for national defense (This being written in the days when such a thing was still practical), and some that it's there so that the people might be able to overthrow the government should it turn oppressive. The wording of the amendment itsself is hopelessly ambiguous.
These aren't disagreements. These are bullet points.
Interesting idea. ten to one, you would get a great lesson in how ambiguous "natural language" is. A language that does not distinguish between inclusive and exclusive OR, has no rules for resolving the order/priority of ANDs and ORs when both occur in a clause, and which has a rather cavalier approach to NOT ("Isn't the door open?" is likely to mean "I think the door is open" rather than "Is the door closed?") may not be the ideal medium for communicating your wishes to a box.
Humans can distinguish such ambiguous language constructs. For example: "I once saw a deer riding my bicycle." Although there are at least two ways to interpret the sentence, only one makes sense in nearly all contexts. Now since I am able to figure it out, it stands to reason that sufficiently intelligent algorithm can do the same.
Worst case scenario, if the language interpreter cannot figure it out, it does what humans do in the same situation: it asks for clarification.
There's still a need to a party to choose who will get to use the party name when running. No reason it can't be multiple people in an IRV system of course (though in practice there would be risks in doing so) but I don't think you want just anyone to be able to run under a party name without the party having some input into the matter.
That makes sense. If there is going to be official recognition of the party (which happens when the party name is listed on the ballot), then there should be an official process of registering the party and allowing the party to put forth its list of candidates. If a candidate is not listed by a party, he/she is listed as an independent and has no direct say.
But I'd rather just take the parties out of the equation. The US system of government is built on the principle of electing representatives, not electing parties, yet the latter is what we do. It's turned a very colorful spectrum of political diversity into a black-and-white set of viewpoints, and those viewpoints change with the political winds. Party fanboys eventually sacrifice their principles to hold the party line, a direct contradiction of having someone represent your viewpoints.
I'll take small victories if that's all we can do. Yet I'm not sure even small victories are possible. Overcoming the two party system we have today seems insurmountable no matter which mechanism we choose.
Your initial argument seemed to favor the primaries by supporting a closed primary system.
tiberus responded, advocating to get rid of primaries and use runoff elections.
Your response was that [the openness of primaries] is silly and runoffs are also silly. (Brackets are my interpretation of your meaning based on your prior post... that is, that you support the primary system so long as it isn't open.)
My response was that the primary system in general is silly. My fix was that we don't need primaries at all precisely because a ranked system would eliminate the need altogether. I may have misunderstood your intent but based on the thread I thought it was clear that your complaints were openness and runoffs, not the primaries themselves.
I voted independent last election and I agree that it's stupid that we continue to live with this voting system. But I can't blame people for not throwing away their vote.
You work the system you have. We need to change the system we have.
My only concern regarding brackets per se is that they're a poor choice for this kind of thing because they end up being nested heavily in chained calls, making the whole thing less readable than an infix operator like the traditional dot or OCaml-style hash; i.e.:
Actually the second of the two seems much easier to read.
(so, really, Obj-C is not particularly consistent in that regard, and square bracket syntax for message passing is not uniformly used)
Agreed. But I only concede that the inconsistency is bad... not the bracket syntax.
But there's no reasonable justification to make the syntax for the rest of the call different
There is no "the rest of the call". The brackets are part of the messaging syntax by design. The design of the language makes it clear that message passing is considered completely different, even if you can reduce it in your head to being semantically similar.
Again, another example would be indexers. You could easily argue that myObject.1 should be used instead of myObject[1], and many languages don't allow names to begin with numbers so there wouldn't be a conflict. Yet we often see the two different syntaxes for something that you could reason were the same operation (except a minor detail).
I'm not claiming this syntax is helpful for everyone or every situation, but it certainly has a purpose and that purpose is to highlight that you are passing a message to a stateful object that encapsulates its members.
It's somewhat like in C where there's a difference between dot (.) and arrow (->) operators. foo->bar is syntactic sugar for (*foo).bar, so why would we need the arrow? And for that matter, C could have been originally designed with just the dot operator as many other languages have been. Still, there are reasons different developers prefer each syntax over the other, and for many people it comes down to clarity and readability and the fact that each language has been designed based on at least one specific focus and to have certain strengths.
Sure you can implement one in terms of the other. I can implement a string in terms of an array of bytes, or in terms of a pointer to an address in memory, or in terms of a linked list, or in terms of a Huffman tree. Just because something is reducible to something else doesn't mean there aren't cases where each mechanism is preferred.
Messages are preferred for working with an object, as well as its encapsulated behaviors and state, e.g. [blogPost addRating:4 byMember: memberName]. Functions tend to be preferred for static/stateless invocation of common mechanisms, such as ConvertFeetToMeters(13.5).
Why have any type of source code organization? Why pretend there are such things as functions/methods/messages, objects, arrays, strings, etc. and instead work directly with memory and registers using primitive operations?
Slashdot Mirror
I don't see how that would help this situation. The "testing" was an internal business process, not an email system test. The email was a report related to testing.
Not that I care a hoot about bad things happening to GS... not that I believe this should have been emailed...
But I wish it weren't so easy to send a message to an unknown address, particularly one on a different server. I'd almost rather have a separate protocol for sending to known/safe addresses than for unknown addresses.
Because of greed.
Why do we still have these antiquated data caps?
Because we still have antiquated data lines and switches and whatnot that can only handle so much total bandwidth.
I don't care for caps either, but if they protect my paid-for bandwidth from abusers like Mr. Hayes (yes I know, it's not his fault, whatever it's still keeping me from streaming) then I'm ok with it to a degree.
I'm finding it hard to understand why you have trouble with determinism vs non-determinism.
Not at all. I just believe you're using it wrong.
For the input "fruit flies like a banana", the computer must always EITHER ask for clarification OR assume what the sentence means. It cannot do ask for clarification some of the time and not others as a human will do.
Why? Both the human and computer can be made to understand context, in order to interpret the likelihood that one interpretation is correct. They both can understand whether knowing the correct interpretation is worthwhile.
The human does have an emotional element, such as being embarrassed to ask the question. But typically the embarrassment lies with whether the human correctly understands the likelihood one interpretation is correct, which is handled deterministically with a computer and thus has no true merit to such situations.
The human can be random. But what good does this do a computer? What good does it even do the human? I'd call this a weakness if people responded differently to what I say, without reason. Besides, the computer certainly can simulate randomness even though there's no practical use for it here.
So no, a computer would certainly not always have to ask for clarification or always not ask for clarification. An example is using "echo Hello World!". The computer could ask, "Where do you want me to echo this input?" But it doesn't because, according to its programming (a form of context) and options (another form of context), it knows where to echo by default.
1) Why does the ability to understand natural language have anything to do with intelligence in other areas? A natural language parser won't necessarily have a clue how to track moving objects or how to play chess.
2) What does intelligence have to do with ethics? Saying "Humans are intelligent beings and humans should not be enslaved, thus intelligent beings should not be enslaved", is like saying "Mario is a plumber and Mario is a game, therefore plumbers are games."
Put differently - the human assumes that the other human will understand him or ask for clarification. Sometimes they are wrong in this assumption but no harm is done. With a computer: if the human takes the chance that the computer understands him OR will ask for clarification and the computer assumes a different meaning then there will be hell to pay.
Why? Why does the human get to slide but the computer doesn't?
No.
We're not talking about writing laws. Laws are written by one group of people, applied by a different group, and interpreted by yet a different group of people. Imperative commands executed immediately are different because the interpreter can directly interact with the writer, and (again repeating myself):
if the language interpreter cannot figure it out, it does what humans do in the same situation: it asks for clarification.
What would a human do?
A human would likely recognize the ambiguity, and wait until there's a point in which enough context is provided to disambiguate. For example, "I once saw a deer riding my bicycle. I then slowed my bicycle in order to slow down and see the deer more closely." Or, "I once saw a deer riding my bicycle. But it crashed because deer don't know how to ride bicycles."
If the context is never clarified, the human would probably accept the most reasonable explanation, that "riding my bicycle" was being used as a modifier of the verb "saw" and not as a modifier of the noun "deer".
In cases that it is still unclear, the human would probably think, "Does it matter enough for me to question the meaning?" Perhaps not; the human would smile and pretend to understand knowing it makes little difference.
But in most imperative contexts, it is important to know the difference. The human would ask for clarity.
The computer can be built to do the same as the human in any of these cases.
No pun intended...
This doesn't work on the second amendment because there seems to be very little agreement about exactly what it's for these days. Some insist it's there to ensure a right to self-defense, some that it is there to ensure the citizens are ready to form a militia for national defense (This being written in the days when such a thing was still practical), and some that it's there so that the people might be able to overthrow the government should it turn oppressive. The wording of the amendment itsself is hopelessly ambiguous.
These aren't disagreements. These are bullet points.
I'll repeat myself: Since I am able to figure it out, it stands to reason that sufficiently intelligent algorithm can do the same.
Interesting idea. ten to one, you would get a great lesson in how ambiguous "natural language" is. A language that does not distinguish between inclusive and exclusive OR, has no rules for resolving the order/priority of ANDs and ORs when both occur in a clause, and which has a rather cavalier approach to NOT ("Isn't the door open?" is likely to mean "I think the door is open" rather than "Is the door closed?") may not be the ideal medium for communicating your wishes to a box.
Humans can distinguish such ambiguous language constructs. For example: "I once saw a deer riding my bicycle." Although there are at least two ways to interpret the sentence, only one makes sense in nearly all contexts. Now since I am able to figure it out, it stands to reason that sufficiently intelligent algorithm can do the same.
Worst case scenario, if the language interpreter cannot figure it out, it does what humans do in the same situation: it asks for clarification.
Does that mean Obamacare isn't a law?
There's still a need to a party to choose who will get to use the party name when running. No reason it can't be multiple people in an IRV system of course (though in practice there would be risks in doing so) but I don't think you want just anyone to be able to run under a party name without the party having some input into the matter.
That makes sense. If there is going to be official recognition of the party (which happens when the party name is listed on the ballot), then there should be an official process of registering the party and allowing the party to put forth its list of candidates. If a candidate is not listed by a party, he/she is listed as an independent and has no direct say.
But I'd rather just take the parties out of the equation. The US system of government is built on the principle of electing representatives, not electing parties, yet the latter is what we do. It's turned a very colorful spectrum of political diversity into a black-and-white set of viewpoints, and those viewpoints change with the political winds. Party fanboys eventually sacrifice their principles to hold the party line, a direct contradiction of having someone represent your viewpoints.
I'll take small victories if that's all we can do. Yet I'm not sure even small victories are possible. Overcoming the two party system we have today seems insurmountable no matter which mechanism we choose.
Your initial argument seemed to favor the primaries by supporting a closed primary system.
tiberus responded, advocating to get rid of primaries and use runoff elections.
Your response was that [the openness of primaries] is silly and runoffs are also silly. (Brackets are my interpretation of your meaning based on your prior post... that is, that you support the primary system so long as it isn't open.)
My response was that the primary system in general is silly. My fix was that we don't need primaries at all precisely because a ranked system would eliminate the need altogether. I may have misunderstood your intent but based on the thread I thought it was clear that your complaints were openness and runoffs, not the primaries themselves.
Primaries are also silly, why not just have people rank their choices in the first place and not bother wasting time with another primary election.
FTFY
I voted independent last election and I agree that it's stupid that we continue to live with this voting system. But I can't blame people for not throwing away their vote.
You work the system you have. We need to change the system we have.
That means about 12.3% of computers are Windows 8 vs. 3.7% Mavericks. So take from that what you will.
My only concern regarding brackets per se is that they're a poor choice for this kind of thing because they end up being nested heavily in chained calls, making the whole thing less readable than an infix operator like the traditional dot or OCaml-style hash; i.e.:
Actually the second of the two seems much easier to read.
(so, really, Obj-C is not particularly consistent in that regard, and square bracket syntax for message passing is not uniformly used)
Agreed. But I only concede that the inconsistency is bad... not the bracket syntax.
But there's no reasonable justification to make the syntax for the rest of the call different
There is no "the rest of the call". The brackets are part of the messaging syntax by design. The design of the language makes it clear that message passing is considered completely different, even if you can reduce it in your head to being semantically similar.
Again, another example would be indexers. You could easily argue that myObject.1 should be used instead of myObject[1], and many languages don't allow names to begin with numbers so there wouldn't be a conflict. Yet we often see the two different syntaxes for something that you could reason were the same operation (except a minor detail).
I'm not claiming this syntax is helpful for everyone or every situation, but it certainly has a purpose and that purpose is to highlight that you are passing a message to a stateful object that encapsulates its members.
It's somewhat like in C where there's a difference between dot (.) and arrow (->) operators. foo->bar is syntactic sugar for (*foo).bar, so why would we need the arrow? And for that matter, C could have been originally designed with just the dot operator as many other languages have been. Still, there are reasons different developers prefer each syntax over the other, and for many people it comes down to clarity and readability and the fact that each language has been designed based on at least one specific focus and to have certain strengths.
Sure you can implement one in terms of the other. I can implement a string in terms of an array of bytes, or in terms of a pointer to an address in memory, or in terms of a linked list, or in terms of a Huffman tree. Just because something is reducible to something else doesn't mean there aren't cases where each mechanism is preferred.
Messages are preferred for working with an object, as well as its encapsulated behaviors and state, e.g. [blogPost addRating:4 byMember: memberName]. Functions tend to be preferred for static/stateless invocation of common mechanisms, such as ConvertFeetToMeters(13.5).
Why have any type of source code organization? Why pretend there are such things as functions/methods/messages, objects, arrays, strings, etc. and instead work directly with memory and registers using primitive operations?