Latin dictionaries usually list the first person singular of verbs, rather than the infinitive, so in a dictionary you'll likely find quaero for 'to search', rather than the technically correct quaerere.
The quote of mine you're responding to is simply stating that the rational, agnostic default position, for anything, is to assume that a claim is false until there is reason to believe it is so.
"What makes someone atheist is not believing in God(s). As it happens this is the default position of someone who is not religious, as without observed evidence of logical proof, it is irrational to believe in God(s)."
No, you definitely said atheist.
By the principle of bivalence (that if any claim is false, its negation is true), if you don't believe something is so, you're assuming (though not as a matter of faith; just a tentative assumption) that it's not so.
This is simply not true. One simple example: take a random planet, one that you have not ever seen. Do you believe it is blue? Do you believe it is red? Do you believe it is green? Do you believe it is white? I'm guessing you'd say no to all, but that you'd not assume it's none of those colours either.
More to the point, it's possible to be agnostic and not make assumptions either way about the existence of God.
There is a way of proving something doesn't exist: assume it does exist, draw conclusions from that, and if they lead to a contradiction, either the assumption is false, or your logic is flawed. In the rather simple case of invisible pink unicorns, you could say for example that invisible means it reflects no light, pink means it reflects some light, and as these contradict, either invisible pink unicorns cannot exist, or there's a flaw in my reasoning. And if you were to take out either the "invisible" or the "pink" part, no, I have no reason to believe they exist, but I'm not about to claim I'm sure they don't unless you want to get more specific.
What makes someone atheist is not believing in God(s). As it happens this is the default position of someone who is not religious, as without observed evidence of logical proof, it is irrational to believe in God(s).
I think you're confusing atheist and agnostic, the latter being the logical default position, since there's no proof God doesn't exist either.
The main difference, I think, is that Windows installers are much more often poorly written, refusing to run as a limited user. That one's not really a problem with Windows itself anymore.
I don't remember how much power that group gives you, so I'm not sure. If it's not too much -- if it keeps the core system protected -- then yes, like that.
It's mostly doable already. linuxfromscratch lists one possible way. I suppose one big problem for other distros is that a generic package manager which can handle any package will require root permissions, because some programs have a legitimate reason to be installed setuid root. For obvious reasons, non-root users can't install setuid root programs.
Why would you want to let ordinary users install packages?
You're assuming that every non-root user has exactly the same permissions. This is not the case. Allowing some users in a special group to install software without running as root might be a good idea.
Does this ruling mean that a child can go to an adult rated film, and if they get denied entry claim it breaches their First Amendment rights?
No. The First Amendment does not prevent anyone from voluntarily restricting any form of speech on their private property, it only prevents the government from restricting this by law.
for instance something with an é in it [...] and if they are in it they have to be specified using their ASCII character code
é is not an ASCII character, and several different ASCII-compatible encodings which support é represent it differently (the major ones: in the 8859-* which support it, it's e9; in UTF-8, it's c3 a9). How is it decided which encoding is actually used? Or are automatic conversions to that %xx format a bad idea?
Re:Check out Rob Pike's thoughts on code commentin
on
How to Write Comments
·
· Score: 1
You're taking the OPs comment too literally and reading too much into them. Yes, the name of a function (note that the OP draws a distinction between functions and procedures - C doesn't have such a distinction, so you have to conceptualize a little)
I did, by assuming the meaning of "procedure" and "function" was the same as in a language which uses the keywords "procedure" and "function". Silly me.
should reflect what it returns. That does not mean you use a pseudo-hungarian notation and append the return type to the name, but that the phrasing of the name should indicate the return value.
That's what I did. Adding the return type would turn waddstr into waddstr_int. waddstr_error describes the return value.
isWindowRaised() returns a boolean. getSystemSettingsAsTree() returns a tree (but is redundant and should be called getSystemSettings if that is the only way to get system settings). Procedures (ie, functions with side effects) should be named by what they do, clearly. There's a convention in C code, especially old C code, to make your function names as concise and non-literal as possible, that is a flaw (not in the language, but in the culture) and should be avoided. setWindowString is a much better name than waddstr.
That I mostly agree with.
Such functions are generally poor practice.
I think there are legitimate reasons for it. Since you don't like the map example, how about C++'s new? (Admittedly, it's not really a function, but I think it makes the point clear enough.) Normally, its return value is important, but if your class manages itself, it may actually be reasonable to discard it.
Re:Check out Rob Pike's thoughts on code commentin
on
How to Write Comments
·
· Score: 1
In C, it's a conceptual difference. The return value of waddstr isn't important and in fact exists only because C doesn't have any other convenient way of indicating an error condition. waddstr is a procedure because it has side effects.
errno's not exactly convenient, that I'll admit. Anyway, what does this then mean for functions/procedures for which either the side effect or the result can be important? For example, can Perl's map function be called a procedure when it's used as an alternative way of writing foreach?
I used to use Pascal, so for me, if you make a distinction between procedures and functions, if any value is returned, it's a function to me. If it's called for side effects, it's not suddenly a procedure, it's nothing more or less than a function with side effects.
The compat name does matter because it's exactly the point. Compact names make for hard to read code. And claiming that it should be window_add_string_returned_error just means that you are totally missing the point and don't understand the issue.
If waddstr is a function (which you don't agree with), the post I replied to basically said it should be named something like that. All I did was notice that that's what it said, and point it out in hopes of clarification (which I got).
Re:Check out Rob Pike's thoughts on code commentin
on
How to Write Comments
·
· Score: 1
waddstr is a procedure, not a function
As far as I know, the difference is that procedures don't return values, and functions do. waddstr returns a value. What's the difference according to you?
And the compact waddstr name doesn't matter; if it were named window_add_string, I would make the same point by saying that its name would need changing to window_add_string_returned_error.
Re:Check out Rob Pike's thoughts on code commentin
on
How to Write Comments
·
· Score: 1
"Procedure names should reflect what they do; function names should reflect what they return"
What about functions that simply return a success/failure indicator? Should we rename, for example, waddstr to waddstr_error?
Ah, okay, just a bunch of misunderstandings:) All I meant (and hopefully said) originally was that having that freedom is fortunate. Thanks for clearing things up.
Okay, so by how I'm reading your posts, now you've said that freedom is very important (in that message), and that it's unfortunate we have it (in your message before that). That makes no sense, so could you please explain yourself, preferably more directly? That way, if I'm misunderstanding you, I don't again.
Assuming that you treat speech and "free-as-in-speech software" the same, I don't see it. If you support others' rights to say what you disagree with, that makes it fortunate, not unfortunate, that they're allowed to speak. All it makes unfortunate is that they actually do speak.
I used to use a somewhat similar system, a Corona "portable" PC. It's got less RAM, mine didn't have a HD, and it's heavier, but it felt like a great machine at the time.:)
Slashdot Mirror
Latin dictionaries usually list the first person singular of verbs, rather than the infinitive, so in a dictionary you'll likely find quaero for 'to search', rather than the technically correct quaerere.
It wouldn't take that long, if I didn't have to type it twice!
Heh, I do too, but it's kind of nice to be able to strip sigs and only read comments relevant to the story :)
Some Hot Chick [ww.com]
Okay, what does that have to do with anything?
Which is exactly what the summary says.
The quote of mine you're responding to is simply stating that the rational, agnostic default position, for anything, is to assume that a claim is false until there is reason to believe it is so.
"What makes someone atheist is not believing in God(s). As it happens this is the default position of someone who is not religious, as without observed evidence of logical proof, it is irrational to believe in God(s)."
No, you definitely said atheist.
By the principle of bivalence (that if any claim is false, its negation is true), if you don't believe something is so, you're assuming (though not as a matter of faith; just a tentative assumption) that it's not so.
This is simply not true. One simple example: take a random planet, one that you have not ever seen. Do you believe it is blue? Do you believe it is red? Do you believe it is green? Do you believe it is white? I'm guessing you'd say no to all, but that you'd not assume it's none of those colours either.
More to the point, it's possible to be agnostic and not make assumptions either way about the existence of God.
There is a way of proving something doesn't exist: assume it does exist, draw conclusions from that, and if they lead to a contradiction, either the assumption is false, or your logic is flawed. In the rather simple case of invisible pink unicorns, you could say for example that invisible means it reflects no light, pink means it reflects some light, and as these contradict, either invisible pink unicorns cannot exist, or there's a flaw in my reasoning. And if you were to take out either the "invisible" or the "pink" part, no, I have no reason to believe they exist, but I'm not about to claim I'm sure they don't unless you want to get more specific.
What makes someone atheist is not believing in God(s). As it happens this is the default position of someone who is not religious, as without observed evidence of logical proof, it is irrational to believe in God(s).
I think you're confusing atheist and agnostic, the latter being the logical default position, since there's no proof God doesn't exist either.
The main difference, I think, is that Windows installers are much more often poorly written, refusing to run as a limited user. That one's not really a problem with Windows itself anymore.
I don't remember how much power that group gives you, so I'm not sure. If it's not too much -- if it keeps the core system protected -- then yes, like that.
It's mostly doable already. linuxfromscratch lists one possible way. I suppose one big problem for other distros is that a generic package manager which can handle any package will require root permissions, because some programs have a legitimate reason to be installed setuid root. For obvious reasons, non-root users can't install setuid root programs.
Why would you want to let ordinary users install packages?
You're assuming that every non-root user has exactly the same permissions. This is not the case. Allowing some users in a special group to install software without running as root might be a good idea.
http://emacs-chess.sourceforge.net/
Just ask me what I want... screw the surprise, at least you won't end up having paid for a game that I don't want/need.
This is why for my birthday I got a wrapped game. If I didn't like it, I could just return it.
Does this ruling mean that a child can go to an adult rated film, and if they get denied entry claim it breaches their First Amendment rights?
No. The First Amendment does not prevent anyone from voluntarily restricting any form of speech on their private property, it only prevents the government from restricting this by law.
for instance something with an é in it [...] and if they are in it they have to be specified using their ASCII character code
é is not an ASCII character, and several different ASCII-compatible encodings which support é represent it differently (the major ones: in the 8859-* which support it, it's e9; in UTF-8, it's c3 a9). How is it decided which encoding is actually used? Or are automatic conversions to that %xx format a bad idea?
You're taking the OPs comment too literally and reading too much into them. Yes, the name of a function (note that the OP draws a distinction between functions and procedures - C doesn't have such a distinction, so you have to conceptualize a little)
I did, by assuming the meaning of "procedure" and "function" was the same as in a language which uses the keywords "procedure" and "function". Silly me.
should reflect what it returns. That does not mean you use a pseudo-hungarian notation and append the return type to the name, but that the phrasing of the name should indicate the return value.
That's what I did. Adding the return type would turn waddstr into waddstr_int. waddstr_error describes the return value.
isWindowRaised() returns a boolean. getSystemSettingsAsTree() returns a tree (but is redundant and should be called getSystemSettings if that is the only way to get system settings). Procedures (ie, functions with side effects) should be named by what they do, clearly. There's a convention in C code, especially old C code, to make your function names as concise and non-literal as possible, that is a flaw (not in the language, but in the culture) and should be avoided. setWindowString is a much better name than waddstr.
That I mostly agree with.
Such functions are generally poor practice.
I think there are legitimate reasons for it. Since you don't like the map example, how about C++'s new? (Admittedly, it's not really a function, but I think it makes the point clear enough.) Normally, its return value is important, but if your class manages itself, it may actually be reasonable to discard it.
In C, it's a conceptual difference. The return value of waddstr isn't important and in fact exists only because C doesn't have any other convenient way of indicating an error condition. waddstr is a procedure because it has side effects.
errno's not exactly convenient, that I'll admit. Anyway, what does this then mean for functions/procedures for which either the side effect or the result can be important? For example, can Perl's map function be called a procedure when it's used as an alternative way of writing foreach?
I used to use Pascal, so for me, if you make a distinction between procedures and functions, if any value is returned, it's a function to me. If it's called for side effects, it's not suddenly a procedure, it's nothing more or less than a function with side effects.
The compat name does matter because it's exactly the point. Compact names make for hard to read code. And claiming that it should be window_add_string_returned_error just means that you are totally missing the point and don't understand the issue.
If waddstr is a function (which you don't agree with), the post I replied to basically said it should be named something like that. All I did was notice that that's what it said, and point it out in hopes of clarification (which I got).
waddstr is a procedure, not a function
As far as I know, the difference is that procedures don't return values, and functions do. waddstr returns a value. What's the difference according to you?
And the compact waddstr name doesn't matter; if it were named window_add_string, I would make the same point by saying that its name would need changing to window_add_string_returned_error.
"Procedure names should reflect what they do; function names should reflect what they return"
What about functions that simply return a success/failure indicator? Should we rename, for example, waddstr to waddstr_error?
Ah, okay, just a bunch of misunderstandings :) All I meant (and hopefully said) originally was that having that freedom is fortunate. Thanks for clearing things up.
Okay, so by how I'm reading your posts, now you've said that freedom is very important (in that message), and that it's unfortunate we have it (in your message before that). That makes no sense, so could you please explain yourself, preferably more directly? That way, if I'm misunderstanding you, I don't again.
Assuming that you treat speech and "free-as-in-speech software" the same, I don't see it. If you support others' rights to say what you disagree with, that makes it fortunate, not unfortunate, that they're allowed to speak. All it makes unfortunate is that they actually do speak.
Unfortunately you cannot have free software if you place arbitary restrictions upon who can use it or what it can be used for.
Unfortunately? I'm certainly glad I'm not told to only use Linux in approved manners. I doubt I'd even run it otherwise.
I used to use a somewhat similar system, a Corona "portable" PC. It's got less RAM, mine didn't have a HD, and it's heavier, but it felt like a great machine at the time. :)