Then I'd say I think you misunderstand the purpose of the request for an e-mail address. There's a reason they ask for an e-mail address instead of a handle -- they want the ability to e-mail you.
You can decide you don't want them to e-mail you, and that's fine. But the alternative might be not registering for the service.
It seems to me that giving someone your e-mail address constitutes an indication of willingness to receive e-mail. It would follow logically that if you give someone your e-mail address and don't wish to receive e-mail from them, you must say so explicitly.
You're an idiot. SPAM is unsolicited, bulk, commercial e-mail. If you send it out to a list of your customers (who can opt-out, I assume), then it's not SPAM.
Next time, try to form an argument that actually makes sense.
It's quite well-defined. When the end of main is reached, it's equivalent to calling the exit function (unless the return type of main is incompatible with int, in which case the value returned to the operating system is implementation-defined). Among other things, exit() has the following affect:
"Next, all open streams with unwritten buffered data are flushed, all open streams are closed, and all files created by the tmpfile function are removed."
Maybe you should learn the language a little better.
Java is probably the most widely-used garbage-collected language in existence. I think I speak for all Java programmers when I say "WTF are you talking about?"
He's talking about the unpredictability of resource release using GC. If unpredictability isn't a problem, fine. If you need to synchronize your resources carefully (which is what a mutex is/all about/), then you've got a problem.
Now, this article is about C, so let's compare the two.
The post you're responding to wasn't about C: it was about a weakness of GC compared to, say, RAII (which is the idiom C++, among others, uses). But just for fun, let's go on to see how little you know about C.
Java: failing to close a file == usually no problem whatsoever
Unless you need to open the file again before the garbage collector decides to reclaim the handle.
C: failing to close a file == permanently leaked handle
Bzzt... wrong. All file handles are released upon program termination. I like how you used '==' to try impress people with your programming skillz, though.
As far as the other case you mention, mutexes, goes, Java has two means of providing mutual exclusion. The "synchronized" keyword
Wait, wait... you're saying... hold on a second, now... that Java uses a different idiom to handle mutexes? That's exactly what the parent post said it would have to do... because GC isn't as useful as RAII when it comes to general resource allocation (not just memory).
But you make it sound as if garbage collection is a step backwards from malloc/free
He made no such comparison. He compared it (unfavorably) to RAII.
I think he expressed his ideas quite well; perhaps you are lacking in reading comprehension.
He said that, in the context of the US copyright laws, "financial gain" is not limited to refering to capital: it includes the/expected/ exchange of other copyrighted works, which is exactly what the GPL requires. Therefore (and ergo, vis a vis, et cetera), the GPL does, in fact, meet the criteria for "financial gain".
IOW, he said, "That word... I do not think it means what you think it means."
Templates is such a large part of the language that I/would/ say you know little about C++ if you don't know templates. It's like saying you know C except for pointers.
And if the team member assumed there would be such a sensible exception (compare C-style strings as strings... what a concept!) and there wasn't, you'd have the same problem. If the standard library and just about every other library in existence weren't already littered with this kind of exception, you'd have a much stronger argument. As it is, you just sound beligerent.
I didn't mean that to be derogatory. It's just the whole, "Just as good as C++, but a clearer syntax, better abstractions, etc". I'm not saying it's wrong -- just that I've heard it before.
>In my opinion, this is Stroustrups "much smaller and cleaner language struggling to get out" from C++.
That's not what I see. It looks much more like an updated version of Ada to my eyes. Even the claims made are very similar to those made against C++ when Ada95 was new-fangeled and against C when Ada was born.
While you're correct that LOC is not a measure of how good a language is, it can be a rough measure of the level of abstraction afforded by a language, when compared to a similar language.
The question is not whether or not it's a/human being/. The question is whether or not it's/alive/.
As to difference in programming -- computers today aren't programmed in the same way computers were fifty years ago. Quantum computers are programmed very differently, and biological computers are programmed in yet different ways. As I said -- it's quite difficult to provide a useful legal definition.
We're not talking about philosophy, we're talking about law. Things become much trickier when they have legal consequences. And any definition you make to suit the outcome you wish (such as "computer" or "programmed") will have effects on other laws -- effects which may be very detrimental. Even so, it's very difficult to design a definition of "life" that includes humans but not artificial creations.
And no... people are programmed too. Take a baby and put them in an isolation chamber for twenty years. See what they're like... a human with no programming is a pretty sad sight.
There's a difference between, "Well, it could happen at some point in the future using an unknown method that may or may not even be possible" and "Yeah, this is how you'd do it". You're right that "conception" is not the right word: I didn't choose it; the post I replied to did (they said AI was inconceivable in the next 50 years).
In the context the person I was replying to meant it, yes, it was inconceivable. Obviosuly, AI has been conceivable/in science-fiction/ since at least the 1920s. I mean, that's like saying that it's conceivable that we could blow up an asteroid with a nuclear warhead and have the pieces rain down on earth without causing cataclysmic destruction. I mean, they did it in Armaggeddon, right?
I guess my point is that there's a difference between conception and fantasy.
Slashdot Mirror
RTFA. c't ran a "sting" where the virus author sold them the IP addresses.
Then I'd say I think you misunderstand the purpose of the request for an e-mail address. There's a reason they ask for an e-mail address instead of a handle -- they want the ability to e-mail you.
You can decide you don't want them to e-mail you, and that's fine. But the alternative might be not registering for the service.
Okay, fair enough.
It seems to me that giving someone your e-mail address constitutes an indication of willingness to receive e-mail. It would follow logically that if you give someone your e-mail address and don't wish to receive e-mail from them, you must say so explicitly.
Full ack.
Heh... I first read that as "Fuck all."
Apparently you've learned how use terms incorrectly.
He was talking about people who were already his customers; they're implicitly opted in until they explicitly opt out.
You're an idiot. SPAM is unsolicited, bulk, commercial e-mail. If you send it out to a list of your customers (who can opt-out, I assume), then it's not SPAM.
Next time, try to form an argument that actually makes sense.
If I perform an action, with an intended result, and the result happend, then I have caused the result to happen.
That is a truly idiotic statement. Just think about it for second.
No, you paid attention to the wrong part. The relavent part is "all open streams are closed". Remember that a FILE* is a stream.
It's quite well-defined. When the end of main is reached, it's equivalent to calling the exit function (unless the return type of main is incompatible with int, in which case the value returned to the operating system is implementation-defined). Among other things, exit() has the following affect:
"Next, all open streams with unwritten buffered data are flushed, all open streams are
closed, and all files created by the tmpfile function are removed."
Maybe you should learn the language a little better.
Java is probably the most widely-used garbage-collected language in existence. I think I speak for all Java programmers when I say "WTF are you talking about?"
/all about/), then you've got a problem.
He's talking about the unpredictability of resource release using GC. If unpredictability isn't a problem, fine. If you need to synchronize your resources carefully (which is what a mutex is
Now, this article is about C, so let's compare the two.
The post you're responding to wasn't about C: it was about a weakness of GC compared to, say, RAII (which is the idiom C++, among others, uses). But just for fun, let's go on to see how little you know about C.
Java: failing to close a file == usually no problem whatsoever
Unless you need to open the file again before the garbage collector decides to reclaim the handle.
C: failing to close a file == permanently leaked handle
Bzzt... wrong. All file handles are released upon program termination. I like how you used '==' to try impress people with your programming skillz, though.
As far as the other case you mention, mutexes, goes, Java has two means of providing mutual exclusion. The "synchronized" keyword
Wait, wait... you're saying... hold on a second, now... that Java uses a different idiom to handle mutexes? That's exactly what the parent post said it would have to do... because GC isn't as useful as RAII when it comes to general resource allocation (not just memory).
But you make it sound as if garbage collection is a step backwards from malloc/free
He made no such comparison. He compared it (unfavorably) to RAII.
c isn't "the speed of light". It's the speed of light *in a vacuum*. And that /is/ a constant.
I think he expressed his ideas quite well; perhaps you are lacking in reading comprehension.
/expected/ exchange of other copyrighted works, which is exactly what the GPL requires. Therefore (and ergo, vis a vis, et cetera), the GPL does, in fact, meet the criteria for "financial gain".
He said that, in the context of the US copyright laws, "financial gain" is not limited to refering to capital: it includes the
IOW, he said, "That word... I do not think it means what you think it means."
You sure? Looks fine to me. Takes a small bit of effort, perhaps, but it's definitely readable.
Templates is such a large part of the language that I /would/ say you know little about C++ if you don't know templates. It's like saying you know C except for pointers.
Oh, and that's so much better than
/exactly/ what's going on without bothering to read the function definition. Riiight.
A var1;
B var2;
add(var1, var2, &var3);
Because now you know
Seriously, operator overloading is just syntactic sugar for a function call: it's no more and no less obfuscated.
And if the team member assumed there would be such a sensible exception (compare C-style strings as strings... what a concept!) and there wasn't, you'd have the same problem. If the standard library and just about every other library in existence weren't already littered with this kind of exception, you'd have a much stronger argument. As it is, you just sound beligerent.
While functions as first-class values are indeed useful, it is not necessary for any of those three tasks.
I didn't mean that to be derogatory. It's just the whole, "Just as good as C++, but a clearer syntax, better abstractions, etc". I'm not saying it's wrong -- just that I've heard it before.
>In my opinion, this is Stroustrups "much smaller and cleaner language struggling to get out" from C++.
That's not what I see. It looks much more like an updated version of Ada to my eyes. Even the claims made are very similar to those made against C++ when Ada95 was new-fangeled and against C when Ada was born.
While you're correct that LOC is not a measure of how good a language is, it can be a rough measure of the level of abstraction afforded by a language, when compared to a similar language.
The question is not whether or not it's a /human being/. The question is whether or not it's /alive/.
As to difference in programming -- computers today aren't programmed in the same way computers were fifty years ago. Quantum computers are programmed very differently, and biological computers are programmed in yet different ways. As I said -- it's quite difficult to provide a useful legal definition.
We're not talking about philosophy, we're talking about law. Things become much trickier when they have legal consequences. And any definition you make to suit the outcome you wish (such as "computer" or "programmed") will have effects on other laws -- effects which may be very detrimental. Even so, it's very difficult to design a definition of "life" that includes humans but not artificial creations.
And no... people are programmed too. Take a baby and put them in an isolation chamber for twenty years. See what they're like... a human with no programming is a pretty sad sight.
There's a difference between, "Well, it could happen at some point in the future using an unknown method that may or may not even be possible" and "Yeah, this is how you'd do it". You're right that "conception" is not the right word: I didn't choose it; the post I replied to did (they said AI was inconceivable in the next 50 years).
In the context the person I was replying to meant it, yes, it was inconceivable. Obviosuly, AI has been conceivable /in science-fiction/ since at least the 1920s. I mean, that's like saying that it's conceivable that we could blow up an asteroid with a nuclear warhead and have the pieces rain down on earth without causing cataclysmic destruction. I mean, they did it in Armaggeddon, right?
I guess my point is that there's a difference between conception and fantasy.