I presume then that you would be against any kind of general purpose computing platform as wearable tech that could provide an immersive augmented reality system, because it also contains a camera (which is necessary to provide an augmented reality that seamlessly blends with the physical surroundings) that could also conceivably be used to record people's activities, and would not require any sort of "conscious action" like holding something in your hand to utilize. Consider that the fact that it wouldn't require any kind of explicit and outwardly obvious action like being held in your hand is actually the entire point of wearable tech.
Which would suggest to me that you are probably just opposed to the idea of wearable tech in general.
Small children can sometimes fall out of an adult's peripheral vision, if they are concentrating on what is further ahead of them rather than on what happens to be on or near ground-level of otherwise familiar territory. This has actually happened to me, and I stopped immediately, as I realized I had not seen whatever it was that I would have otherwise walked right on top of. Fortunately for me, the child was not seriously hurt, but was largely startled by what had happened, and the parents were thankfully not vindictive. Of course, this robot also stayed on its course, which may have led to injuries being more serious than if it had stopped immediately upon contact, as I did.
Oh, and to answer your question... yes. Because if it such usage became pervasive as pokemon go seems to have, people would be more likely to think people using it are just using an augmented reality application more than they were interested in invading other people's privacy.
How many people do you see assaulting people using pokemon go? That's got its camera on all the time too.... it's just as likely to record people, but nobody calls pokemon go players derisive comments like glassholes for google glass users.
I wonder if it could have been the killer app for google glass... if people hadn't been so freaked out about privacy that they would assault anyone wearing one.
./*you can't just use c from the database because it's often incorrect, so calculate it from scratch*/
Indeed, and this is an example of what I would call a good comment. But what a code fragment does, and why, should ideally be so self-evidently clear from the function names that it calls and the names of the entities that it uses or manipulates that additional comments ought to hardly ever otherwise be required. Variable names and other identifiers can easily be long enough in modern languages to be descriptive about what the corresponding entity is and often why it exists at all that code which uses good naming practices from the ground up will rarely need any actual comments to explain them. With decent variable and identifier completion found in modern development environments, long variable names do not even have to be the source of typographical errors.
I mentioned this example in another comment, but I'm particularly fond of it because it illustrates an important aspect of how comments are used.
Consider the following conditional statement:
if ((employee.flags & HOURLY_FLAG) && (employee.age > 65))...
Now by itself, this isn't very clear, so it might need a comment above it:
// Check to see if the employee is eligible for full benefits if (!(employee.flags & HOURLY_FLAG) && (employee.age > 65))...
Okay, so now it is more obvious what the conditional is there for, but this can be refactored to eliminate the comment completely:
if (employee.isEligibleForBenefits())...
So now the conditional is clear without a comment.
So what about the logic of isEligibleForBenefits? Wouldn't that still need some comments? Well, first of all, in the implementation of the 'isEligibleForBenefits', you don't need a redundant comment explaining that it tells you whether the employee is eligible for benefits because the function name itself already tells you that. Secondly, one could refactor its logic as follows:
Where isPaidHourly and isLegalSenior are both bool functions that simply return results like what was given in the two conditions above. Since the name of each function describes what is appropriate condition is for, and they are individually very simple one-line functions whose purpose is obvious from the name and behavior is so immediately self-evident from the simplicity of the code that there is no need to add any further comments.
And by adding 'inline' to each these function definitions, you aren't even incurring the runtime penalty of a function call... any respectable optimizing compiler will make it efficient, and the resulting code is just as readable, arguably moreso, and without a single comment in the bunch.
One might be compelled to ask if it would not be easier to just add a one-line comment to the original than to bother with all of that refactoring.
To that I would say undoubtably... but the remaining problem with comments is that they can lie. Code can easily evolve from its original implementation, and where the changes at each iteration are individually so tiny that one does not necessarily remember they need to also update the comment... especially if different stages of the modification are being done separately by many people over a course of many months. Since compilers rarely check comments for semantic validity, you may be left with the documentation of your code found in the comment reflecting something other than what the code actually does, potentially costing the developer who must maintain it far more
I am suggesting by that they should not be taking the results of this referendum as a definitive representation of what the majority of its citizens want because the winning margin was so tiny... Several times smaller even than the number that could have but didn't vote. Given the voted turnout of 75%, I don't think a winning vote of less than about 60 to 65 percent should have been taken as finally decisive.
It would have been equally inconclusive if the vote had gone the other way with the results this close.
// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) && employee.age>65)...
vs
if (isEmployeeEligibleForBenefits(&empoyee))...
The comment in the former case is arguably neccessary to explain why the condition is there, but why becomes self-evident in the second case... because the function is already named something clear, a comment should not even be be necessary at the function definition, the prototype for which would look something like:
bool isEmployeeEligibleForBenefits(employee_t *);
Comments are useful for explaning intent behind design decisions, for example:
int compareTwoElements(elem_t *lhs, elem_t *rhs)
{
if (is_string(lhs) && !is_string(rhs)) {
return -1;// strings are less than everything else
} ... }
(Okay.... I tried using to indent that cleanly.... not sure why they aren't showing up)
Anyways.... my point is not that comments are never necessary, but more often than not they are used to clarify code that has not been written as clearly as it could have otherwise been. In my experience, comments still have their uses, but in practice, they are actually fairly few and far between.
I didn't say I don't write comments, I said comments should be theoretically unnecessary. They are an admission of failure on the part of the programmer that they have not made their code clear enough to be self-explanatory.
Agreed. Which is why it is best to write code whose functionality is self evident from the names of the functions it calls and identifiers it uses. If the code is clear, comments are superfluous, and largely unnecessary.
If you claim you don't find the threat of being ambushed, stalked, sniped, or just plain shot/stabbed in a rageâ"by an armed and intelligent human being who *wants to kill you*â"more frightening than a faceless and non-malevolent risk of *accidental* machine/tree/landslide/car accident/etc. death, then I don't think there is anything left to discuss here
I'd like to answer that by considering the following (rhetorical) question: If fear can be argued to be a genuinely useful survival mechanism that we have evolved to rapidly recognize and avoid threats, how rational is it to be more afraid of something that is less likely to kill you than something that is far more likely to do so?
Of course, human beings aren't particularly rational anyways, especially when it comes to things like fear, but how irrationally we might be more afraid of someone who wants to kill us than of an accidental death that is several times more likely is not a logically sustainable basis to suggest that the job that puts one in the former position is necessarily more dangerous. because how dangerous a job might be is not measured by how afraid someone might be of the threats of the job, however frightening they might be, but solely by how statistically likely it is that one gets killed doing that job.
This should not be interepreted as a suggestion that cops should necessarily be any less afraid of the hazards of their job than they are... fear is subjective, and as I said, it's a healthy survival mechanism. Without it, they may even end up dead far more often than they statistcally do.
But the post to which I initially responded appeared to suggest that the hazards of police work, which one may entirely reasonably have more of an instinctive fearful reaction to, should somehow mean that the job is necessarily more dangerous than others where one is actually much more likely to get killed, and that is the point that I took exception to.
I don't know how it got interpreted that I was suggesting that cops should not have any right to be afraid of the threats they might face, because that is most certainly not what I meant.
... why they are doing this. Sure, more than 50% voted for it, but it didn't even get 52% of the vote, and while 48.2% against is technically a minority, it's one mother of a fucking huge one. If voter turnout had been within a heck of a lot closer to a hundred percent then I could see allowing this to pass with such a slim margin, but with only 75% turnout, I see results this close as being about as inconclusive as if it had actually been a pure tie vote.
... an augmented reality type of application, so you could use the iphone screen to watch where you are walking, keeping your head up and seeing where you are going, while still catching a peripheral view of things in front of you to either side of your phone.
Hololens would probably be a very good platform for it as well.
While it is correct that it did not do that... it *COULD* have, had it been written to do so, because it received permissions to do so, despite not using them.
Under most circumstances, such a termination would be grounds to not receive any employment insurance benefits, or at least delay them pending an investigation to see if there was any wrongdoing on the employee's part that deserved dismissal (in which case they are not eligible for benefits).
I was once fired for reasons that were not my fault and it delayed my benefits by almost a month. Sucked, royally.
I thought the point yvan256 was trying to make was that of the imac series, *ONLY* the 27" retina models have had upgradable ram. I wasn't contesting the 27 inches part, only the retina part. I don't actually know if apple still makes a non-retina 27" imac anymore, to be honest.
I wasn't proposing anything to "fix" an alleged problem. While it's almost certainly true that the likelihood of getting murdered doing policework is much higher higher than the chance of being murdered working in the logging industry, the accidental death rate in the latter is so much higher as to *completely* offset that measurement of overall job danger. And when the end result is same: you die, what difference does the cause of death make with regards to determining how dangerous that job really is?
No... that is not what I am saying at all.
p.
My point was that it was noted above that police work is not even in the top ten most dangerous jobs, as measured by fatality incidents... and a followup poster appeared to contest the notion, by raising the fact that police might have to put themselves in particular situations that are obviously recognized even to a layperson as life-threatening, such as possibly getting shot. My "what difference does it make?" remark was driven by the fact that those points do not somehow cause police work to be more dangerous than it already statistically is when you are measuring how dangerous a job is by how many fatalities it causes in the first place. While police officers may put themselves in situations that may be obviously viewed as dangerous, and my "what difference does it make?" remark was certainly not intended to sound flippant towards those who would put themselves in harms way in the interests of upholding the law and to protect innocent people, going strictly by the number of fatalities, those efforts do not change the fact that the number of police officer fatalities doesn't even place police work in the top ten most dangerous jobs.
And you conveniently sidestepped the point that function definitions are not what APIs are in the first place. APIs are determined by function declarations, which do not generate any code at all. As you noted, they are a communication tool for programmers, and provide a mechanism for error checking for compilers, but the API itself does not actually do any error checking any more than a phone book with your name in it is what makes your phone ring when somebody calls you.
Actually,. my point was that the argument that police might somehow be required as part of their duties to engage in activities that are commonly recognized as life threatening to even a layperson does not somehow cause police work to actually be any more life threatening than it actually is relative to those other professions listed, which are actually statistically *MORE* deadly. The fact that police may have to do such things is entirely irrelevant to the issue of how deadly it actually is compared to the deadlier professions that do not require such activities. Hence: "what difference does it make"? Answer: none.
Slashdot Mirror
I presume then that you would be against any kind of general purpose computing platform as wearable tech that could provide an immersive augmented reality system, because it also contains a camera (which is necessary to provide an augmented reality that seamlessly blends with the physical surroundings) that could also conceivably be used to record people's activities, and would not require any sort of "conscious action" like holding something in your hand to utilize. Consider that the fact that it wouldn't require any kind of explicit and outwardly obvious action like being held in your hand is actually the entire point of wearable tech.
Which would suggest to me that you are probably just opposed to the idea of wearable tech in general.
Small children can sometimes fall out of an adult's peripheral vision, if they are concentrating on what is further ahead of them rather than on what happens to be on or near ground-level of otherwise familiar territory. This has actually happened to me, and I stopped immediately, as I realized I had not seen whatever it was that I would have otherwise walked right on top of. Fortunately for me, the child was not seriously hurt, but was largely startled by what had happened, and the parents were thankfully not vindictive. Of course, this robot also stayed on its course, which may have led to injuries being more serious than if it had stopped immediately upon contact, as I did.
Oh, and to answer your question... yes. Because if it such usage became pervasive as pokemon go seems to have, people would be more likely to think people using it are just using an augmented reality application more than they were interested in invading other people's privacy.
How many people do you see assaulting people using pokemon go? That's got its camera on all the time too.... it's just as likely to record people, but nobody calls pokemon go players derisive comments like glassholes for google glass users.
I wonder if it could have been the killer app for google glass... if people hadn't been so freaked out about privacy that they would assault anyone wearing one.
Indeed, and this is an example of what I would call a good comment. But what a code fragment does, and why, should ideally be so self-evidently clear from the function names that it calls and the names of the entities that it uses or manipulates that additional comments ought to hardly ever otherwise be required. Variable names and other identifiers can easily be long enough in modern languages to be descriptive about what the corresponding entity is and often why it exists at all that code which uses good naming practices from the ground up will rarely need any actual comments to explain them. With decent variable and identifier completion found in modern development environments, long variable names do not even have to be the source of typographical errors.
I mentioned this example in another comment, but I'm particularly fond of it because it illustrates an important aspect of how comments are used.
Consider the following conditional statement:
Now by itself, this isn't very clear, so it might need a comment above it:
Okay, so now it is more obvious what the conditional is there for, but this can be refactored to eliminate the comment completely:
So now the conditional is clear without a comment.
So what about the logic of isEligibleForBenefits? Wouldn't that still need some comments? Well, first of all, in the implementation of the 'isEligibleForBenefits', you don't need a redundant comment explaining that it tells you whether the employee is eligible for benefits because the function name itself already tells you that. Secondly, one could refactor its logic as follows:
Where isPaidHourly and isLegalSenior are both bool functions that simply return results like what was given in the two conditions above. Since the name of each function describes what is appropriate condition is for, and they are individually very simple one-line functions whose purpose is obvious from the name and behavior is so immediately self-evident from the simplicity of the code that there is no need to add any further comments.
And by adding 'inline' to each these function definitions, you aren't even incurring the runtime penalty of a function call... any respectable optimizing compiler will make it efficient, and the resulting code is just as readable, arguably moreso, and without a single comment in the bunch.
One might be compelled to ask if it would not be easier to just add a one-line comment to the original than to bother with all of that refactoring.
To that I would say undoubtably... but the remaining problem with comments is that they can lie. Code can easily evolve from its original implementation, and where the changes at each iteration are individually so tiny that one does not necessarily remember they need to also update the comment... especially if different stages of the modification are being done separately by many people over a course of many months. Since compilers rarely check comments for semantic validity, you may be left with the documentation of your code found in the comment reflecting something other than what the code actually does, potentially costing the developer who must maintain it far more
It would have been equally inconclusive if the vote had gone the other way with the results this close.
The funny thing is, however, those cases do not happen that often in practice
Consider the following code snippet:
if ((employee.flags & HOURLY_FLAG) && employee.age>65)
vs
if (isEmployeeEligibleForBenefits(&empoyee))...
The comment in the former case is arguably neccessary to explain why the condition is there, but why becomes self-evident in the second case... because the function is already named something clear, a comment should not even be be necessary at the function definition, the prototype for which would look something like: bool isEmployeeEligibleForBenefits(employee_t *);
Comments are useful for explaning intent behind design decisions, for example:
int compareTwoElements(elem_t *lhs, elem_t *rhs) // strings are less than everything else
...
{
if (is_string(lhs) && !is_string(rhs)) {
return -1;
}
}
(Okay.... I tried using to indent that cleanly.... not sure why they aren't showing up)
Anyways.... my point is not that comments are never necessary, but more often than not they are used to clarify code that has not been written as clearly as it could have otherwise been. In my experience, comments still have their uses, but in practice, they are actually fairly few and far between.
I didn't say I don't write comments, I said comments should be theoretically unnecessary. They are an admission of failure on the part of the programmer that they have not made their code clear enough to be self-explanatory.
Agreed. Which is why it is best to write code whose functionality is self evident from the names of the functions it calls and identifiers it uses. If the code is clear, comments are superfluous, and largely unnecessary.
What if both the windows computer and the printer are behind the NAT?
Even through a NAT?
I'd like to answer that by considering the following (rhetorical) question: If fear can be argued to be a genuinely useful survival mechanism that we have evolved to rapidly recognize and avoid threats, how rational is it to be more afraid of something that is less likely to kill you than something that is far more likely to do so?
Of course, human beings aren't particularly rational anyways, especially when it comes to things like fear, but how irrationally we might be more afraid of someone who wants to kill us than of an accidental death that is several times more likely is not a logically sustainable basis to suggest that the job that puts one in the former position is necessarily more dangerous. because how dangerous a job might be is not measured by how afraid someone might be of the threats of the job, however frightening they might be, but solely by how statistically likely it is that one gets killed doing that job.
This should not be interepreted as a suggestion that cops should necessarily be any less afraid of the hazards of their job than they are... fear is subjective, and as I said, it's a healthy survival mechanism. Without it, they may even end up dead far more often than they statistcally do.
But the post to which I initially responded appeared to suggest that the hazards of police work, which one may entirely reasonably have more of an instinctive fearful reaction to, should somehow mean that the job is necessarily more dangerous than others where one is actually much more likely to get killed, and that is the point that I took exception to.
I don't know how it got interpreted that I was suggesting that cops should not have any right to be afraid of the threats they might face, because that is most certainly not what I meant.
... why they are doing this. Sure, more than 50% voted for it, but it didn't even get 52% of the vote, and while 48.2% against is technically a minority, it's one mother of a fucking huge one. If voter turnout had been within a heck of a lot closer to a hundred percent then I could see allowing this to pass with such a slim margin, but with only 75% turnout, I see results this close as being about as inconclusive as if it had actually been a pure tie vote.
Hololens would probably be a very good platform for it as well.
While it is correct that it did not do that... it *COULD* have, had it been written to do so, because it received permissions to do so, despite not using them.
I was once fired for reasons that were not my fault and it delayed my benefits by almost a month. Sucked, royally.
I thought the point yvan256 was trying to make was that of the imac series, *ONLY* the 27" retina models have had upgradable ram. I wasn't contesting the 27 inches part, only the retina part. I don't actually know if apple still makes a non-retina 27" imac anymore, to be honest.
I have an iMac from before the retina displays were even available, and I upgraded the ram in my system without any issue.
I wasn't proposing anything to "fix" an alleged problem. While it's almost certainly true that the likelihood of getting murdered doing policework is much higher higher than the chance of being murdered working in the logging industry, the accidental death rate in the latter is so much higher as to *completely* offset that measurement of overall job danger. And when the end result is same: you die, what difference does the cause of death make with regards to determining how dangerous that job really is?
Better yet, the default behavior should be a configurable option in browser preferences. Make it an end-user choice.
No... that is not what I am saying at all. p. My point was that it was noted above that police work is not even in the top ten most dangerous jobs, as measured by fatality incidents... and a followup poster appeared to contest the notion, by raising the fact that police might have to put themselves in particular situations that are obviously recognized even to a layperson as life-threatening, such as possibly getting shot. My "what difference does it make?" remark was driven by the fact that those points do not somehow cause police work to be more dangerous than it already statistically is when you are measuring how dangerous a job is by how many fatalities it causes in the first place. While police officers may put themselves in situations that may be obviously viewed as dangerous, and my "what difference does it make?" remark was certainly not intended to sound flippant towards those who would put themselves in harms way in the interests of upholding the law and to protect innocent people, going strictly by the number of fatalities, those efforts do not change the fact that the number of police officer fatalities doesn't even place police work in the top ten most dangerous jobs.
And you conveniently sidestepped the point that function definitions are not what APIs are in the first place. APIs are determined by function declarations, which do not generate any code at all. As you noted, they are a communication tool for programmers, and provide a mechanism for error checking for compilers, but the API itself does not actually do any error checking any more than a phone book with your name in it is what makes your phone ring when somebody calls you.
Actually,. my point was that the argument that police might somehow be required as part of their duties to engage in activities that are commonly recognized as life threatening to even a layperson does not somehow cause police work to actually be any more life threatening than it actually is relative to those other professions listed, which are actually statistically *MORE* deadly. The fact that police may have to do such things is entirely irrelevant to the issue of how deadly it actually is compared to the deadlier professions that do not require such activities. Hence: "what difference does it make"? Answer: none.