.... pull the driver information out of the state vehicle registration database
And of course, anybody can just go and do this.... with absolutely no credentials or cooperation by other responsible parties who are administering that database.[/sarcasm]
FWIW, that sort of situation is precisely why I would *NOT* give any would-be robbers access to my banking information.... they can just up and murder you anyways, so why would I want to give my potential would-be killers any money?
People who are willing to rob you are almost certainly no less likely to be also be willing to lie to you about not hurting you if you cooperate.
Point being that you need somebody's cooperation who administrates that database.
What evidence is there that the private information associated with these RFID's is equally accessible to anybody who can just walk in and ask who something belongs to?
No... more like 'rfid #xyz is located at xx-xx". In other words, absolutely no personal identifying information at all.... you have to look up atht serial number in the database of the company that is actually tracking that particular rfid to get access to that information.
Which, if you think is so easy, why don't you go ahead and see how simple it is to find out somebody's address from their license plate without police cooperation?
I mean, if you have an RFID chip, wouldn't it be detecting that it's being read whenever it passes near *ANY* scanner, whether or not the people who operate the scanner are actually even interested in that RFID? All someone else would know, in general, is that the RFID isn't one that they are trying to track, and I'd imagine at *MOST* they may be able to know which company was tracking that RFID (although I'm not even sure they could do that). And even then, without access to the other company's database of users they would have no way to know who it was who had that RFID or any other personal information.
Actually it probably has no identifying details at all... it's almost certainly just a serial number, and that's it. It may also have a checksum on the device that might be derivable via a one-way hash from personal information that the company has about you, but in general this would not be practical to try to reverse, Such a checksum id could potentially be used to verify at their end that the device was not a forgery.
The company that collects the data on the device has your identifying details and has recorded which device, by serial number, they assigned to you. Whenever they are scanning the device, all they need to do is look up its serial number in their database to get all of your identifying information that they have... unless somebody else had suitable access to that same database, they would not generally be able to identify who you were or anything else about you for that matter.
A third party could, however, potentially use the information even without access to said database to track where it was you were going... although as far as they are concerned, they'd be tracking some anonymous device, with no idea in general who actually has it... only knowing where it was detected by scanners.
>blockquote>I have given you a tiger-repelling rock. The reason you can't see any tigers is because the rock works. Should you be attacked by a tiger, it is your fault the rock didn't work. In such a situation, please find a tiger and operate the rock correctly.
False analogy, there is nothing inherent in the geological formation of rocks that could even in theory, while keeping commensurate with known laws of physics, keep away such creatures.
The TSA's measures, annoying as they may be, at least in theory are supposed to actually deter and prevent terrorist attacks, and given that's pretty much their entire reason for existing, it is not outside of reason to speculate that the TSA's measures have had some positive influence in this regard.
Not that I think that their additional measures are worth the inconveniences that are caused... I'm only pointing out that it's logically flawed to say that they have foiled *zero* terrorist efforts, which was the only point to which I had originally responded.
Except, of course, that == is already an identity comparison operation. This would be fine if you were designing a language from scratch. It's anything but if you are wanting backward compatibility.
The problem I would have with making == check for content similarity is that there are really two different notions of equality, one of which is to compare only the content of the two objects and the other compares the identity of the objects. If == were to ever mean comparing their content, then there would be absolutely *no* means for comparing identity. This may be perfecty acceptable in a lot of circumstances, but imposing that limitation upon a programmer by making that trait part of the language ultimately makes the language less useful.
On the subject of operator overloading, having to call isEquals instead of using an operator like == to compare Strings is one characteristic of the language that never really bothered me in the slightest... but that may be only because it reads like what the function is actually doing, (that is, it seems fairly obvious to me from the name itself that it would test for equality between the object and the parameter to the function, and not do anything else).
But having to type somethiing like a.plus(b).times(t).plus(a.plus(b).times(1-t)) instead of (a+b)*t+(a+b)*(1-t), for example, is very annoying. The function specification loses a lot of the notion of exact precedence, and particularly annoying to myself, it does not even *read* the same as the version described with math the formula.
The latter problem could be somewhat abated by renaming.add() to.plus(),.multiply to.times(), and so on... but then one would be using an inconsistent naming convention to operating with mathematical structures, since the numeric types that come with the java framwork, such as BigInteger, use the function names.add(),.multiply(), etc. Even more annoying, however, and to a certain extent regardless of what naming convention is utilized, it is not immediately obvious from the function name whether the function modifies the state of the object it is operating on, or if it returns a completely different one, whereas with mathematical notation, the stateless nature of the operators is explicit in the notion of understanding what the operators mean mathematically. If one wanted both functions... one to modify the state of the object, and another to return a new one, one is forced to adopt a particular naming policy which may not necessarily be intuitive for other programmers who might have to read the code to differentiate them.
And far from being a contrived complex example that would be useful in a small domain of programs, the formula that I described above is actually an extremely common one which can be used for doing a linear interpolation between the values of a and b, whatever their types may be, whether scalars, vectors or almost any other type of mathematical structure, and the pattern is extremely common in animation code.
And using custom overloaded operators for appropriately defined classes that mimic ring or group-like structures is significantly more concise than calling named methods, and reads much more intuitively.... yet the syntactic convenience of such notation is not considered sufficient merit to add it to the language.
Yet somehow the syntactic convenience of lambdas is considered sufficient merit over anon classes to add that.
This is probably true... but the poster to whom I responded suggested the TSA haven't stopped any... to which I alleged that there is insufficient basis to conclude such a point.
It doesn't necessarily imply that any plots were foiled, but given that is part of the TSA's intended function, the absence of any evidence that they have foiled any such plots in particular has a perfectly plausible explanation that fits in very naturally with how people view their surroundings when things are operating as intended.
Apples and oranges... foiling ufo invasions is not a part of my expected function.
My point, you see, is that when a system is operating as intended, the very fact that it is doing anything useful actually ends up being completely invisible to people around it.... it's the failures that people notice - when things go wrong, and the inconveniences caused by the TSA's operation are examples of that.
But the intended function of the TSA's function is security... and it's to be expected that if they are performing that duty well enough, that there would be little to no reason for anyone to ever be aware that they were doing anything useful in that regard unless one actually had a behind-the-scenes view in the first place.
So given that there's a perfectly plausible explanation for why we aren't seeing any reports about all the terrorist plots that the TSA may have foiled, the absence of such stories is not sufficient logical basis to presume that no such events have ever occurred. I'm not saying that it happens often, but it's not logically justifiable to conclude that they haven't done any good at all.
Not that I think the good they may have done was worth all the shit they've been pulling... not for one instant. I'd speculate that there's nothing that the TSA might have stopped since 9/11 which passengers would not also have, given how 9/11 has forever altered the mindset of fliers with regards to their chances of survival if they just go along with the hijacker.
I never once said that it must be working... I only said that given the stated intended purpose for it, and in particular the natural tendency to not necessarily recognize the operation of a system that *IS* actually working as intended, the absence of evidence that it is working is not sufficient logical basis to presume that it is *NOT* working.
Actually, they might have foiled a terrorist plot without our ever finding out about it, because if or when a system is working as intended, the tendency is only natural to not notice what it is doing. The lack of any evidence to show that they have foiled any terrorist effort, therefore, is logically insufficient basis to presume that they have not actually possibly done so. You may be right, but since stopping such things is what they are supposed to do, there's no way to be certain, if only by their very presence, that they are not having some impact. (Indeed, technically only definitive ineffectiveness can be shown if or when a terrorist attempt that in hindsight should have been detected by the systems in place occurs).
You'll get no argument from me on your other points, however.
Whether or not Java was billed as a number crunching platform doesn't change the fact that such number crunching can often be fundamental to the underlying model to some pretty common and often surprisingly useful stuff, especially in the realm of computer graphics, but it arises in a handful of other domains as well. This phenomenon occurs as often as it does because at it's core, all computer programs *ARE* just math.
Or are you suggesting that Java wasn't ever supposed to be used for doing computer graphics either?
And so a linguistic means that manipulates such necessary and often quite customized mathematical constructs in a concise and intuitive way would therefore inevitably be very useful. Whether or not the JVM performs such computations as efficiently at run time as a language designated for hard-core number crunching would is less of an issue than whether or not those computations are easy to read and understand at a source-code level.
Lambdas do nothing but offer a syntactic convenience beyond what was already possible in Java. I recognize that this is a significant issue however, and I don't mean to downplay it's importance, but it's equally the case that operator overloading is not really anything but a syntactic convenience either.
Hey... If its good enough for mathematical ring or group structures to have to explicitly spell it out instead of using arguably much more intuitive math operators, why should having to use anon classes instead of lambdas be any different?
Clearly, you only read the subject line of my post and not the body. The crux of my question was that if the significant syntactic convenience of operator overloading was claimed to not be a sufficient reason to add that to the language then why should it have been sufficient to justify adding lambdas?
I mean, I get that it's a lot simpler to define now, but I don't really get the point of adding such a major syntax-changing feature to the language for the sole purpose of syntactic convenience.
I mean.... wasn't that their whole main argument against operator overloading? (the other argument, that operator overloading makes for unreadable code can be shown to be a red herring).
The messiness of diamond inheritance is at least made unambiguous with the approach taken in Java8 in that a function implementation from a a superclass would be preferred to a matching function definition in an interface. Pretty much the way things are right now.
Slashdot Mirror
What I don't get about this is what's so horribly wrong with a captain abandoning the ship?
I mean, seriously.... do they expect a captain to just go down with the ship and simply die if something entirely unexpected happens to the ship?
And of course, anybody can just go and do this.... with absolutely no credentials or cooperation by other responsible parties who are administering that database.[/sarcasm]
FWIW, that sort of situation is precisely why I would *NOT* give any would-be robbers access to my banking information.... they can just up and murder you anyways, so why would I want to give my potential would-be killers any money?
People who are willing to rob you are almost certainly no less likely to be also be willing to lie to you about not hurting you if you cooperate.
Careful there... you actually just might be right about some of those...
What evidence is there that the private information associated with these RFID's is equally accessible to anybody who can just walk in and ask who something belongs to?
How will you find out who it is, exactly?
Do you know the name of the person driving in front of your car simply by looking at their license plate?
And just how much work is it to find out the name of that person without police cooperation?
No... more like 'rfid #xyz is located at xx-xx". In other words, absolutely no personal identifying information at all.... you have to look up atht serial number in the database of the company that is actually tracking that particular rfid to get access to that information.
Which, if you think is so easy, why don't you go ahead and see how simple it is to find out somebody's address from their license plate without police cooperation?
I mean, if you have an RFID chip, wouldn't it be detecting that it's being read whenever it passes near *ANY* scanner, whether or not the people who operate the scanner are actually even interested in that RFID? All someone else would know, in general, is that the RFID isn't one that they are trying to track, and I'd imagine at *MOST* they may be able to know which company was tracking that RFID (although I'm not even sure they could do that). And even then, without access to the other company's database of users they would have no way to know who it was who had that RFID or any other personal information.
Actually it probably has no identifying details at all... it's almost certainly just a serial number, and that's it. It may also have a checksum on the device that might be derivable via a one-way hash from personal information that the company has about you, but in general this would not be practical to try to reverse, Such a checksum id could potentially be used to verify at their end that the device was not a forgery.
The company that collects the data on the device has your identifying details and has recorded which device, by serial number, they assigned to you. Whenever they are scanning the device, all they need to do is look up its serial number in their database to get all of your identifying information that they have... unless somebody else had suitable access to that same database, they would not generally be able to identify who you were or anything else about you for that matter.
A third party could, however, potentially use the information even without access to said database to track where it was you were going... although as far as they are concerned, they'd be tracking some anonymous device, with no idea in general who actually has it... only knowing where it was detected by scanners.
False analogy, there is nothing inherent in the geological formation of rocks that could even in theory, while keeping commensurate with known laws of physics, keep away such creatures.
The TSA's measures, annoying as they may be, at least in theory are supposed to actually deter and prevent terrorist attacks, and given that's pretty much their entire reason for existing, it is not outside of reason to speculate that the TSA's measures have had some positive influence in this regard.
Not that I think that their additional measures are worth the inconveniences that are caused... I'm only pointing out that it's logically flawed to say that they have foiled *zero* terrorist efforts, which was the only point to which I had originally responded.
Except, of course, that == is already an identity comparison operation. This would be fine if you were designing a language from scratch. It's anything but if you are wanting backward compatibility.
The problem I would have with making == check for content similarity is that there are really two different notions of equality, one of which is to compare only the content of the two objects and the other compares the identity of the objects. If == were to ever mean comparing their content, then there would be absolutely *no* means for comparing identity. This may be perfecty acceptable in a lot of circumstances, but imposing that limitation upon a programmer by making that trait part of the language ultimately makes the language less useful.
On the subject of operator overloading, having to call isEquals instead of using an operator like == to compare Strings is one characteristic of the language that never really bothered me in the slightest... but that may be only because it reads like what the function is actually doing, (that is, it seems fairly obvious to me from the name itself that it would test for equality between the object and the parameter to the function, and not do anything else).
But having to type somethiing like a.plus(b).times(t).plus(a.plus(b).times(1-t)) instead of (a+b)*t+(a+b)*(1-t), for example, is very annoying. The function specification loses a lot of the notion of exact precedence, and particularly annoying to myself, it does not even *read* the same as the version described with math the formula.
The latter problem could be somewhat abated by renaming .add() to .plus(), .multiply to .times(), and so on... but then one would be using an inconsistent naming convention to operating with mathematical structures, since the numeric types that come with the java framwork, such as BigInteger, use the function names .add(), .multiply(), etc. Even more annoying, however, and to a certain extent regardless of what naming convention is utilized, it is not immediately obvious from the function name whether the function modifies the state of the object it is operating on, or if it returns a completely different one, whereas with mathematical notation, the stateless nature of the operators is explicit in the notion of understanding what the operators mean mathematically. If one wanted both functions... one to modify the state of the object, and another to return a new one, one is forced to adopt a particular naming policy which may not necessarily be intuitive for other programmers who might have to read the code to differentiate them.
And far from being a contrived complex example that would be useful in a small domain of programs, the formula that I described above is actually an extremely common one which can be used for doing a linear interpolation between the values of a and b, whatever their types may be, whether scalars, vectors or almost any other type of mathematical structure, and the pattern is extremely common in animation code.
And using custom overloaded operators for appropriately defined classes that mimic ring or group-like structures is significantly more concise than calling named methods, and reads much more intuitively.... yet the syntactic convenience of such notation is not considered sufficient merit to add it to the language.
Yet somehow the syntactic convenience of lambdas is considered sufficient merit over anon classes to add that.
Go figure.
This is probably true... but the poster to whom I responded suggested the TSA haven't stopped any... to which I alleged that there is insufficient basis to conclude such a point.
It doesn't necessarily imply that any plots were foiled, but given that is part of the TSA's intended function, the absence of any evidence that they have foiled any such plots in particular has a perfectly plausible explanation that fits in very naturally with how people view their surroundings when things are operating as intended.
Apples and oranges... foiling ufo invasions is not a part of my expected function.
My point, you see, is that when a system is operating as intended, the very fact that it is doing anything useful actually ends up being completely invisible to people around it.... it's the failures that people notice - when things go wrong, and the inconveniences caused by the TSA's operation are examples of that.
But the intended function of the TSA's function is security... and it's to be expected that if they are performing that duty well enough, that there would be little to no reason for anyone to ever be aware that they were doing anything useful in that regard unless one actually had a behind-the-scenes view in the first place.
So given that there's a perfectly plausible explanation for why we aren't seeing any reports about all the terrorist plots that the TSA may have foiled, the absence of such stories is not sufficient logical basis to presume that no such events have ever occurred. I'm not saying that it happens often, but it's not logically justifiable to conclude that they haven't done any good at all.
Not that I think the good they may have done was worth all the shit they've been pulling... not for one instant. I'd speculate that there's nothing that the TSA might have stopped since 9/11 which passengers would not also have, given how 9/11 has forever altered the mindset of fliers with regards to their chances of survival if they just go along with the hijacker.
I never once said that it must be working... I only said that given the stated intended purpose for it, and in particular the natural tendency to not necessarily recognize the operation of a system that *IS* actually working as intended, the absence of evidence that it is working is not sufficient logical basis to presume that it is *NOT* working.
Actually, they might have foiled a terrorist plot without our ever finding out about it, because if or when a system is working as intended, the tendency is only natural to not notice what it is doing. The lack of any evidence to show that they have foiled any terrorist effort, therefore, is logically insufficient basis to presume that they have not actually possibly done so. You may be right, but since stopping such things is what they are supposed to do, there's no way to be certain, if only by their very presence, that they are not having some impact. (Indeed, technically only definitive ineffectiveness can be shown if or when a terrorist attempt that in hindsight should have been detected by the systems in place occurs).
You'll get no argument from me on your other points, however.
Whether or not Java was billed as a number crunching platform doesn't change the fact that such number crunching can often be fundamental to the underlying model to some pretty common and often surprisingly useful stuff, especially in the realm of computer graphics, but it arises in a handful of other domains as well. This phenomenon occurs as often as it does because at it's core, all computer programs *ARE* just math.
Or are you suggesting that Java wasn't ever supposed to be used for doing computer graphics either?
And so a linguistic means that manipulates such necessary and often quite customized mathematical constructs in a concise and intuitive way would therefore inevitably be very useful. Whether or not the JVM performs such computations as efficiently at run time as a language designated for hard-core number crunching would is less of an issue than whether or not those computations are easy to read and understand at a source-code level.
Lambdas do nothing but offer a syntactic convenience beyond what was already possible in Java. I recognize that this is a significant issue however, and I don't mean to downplay it's importance, but it's equally the case that operator overloading is not really anything but a syntactic convenience either.
Hey... If its good enough for mathematical ring or group structures to have to explicitly spell it out instead of using arguably much more intuitive math operators, why should having to use anon classes instead of lambdas be any different?
it's the inconsistency that I don't understand
I mean.... wasn't that their whole main argument against operator overloading? (the other argument, that operator overloading makes for unreadable code can be shown to be a red herring).
The messiness of diamond inheritance is at least made unambiguous with the approach taken in Java8 in that a function implementation from a a superclass would be preferred to a matching function definition in an interface. Pretty much the way things are right now.