Ah, OK, yeah, it is valid to use post-increment to increment something, return a copy of the old value, and then increment that, and throw it away...
Point taken - code's not invalid as such, just fairly pointless as it does nothing. (Unless, of course, the operators are defined with side-effects... in which case it does something but it's probably a bad design...)
Anybody remember how awesome and important VRML was supposed to be? They just forgot to convince users.
What? No way! I was definitely convinced! I distinctly remember running a VRML plugin at one time, and trying one of a very limited number of available example pages for it with some limited measure of success...
I feel compelled to add, this was a point in time at which streaming audio over the internet was still a big deal.
Anybody remember how awesome and important VRML was supposed to be? They just forgot to convince users.
What? No way! I was definitely convinced! I distinctly remember running a VRML plugin at one time, and trying one of a very limited number of available example pages for it with some limited measure of success...
If I'd had tools like (today's) Blender back then, and the hardware to back it up, I might have done something with VRML...
What's really unfortunate is that he's one of the very few language maintainers out there that isn't of the mentality "Rah rah! My language/tool/design-philosophy/whatever is the solution to all your problems and will take over the world tomorrow."
Care to actually provide the names of those other language maintainers, with appropriate citations, that make such claims?
Very well. They don't out and out say that exact phrase but I'm sick of languages being marketed to me like an automobile. Here are a few after a bit of Googling. I don't really have time to dig more up:...
If I were in their shoes, I would explicitly say what the language is but also explicitly say what it is not. As someone who's tried to do video analysis in Java, I've been down the "should not" path and wasted my time.
Java was very, very hyped, it's true. However I view the other cases rather differently. I have been working on a language design of my own, and as a result I have given this some thought.
Basically, to a certain extent it doesn't matter how good a language or tool is if people don't try it. And it can be hard to get people to try something new and different for a variety of reasons: there's bound to be a learning curve involved, and even if the language is populated with concepts the user will ultimately enjoy, when they start out it'll all be rather alien. I believe that if you want people to use the language you've developed, you've got to "market" it - otherwise people will never get beyond those initial hurdles standing between themselves and their potential enjoyment of the language. For the language to have any chance at all of success, someone's got to be an advocate for it - if the language creator isn't doing this, then why should anyone else?
As for keeping the proper perspective in this advocacy - that is tough because people involved in development often think in terms of what they want the tool to become rather than necessarily exactly what it is. In the case of independent software developers writing these things, they're often not your consultants either - they're not there to advise you on whether their tool might or might not be good for your task - they wrote something they're enthusiastic about, and they're excited to share it.
As for the Matsumoto quote you cited: he was asked specifically in the interview if there was a philosophy that guided the development of Ruby, and that was his answer. Now, you could say that was a carefully crafted answer designed to win over the hearts of programmers - or you could say that this really was the idea that drove him to create a programming language, and guided its design. Who can say which is right? I read the quote and I see Matsumoto as someone who's enthusiastic about what he's created, and wants people to enjoy it...
I enjoyed the interview but I felt the initials of the participants were really unfortunate. DK and BS? I kept reading the whole thing as:
Donkey Kong: The specification of concepts has taken seven years. By contrast, the standardization of the entire STL took about half that time. What is so complicated about concepts?
I always wonder about those shirts and stuff that say "Donkey Kong New York", too...
The problem there is, who checks to see that "buf" is sufficiently large, when, and how?
The choice not to do that sort of thing at runtime is pretty fundamental to the design of C as a minimal-overhead language. Checking that kind of assertion at compile time is a nearly intractable problem - I would argue that the benefits wouldn't have been worth the cost. Still, I do agree that making that relationship between the buffer and its size explicit in the code is a good thing.
Instead of fixing the mess underneath, C++ papered it over. Arrays were wrapped with classes in the Standard Template Library. The STL is a good thing, but it's not good enough to totally replace built-in arrays. So real-world programs remain a mixture of ambiguous built-in arrays, pointers to arrays, and STL arrays.
I think it's worth noting the precise reasons why STL containers aren't "good enough" to "totally" replace arrays:
Extra overhead from carrying information about the array's size in addition to its data address
Lack of syntax support for declaring elements of a vector
Use of built-in arrays didn't end due to the continued need for the zero-overhead methods for dealing with memory
Then the STL approached iteration as an extension of pointer arithmetic. For "compatibility" with C pointer arithmetic, iterators are not only unchecked, but are not explicitly bound to the collection over which they iterate.
That decision wasn't for compatibility with C pointer arithmetic (note, for instance, that it's entirely possible to implement an iterator in C++ which does the kind of checking you suggest, but still has the same interface as a C pointer) - but rather, for efficiency. For instance, consider the following loop:
std::vector x(10000000);// Get the value of x from somewhere... for (std::vector::const_iterator i = x.begin(). i != x.end(); i++) {// do something... }
Now, we damn well know that, barring memory corruption or a serious bug in the STL, that this won't overrun the boundaries of the container. So why should i be range-checked ten million times?
I believe some features that might help C++ is automatic memory allocation (where objects are automatically resized and freed when they go out of scope
Even C had that.
You mean smart pointers? About 10 minutes work to implement...
Well, until it's time to do it right... If, for instance, you need to be sure that the assignment operators will allow assignment from compatible types, but not from incompatible types (admittedly, various compiler bugs complicate this) - or provide thread safety, things like that.
Uncluttered article, without any extra crap and multiple pages. Printable == readable.
There fixed that for you.
You know, this tends to bug me a bit...
I mean, yeah, here we are talking about C++ in which "=" means assignment and "==" means an equality test... But the world at large is not governed by these definitions. An equation like "y = 3*x + 4" establishes a relationship in which the two sides of the equation are equal.
If you want to apply the meanings of C operators to English text, then really neither meaning is correct: "Printable = Readable" - means "Henceforth, until further notice, 'Printable' will have the value that 'Readable' has now" (Assignment) "Printable == Readable" - means "I want to know if 'Printable' and 'Readable' have the same value". (It's an equality test, not an equality assertion)
I mean, I was pretty annoyed when they said, "Hey, here's C++! We added that increment operator to show you that we made C better!" But, then, wouldn't you know it... Yeah, they made a better C, but what they actually gave to us was the same old C, as it was before they improved it. Later on I kept checking back to see if C++ really was substantially different from plain old C: and it was, but each time I looked at C++, the result was something different from what I'd seen before!
(C+++=1 simply wouldn't work, as C++ is an rvalue. Suppose D=C. Now, D == C++. But then, D != C++. And for that matter, C++ != C++. It's maddening, I tell you! And I don't think C+=2 is equal to anything at all...)
Yes yes, I know, I was being too simplistic (I realized this after I hit submit). Duck typing == dynamic dispatch *and* dynamic typing. Either way, "duck typing" is a stupid marketing term, nothing more.
So what if it is? Stupid or not, it's nevertheless an effective way of conveying a certain concept.
The point is that these languages have taken those language features and used them to embrace a philosophy (Duck Typing) of how types should be used in the language. I would say that your equation isn't quite correct: Duck Typing isn't the combination of dynamic dispatch and dynamic typing: rather, that combination is one way to implement the concept. Duck Typing itself has more to do with removing the formal definition of a common interface, and the philosophy that if two modules happen to implement the same interface consistently enough that they could work interchangeably, then that is a common interface.
Duck Typing is not specific to runtime. It's all about the concept that type compatibility is determined only by the set of operations that can be performed on a value.
Basically it's a convenient form of sloppy, fragile programming, especially in the case of languages where an inconsistency in the interfaces of the "interchangeable" modules can't be detected except at runtime via a coverage test (as in Python). But it's nevertheless an idea that is used (by way of templates) quite a bit in C++. If you implement a function in C++ with a template argument, then the only thing about that argument that the programmer has to concern himself with is whether the usage of that argument inside the function fits the interface of the class used to implement the value passed in for that argument. In this case neither dynamic dispatch or dynamic typing would be used (C++ specializes the function at compile time) - but from the programmer's perspective it's the same concept as duck typing: all that matters is that whatever class is used as the value for that template argument has to match the usage of that argument inside the function body.
Larry Wall of Perl: "Perl is designed to give you several ways to do anything, so consider picking the most readable one. " - From the Perl Man Pages
Isn't that statement a backhanded way for Larry to tell people to use just about any language other than Perl?
No, it's more like an excuse for Perl's reputed illegibility. He's saying, basically, "it's possible to write legible code in Perl because Perl gives you a lot of ways to do the same thing. If legibility is important to you, you have the freedom to write legible code in Perl (just as you have the freedom to write decidedly illegible code in Perl...)" -- Paraphrasing, obviously.
Don't forget to factor in that you spin the chamber once at the beginning of the game... The probability (of course the position of the bullet is certain - so in a sense there's a 100% chance of a certain shot being lethal and a 0% chance of the others being lethat - but in absence of knowledge of which chamber has a bullet we think of it as a probability) of getting the bullet changes with each shot:
first shot: 1/6 chance second shot: 1/5 chance third shot: 1/4 chance fourth shot: 1/3 chance fifth shot: 1/2 chance sixth shot: if the game goes this far, then everybody already knows where the bullet is...
Basically the flaw in your script is that one could conceivably run it six times and not get the "bullet" - or run it more than once and get the "bullet" more than once (at least, if the shell is busybox or something, preventing the removal of/bin/rm and/bin/echo from being an issue...)
Computer programmers like that is why everyone thinks we are dicks.
If I were that paper boy, I'd ask: "Can your media delivery save you money?" I get the Sunday paper, because for 2 bucks I save about 100 bucks a week on items regularly purchase. Coupons.
Murdoch went on to mention that other site changes came at the request of his dog, Billy, who said that they were not sufficiently canine-accessible. The new design, apparently, will feature images of small rubber toys as the links - these will squeak when clicked upon. Also, in addition to password authentication, the site will support olfactory authentication via a newly-developed USB peripheral.
Some of those in Murdoch's immediate vicinity responded negatively to these claims: one man complained that Murdoch in fact did not even have a dog. Referring to Murdoch as a "crazy fool", he went on to say that Murdoch's presence was not necessary, as there was no present need for his unique skills.
You don't seem to like what I have to say. Think for a moment about how much stock you're putting in what I think - it's as though you don't know how to react to anything I say unless I first take a clear stand on what side of the debate I'm on.
The closest analogue to CV "theft" is "theft of services" - for instance finding a way to ride the rides at an amusement park without paying for them
No. In a theft of services, the one providing the service still had to provide it. If you find a way to the rides to an amusement park, you are actually using the service. They will need to clean up after you. You deteriorate the rides a bit. You also degrade the service of others, as they may have to wait a bit longer to use the ride, etc, etc.
First, note that it's an analogy. It's not an exact copy of the situation with copyright violation, it's similar.
But suppose there were ten other empty seats on the ride. Suppose you even agreed to get off if anybody else wanted to get on. Since there were other people on the ride, it's not like they had to run the thing just for you, and since there were other empty seats, it's not like you affected anyone else's riding experience. So long as you don't make a mess there's nothing to clean - and so long as you don't get injured there's nothing their insurance needs to pay for. So where's the loss?
The answer is that, first, since you got to ride for free, there's no longer any motivation for you to pay. Second, if any of the people who did pay realize that you didn't, they're going to be unhappy about your apparently unfair treatment - they'll be less likely to pay for their own ride in the future.
I'm just saying it's a similar situation and, whether you or I call it theft, in fact the law calls it theft. Thus there's precedent.
You agree that sticking "theft" to copyright violation is manipulation, and then, magically, you said that NOT sticking it would be manipulation too, so we should stick "theft". That kind of negative reasoning doesn't make sense:
Word choice always affects the message. Are you confused why I present two, seemingly contradictory points of view?
Actually, it's because I'm trying to show both sides of the argument.
Also - I did not say that not calling copyright violation "theft" was a form of manipulation, I said it doesn't accomplish anything. It's a kind of zero-value statement. Suppose I'm someone who thinks copyright violation is theft - and you're someone who doesn't... We argue all day, and finally you convince me that you're right....So what? All we've really worked out is a small matter of terminology. We haven't even established what copyright infringement is, just one possible thing that it isn't. Have you convinced me, for instance, that the government should not treat copyright infringement as a criminal offense? I guess that could depend upon the course of the discussion - but quite possibly not. This is why I say the matter of terminology is largely irrelevant. It misses the real issue.
What is your position on not calling copyright violation "rape" ? After all, the perpetrator is taking pleasure from someone else by force ?
Let's call it "rape". Not calling it "rape" would be manipulation, sure ? And arguing about it would be hair-splitting, wouldn't it ?
You are diving ever deeper into the murky waters of farcical nonsense based on ever-increasing distortions of what you think you remember I might have said about something. I love using good logic with bad data as a tool for farce, but I'm not in the mood. Let's skip it, shall we?
The reason the question has come up about whether "copyright violation" qualifies as "theft" is because copyright holders (i.e. people with some am
It was not my intention to troll: merely to present the issue in a fairly neutral way.
You say "Of course CV is not stealing" - but the truth, I think, is that the definition is still under contention. Purists among us may not like the concept, but in a legal sense and in a practical sense, terms like "theft" are subject to redefinition and adaptation. And, of course, what is "obvious" and what is "supported by law" are often quite different. (This is in part due to the inherently subjective nature of what is deemed "obvious"...)
The closest analogue to CV "theft" is "theft of services" - for instance finding a way to ride the rides at an amusement park without paying for them. This isn't theft in the traditional sense of material theft (and one could argue nothing is lost, and thus, nothing's been stolen) but nevertheless, the act is considered a form of "theft" under the law.
The reason I referred to the issue as "hair-splitting" is because arguing over whether copyright violation is or isn't theft, for the most part, doesn't get one anywhere in the discussion of whether it's a valid action or not - whether or not it should be criminal, for instance. Calling copyright violation "theft" imposes a judgement that it should be considered criminal: but not calling it theft doesn't imply that it shouldn't be considered a crime.
Ironic does not mean what Alanis Morisette says it means.
That's why I thought an Alanis Morisette reference was appropriate in my response to someone who said (paraphrasing) that it's ironic that someone might be sympathetic to software piracy even if it hurts the economy of their country. It's not a particularly ironic thing.
I wonder what the trade deficit would be if they actually respected our intellectual property and paid the going rate for it instead of stealing it?
Good point. It's also ironic since most of/. would have you believe that piracy isn't stealing, and yet their own lives might be noticeably better if stated countries paid for, instead of pirated, American software.
Ironic? I don't know if that's the right word for it. That is nothing like rain on your wedding day, for instance.
I mean, look - yes, some people take that stance, that software piracy isn't "stealing". That point alone is just splitting hairs over terminology. The choice of words there is designed to make people sympathize with the copyright holders, and I think people don't always appreciate that sort of spin.
And then also consider - when we have a stance on what we consider right and wrong, in principle that should not be governed by what is best for ourselves, personally. This is why I don't see this situation as "ironic". If a specific person said both that they think copyright infringement is okay and that China's copyright infringement is bad, that would be hypocritical... But if someone believes copyright infringement is okay and doesn't care about China's copyright infringement or the economic consequences thereof, that's consistent. They've taken their stance and stuck to it.
Slashdot Mirror
I am nervous that the kids who grew up on Pokémon are all grown up and in the military now....
Are they going to throw Pokéballs at opposing forces?
This Penny Arcade seems rather apropos...
One prototype for this kind of robot didn't do so well in tests....
Sgt. Connor tossed the robot into a room hoping for a report - after a short period it rolled back out of the room to communicate back its findings...
Connor: Report.
Robot: HARO, GENKI?
Connor: Yeah, hi. Report, please.
Robot: HARO, GENKI? HARO!
Connor: Damnit, tell me what's in there!
Robot: CONNOR-GUNSOU, OKKOTTEIRU, OKKOTTEIRU.
Connor then kicked the robot, causing it to rebound off a wall and hit him in the head.
Ah, OK, yeah, it is valid to use post-increment to increment something, return a copy of the old value, and then increment that, and throw it away...
Point taken - code's not invalid as such, just fairly pointless as it does nothing. (Unless, of course, the operators are defined with side-effects... in which case it does something but it's probably a bad design...)
Anybody remember how awesome and important VRML was supposed to be? They just forgot to convince users.
What? No way! I was definitely convinced! I distinctly remember running a VRML plugin at one time, and trying one of a very limited number of available example pages for it with some limited measure of success...
I feel compelled to add, this was a point in time at which streaming audio over the internet was still a big deal.
Anybody remember how awesome and important VRML was supposed to be? They just forgot to convince users.
What? No way! I was definitely convinced! I distinctly remember running a VRML plugin at one time, and trying one of a very limited number of available example pages for it with some limited measure of success...
If I'd had tools like (today's) Blender back then, and the hardware to back it up, I might have done something with VRML...
What's really unfortunate is that he's one of the very few language maintainers out there that isn't of the mentality "Rah rah! My language/tool/design-philosophy/whatever is the solution to all your problems and will take over the world tomorrow."
Care to actually provide the names of those other language maintainers, with appropriate citations, that make such claims?
Very well. They don't out and out say that exact phrase but I'm sick of languages being marketed to me like an automobile. Here are a few after a bit of Googling. I don't really have time to dig more up: ...
If I were in their shoes, I would explicitly say what the language is but also explicitly say what it is not. As someone who's tried to do video analysis in Java, I've been down the "should not" path and wasted my time.
Java was very, very hyped, it's true. However I view the other cases rather differently. I have been working on a language design of my own, and as a result I have given this some thought.
Basically, to a certain extent it doesn't matter how good a language or tool is if people don't try it. And it can be hard to get people to try something new and different for a variety of reasons: there's bound to be a learning curve involved, and even if the language is populated with concepts the user will ultimately enjoy, when they start out it'll all be rather alien. I believe that if you want people to use the language you've developed, you've got to "market" it - otherwise people will never get beyond those initial hurdles standing between themselves and their potential enjoyment of the language. For the language to have any chance at all of success, someone's got to be an advocate for it - if the language creator isn't doing this, then why should anyone else?
As for keeping the proper perspective in this advocacy - that is tough because people involved in development often think in terms of what they want the tool to become rather than necessarily exactly what it is. In the case of independent software developers writing these things, they're often not your consultants either - they're not there to advise you on whether their tool might or might not be good for your task - they wrote something they're enthusiastic about, and they're excited to share it.
As for the Matsumoto quote you cited: he was asked specifically in the interview if there was a philosophy that guided the development of Ruby, and that was his answer. Now, you could say that was a carefully crafted answer designed to win over the hearts of programmers - or you could say that this really was the idea that drove him to create a programming language, and guided its design. Who can say which is right? I read the quote and I see Matsumoto as someone who's enthusiastic about what he's created, and wants people to enjoy it...
I enjoyed the interview but I felt the initials of the participants were really unfortunate. DK and BS? I kept reading the whole thing as:
Donkey Kong: The specification of concepts has taken seven years. By contrast, the standardization of the entire STL took about half that time. What is so complicated about concepts?
I always wonder about those shirts and stuff that say "Donkey Kong New York", too...
We should have had syntax like
int read(int fd, char buf[n]&, size_t n);
to replace the old
int read(int fd, char *buf, size_t n);
The problem there is, who checks to see that "buf" is sufficiently large, when, and how?
The choice not to do that sort of thing at runtime is pretty fundamental to the design of C as a minimal-overhead language. Checking that kind of assertion at compile time is a nearly intractable problem - I would argue that the benefits wouldn't have been worth the cost. Still, I do agree that making that relationship between the buffer and its size explicit in the code is a good thing.
Instead of fixing the mess underneath, C++ papered it over. Arrays were wrapped with classes in the Standard Template Library. The STL is a good thing, but it's not good enough to totally replace built-in arrays. So real-world programs remain a mixture of ambiguous built-in arrays, pointers to arrays, and STL arrays.
I think it's worth noting the precise reasons why STL containers aren't "good enough" to "totally" replace arrays:
Then the STL approached iteration as an extension of pointer arithmetic. For "compatibility" with C pointer arithmetic, iterators are not only unchecked, but are not explicitly bound to the collection over which they iterate.
That decision wasn't for compatibility with C pointer arithmetic (note, for instance, that it's entirely possible to implement an iterator in C++ which does the kind of checking you suggest, but still has the same interface as a C pointer) - but rather, for efficiency. For instance, consider the following loop:
std::vector x(10000000);
for (std::vector::const_iterator i = x.begin(). i != x.end(); i++)
{
}
Now, we damn well know that, barring memory corruption or a serious bug in the STL, that this won't overrun the boundaries of the container. So why should i be range-checked ten million times?
I believe some features that might help C++ is automatic memory allocation (where objects are automatically resized and freed when they go out of scope
Even C had that.
You mean smart pointers? About 10 minutes work to implement...
Well, until it's time to do it right... If, for instance, you need to be sure that the assignment operators will allow assignment from compatible types, but not from incompatible types (admittedly, various compiler bugs complicate this) - or provide thread safety, things like that.
Uncluttered article, without any extra crap and multiple pages. Printable == readable.
There fixed that for you.
You know, this tends to bug me a bit...
I mean, yeah, here we are talking about C++ in which "=" means assignment and "==" means an equality test... But the world at large is not governed by these definitions. An equation like "y = 3*x + 4" establishes a relationship in which the two sides of the equation are equal.
If you want to apply the meanings of C operators to English text, then really neither meaning is correct:
"Printable = Readable" - means "Henceforth, until further notice, 'Printable' will have the value that 'Readable' has now" (Assignment)
"Printable == Readable" - means "I want to know if 'Printable' and 'Readable' have the same value". (It's an equality test, not an equality assertion)
Stupid name, it should be
C+++=1
or is equiv
C+=2
C++0X is a syntax error!
Actually, the two forms aren't equivalent.
I mean, I was pretty annoyed when they said, "Hey, here's C++! We added that increment operator to show you that we made C better!" But, then, wouldn't you know it... Yeah, they made a better C, but what they actually gave to us was the same old C, as it was before they improved it. Later on I kept checking back to see if C++ really was substantially different from plain old C: and it was, but each time I looked at C++, the result was something different from what I'd seen before!
(C+++=1 simply wouldn't work, as C++ is an rvalue. Suppose D=C. Now, D == C++. But then, D != C++. And for that matter, C++ != C++. It's maddening, I tell you! And I don't think C+=2 is equal to anything at all...)
Yes yes, I know, I was being too simplistic (I realized this after I hit submit). Duck typing == dynamic dispatch *and* dynamic typing. Either way, "duck typing" is a stupid marketing term, nothing more.
So what if it is? Stupid or not, it's nevertheless an effective way of conveying a certain concept.
The point is that these languages have taken those language features and used them to embrace a philosophy (Duck Typing) of how types should be used in the language. I would say that your equation isn't quite correct: Duck Typing isn't the combination of dynamic dispatch and dynamic typing: rather, that combination is one way to implement the concept. Duck Typing itself has more to do with removing the formal definition of a common interface, and the philosophy that if two modules happen to implement the same interface consistently enough that they could work interchangeably, then that is a common interface.
Duck Typing is not specific to runtime. It's all about the concept that type compatibility is determined only by the set of operations that can be performed on a value.
Basically it's a convenient form of sloppy, fragile programming, especially in the case of languages where an inconsistency in the interfaces of the "interchangeable" modules can't be detected except at runtime via a coverage test (as in Python). But it's nevertheless an idea that is used (by way of templates) quite a bit in C++. If you implement a function in C++ with a template argument, then the only thing about that argument that the programmer has to concern himself with is whether the usage of that argument inside the function fits the interface of the class used to implement the value passed in for that argument. In this case neither dynamic dispatch or dynamic typing would be used (C++ specializes the function at compile time) - but from the programmer's perspective it's the same concept as duck typing: all that matters is that whatever class is used as the value for that template argument has to match the usage of that argument inside the function body.
What the hell? Do I have to RTFA to find out what C++0x is supposed to mean?
More than one penis?
Probably. Makes you wonder why there are so few female programmers, doesn't it?
Oh, I don't know... Your mom always seemed pretty good at handling more than one penis.
Larry Wall of Perl: "Perl is designed to give you several ways to do anything, so consider picking the most readable one. " - From the Perl Man Pages
Isn't that statement a backhanded way for Larry to tell people to use just about any language other than Perl?
No, it's more like an excuse for Perl's reputed illegibility. He's saying, basically, "it's possible to write legible code in Perl because Perl gives you a lot of ways to do the same thing. If legibility is important to you, you have the freedom to write legible code in Perl (just as you have the freedom to write decidedly illegible code in Perl...)" -- Paraphrasing, obviously.
[ $[ $RANDOM % 6 ] == 0 ] && rm -rf / || echo *Click*
Don't forget to factor in that you spin the chamber once at the beginning of the game... The probability (of course the position of the bullet is certain - so in a sense there's a 100% chance of a certain shot being lethal and a 0% chance of the others being lethat - but in absence of knowledge of which chamber has a bullet we think of it as a probability) of getting the bullet changes with each shot:
first shot: 1/6 chance
second shot: 1/5 chance
third shot: 1/4 chance
fourth shot: 1/3 chance
fifth shot: 1/2 chance
sixth shot: if the game goes this far, then everybody already knows where the bullet is...
Basically the flaw in your script is that one could conceivably run it six times and not get the "bullet" - or run it more than once and get the "bullet" more than once (at least, if the shell is busybox or something, preventing the removal of /bin/rm and /bin/echo from being an issue...)
Computer programmers like that is why everyone thinks we are dicks.
If I were that paper boy, I'd ask:
"Can your media delivery save you money?"
I get the Sunday paper, because for 2 bucks I save about 100 bucks a week on items regularly purchase. Coupons.
Man, you must buy a lot of coupons!
Yeah, but Korben Dallas kills Snape at Nakatomi Plaza with gravity.
And then he has a nice chat over the radio with Carl Winslow about his plans for a reconciliation with Ginger Heffman...
It was really great at the end when Carl shot that guy and he was like, "Thank you Topper, I can kill again!"
Walking down the street -
"Single"
"Married"
"Single with Facebook Profile"
"Malda's GF - don't touch"
Oh, and don't forget about the other obvious use of this technology:
"Power level: over 9000"
(or 8000 if you buy the Japanese version...)
Murdoch went on to mention that other site changes came at the request of his dog, Billy, who said that they were not sufficiently canine-accessible. The new design, apparently, will feature images of small rubber toys as the links - these will squeak when clicked upon. Also, in addition to password authentication, the site will support olfactory authentication via a newly-developed USB peripheral.
Some of those in Murdoch's immediate vicinity responded negatively to these claims: one man complained that Murdoch in fact did not even have a dog. Referring to Murdoch as a "crazy fool", he went on to say that Murdoch's presence was not necessary, as there was no present need for his unique skills.
You don't seem to like what I have to say. Think for a moment about how much stock you're putting in what I think - it's as though you don't know how to react to anything I say unless I first take a clear stand on what side of the debate I'm on.
The closest analogue to CV "theft" is "theft of services" - for instance finding a way to ride the rides at an amusement park without paying for them
No. In a theft of services, the one providing the service still had to provide it. If you find a way to the rides to an amusement park, you are actually using the service. They will need to clean up after you. You deteriorate the rides a bit. You also degrade the service of others, as they may have to wait a bit longer to use the ride, etc, etc.
First, note that it's an analogy. It's not an exact copy of the situation with copyright violation, it's similar.
But suppose there were ten other empty seats on the ride. Suppose you even agreed to get off if anybody else wanted to get on. Since there were other people on the ride, it's not like they had to run the thing just for you, and since there were other empty seats, it's not like you affected anyone else's riding experience. So long as you don't make a mess there's nothing to clean - and so long as you don't get injured there's nothing their insurance needs to pay for. So where's the loss?
The answer is that, first, since you got to ride for free, there's no longer any motivation for you to pay. Second, if any of the people who did pay realize that you didn't, they're going to be unhappy about your apparently unfair treatment - they'll be less likely to pay for their own ride in the future.
I'm just saying it's a similar situation and, whether you or I call it theft, in fact the law calls it theft. Thus there's precedent.
You agree that sticking "theft" to copyright violation is manipulation, and then, magically, you said that NOT sticking it would be manipulation too, so we should stick "theft". That kind of negative reasoning doesn't make sense:
Word choice always affects the message. Are you confused why I present two, seemingly contradictory points of view?
Actually, it's because I'm trying to show both sides of the argument.
Also - I did not say that not calling copyright violation "theft" was a form of manipulation, I said it doesn't accomplish anything. It's a kind of zero-value statement. Suppose I'm someone who thinks copyright violation is theft - and you're someone who doesn't... We argue all day, and finally you convince me that you're right. ...So what? All we've really worked out is a small matter of terminology. We haven't even established what copyright infringement is, just one possible thing that it isn't. Have you convinced me, for instance, that the government should not treat copyright infringement as a criminal offense? I guess that could depend upon the course of the discussion - but quite possibly not. This is why I say the matter of terminology is largely irrelevant. It misses the real issue.
What is your position on not calling copyright violation "rape" ? After all, the perpetrator is taking pleasure from someone else by force ?
Let's call it "rape". Not calling it "rape" would be manipulation, sure ? And arguing about it would be hair-splitting, wouldn't it ?
You are diving ever deeper into the murky waters of farcical nonsense based on ever-increasing distortions of what you think you remember I might have said about something. I love using good logic with bad data as a tool for farce, but I'm not in the mood. Let's skip it, shall we?
The reason the question has come up about whether "copyright violation" qualifies as "theft" is because copyright holders (i.e. people with some am
IMO, you've been trolled into answering.
It was not my intention to troll: merely to present the issue in a fairly neutral way.
You say "Of course CV is not stealing" - but the truth, I think, is that the definition is still under contention. Purists among us may not like the concept, but in a legal sense and in a practical sense, terms like "theft" are subject to redefinition and adaptation. And, of course, what is "obvious" and what is "supported by law" are often quite different. (This is in part due to the inherently subjective nature of what is deemed "obvious"...)
The closest analogue to CV "theft" is "theft of services" - for instance finding a way to ride the rides at an amusement park without paying for them. This isn't theft in the traditional sense of material theft (and one could argue nothing is lost, and thus, nothing's been stolen) but nevertheless, the act is considered a form of "theft" under the law.
The reason I referred to the issue as "hair-splitting" is because arguing over whether copyright violation is or isn't theft, for the most part, doesn't get one anywhere in the discussion of whether it's a valid action or not - whether or not it should be criminal, for instance. Calling copyright violation "theft" imposes a judgement that it should be considered criminal: but not calling it theft doesn't imply that it shouldn't be considered a crime.
Ironic does not mean what Alanis Morisette says it means.
That's why I thought an Alanis Morisette reference was appropriate in my response to someone who said (paraphrasing) that it's ironic that someone might be sympathetic to software piracy even if it hurts the economy of their country. It's not a particularly ironic thing.
Walking down the street -
"Single"
"Married"
"Single with Facebook Profile"
"Malda's GF - don't touch"
And don't forget...
"Jailbait"
"Psycho"
"Trap"
As soon as I get my hands on an API.
And some Japanese teenage girls... ...You know what? Forget the API.
I wonder what the trade deficit would be if they actually respected our intellectual property and paid the going rate for it instead of stealing it?
Good point. It's also ironic since most of /. would have you believe that piracy isn't stealing, and yet their own lives might be noticeably better if stated countries paid for, instead of pirated, American software.
Ironic? I don't know if that's the right word for it. That is nothing like rain on your wedding day, for instance.
I mean, look - yes, some people take that stance, that software piracy isn't "stealing". That point alone is just splitting hairs over terminology. The choice of words there is designed to make people sympathize with the copyright holders, and I think people don't always appreciate that sort of spin.
And then also consider - when we have a stance on what we consider right and wrong, in principle that should not be governed by what is best for ourselves, personally. This is why I don't see this situation as "ironic". If a specific person said both that they think copyright infringement is okay and that China's copyright infringement is bad, that would be hypocritical... But if someone believes copyright infringement is okay and doesn't care about China's copyright infringement or the economic consequences thereof, that's consistent. They've taken their stance and stuck to it.