I recall the time they found those fossilized mosquitoes And before long, they were cloning DNA Now I'm being chased by some irate veloceraptors Well, believe me... this has been one lousy day
Jurassic Park is frightning in the dark All the dinosaurs are running wild Someone shut the fence off in the rain I admit it's kinda eerie But this proves my chaos theory And I don't think I'll be coming back again Oh no
I cannot approve of this attraction 'Cause getting disemboweled always makes me kinda mad A huge tyrannosaurus ate our lawer Well, I suppose that proves... they're really not all bad
Jurassic Park is frightning in the dark All the dinosaurs are running wild Someone let T. Rex out of his pen I'm afraid those things'll harm me 'Cause they sure don't act like Barney And they think that I'm their dinner, not their friend Oh no
Jurassic Park is frightning in the dark All the dinosaurs are running wild What a crummy weekend this has been Well, this sure ain't no E-ticket Think I'll tell them where to stick it 'Cause I'm never coming back this way again Oh no... oh no
I can tell the difference between a constant and a variable, and I know whether to put an apostrophe in 'yours'. If your IQ really is slightly above average, then the average is pretty woeful these days, and I'm glad mine isn't down there.
Your 'easy peasy' solution isn't that easy peasy after all if you apply some thought to it, of course. Because you have to know what time period to calculate your k over, and as the overhead changes you're either going to end up with too long a period, in which case you'll still be calculating based on old data, or you're going to end up with too short a period in which case your progress bar will jerk around frantically as the load on the system varies.
The real answer is the one that you dismissed; it's impossible to create an accurate progress bar representing the time taken by an operation, because things that change that time can (and will) happen during the operation, which will leave you in an inaccurate state for some part of the operation, or lead to counter-intuitive behaviour of the progress bar. Given that, the goal of the developer shouldn't be to create an accurate progress bar; it should be to create one that gives the impression of being accurate enough or change the way progress is represented so that it doesn't give the misleading impression that it's about providing an accurate time to completion.
All these constants go out of the window if anything else starts accessing the drive as well, of course, and they're actually variable based on file system and a variety of other things.
The relevant questions were asked of the jury. Hogan gave misleading answers to those questions.
If the jury had found for Samsung on every point, despite Hogan's possible bias against Samsung and their position, of course there wouldn't be a basis to demand a new trial. A better question might be whether Apple would be demanding a new trial had an anti-Apple zealot made it onto the jury by concealing their past history with Apple and then browbeating the other jurors into ignoring and misinterpreting law in a way that favoured Samsung.
See, you're proving the point that being able to write more than 140 characters doesn't prevent you from being an irrational asshat with nothing useful to say. Everything you say in your first paragraph is inaccurate. Everything you say in your second paragraph is unsupported and subjective.
In what way does imposing a 140-character limit constitute 'dumbing down'? You haven't done anything to defend that view, which isn't supported by reality. Yes, some people write dumb things in 140 characters. But some people write dumb things in more than 140 characters. Limiting the space does at least force you to consider what you're saying, especially if your initial attempt runs to slightly more than 140 characters, as you have to decide what is redundant and what isn't.
The truth of it is as always that dumb people will say dumb things, and smart people will say smart things. The smart ones will use Twitter in ways where it's appropriate and other resources where Twitter isn't the right tool for the job. The dumb ones will make incoherent anonymous personal attacks on people on Slashdot, apparently.
It's easy to fall into the trap of thinking that Twitter is just for inanity, because unfortunately that's the majority content of the internet in general. But it can be useful, and the 140-character limit is not inherently dumbing down. And I suspect you know it, which is why you haven't defended that claim in the slightest and resorted to pitiful anonymous ad hominem.
1. Good rebuttal. No, seriously, proof by dogmatic assertion is great.
Of course it causes all these things. If you're refusing to modify existing code, then you can't refactor it to handle extra cases, which is going to lead to unnecessary duplication (and probably hideous cut/paste code). It will expand the size of the codebase, because this is what happens when you add code, which will eventually cause problems on some platforms (trust me - I've been there).
2. Turn in your coding license. Now. Except for a very small subset of coders working on very specialised projects and using formal proofs of correctness, anyone who claims their code contains (or should contain) no bugs when first written is a fool, and a dangerous fool at that.
3. That may be your experience. Rolling back version control history to find out where defects were introduced can be very useful, and if the tools are good enough (which they are) it isn't exactly difficult either.
As for the idea that you can't track all dependencies from the deleted code to the whole system, if that's true to the extent that you claim then your design is screwed.
Unfortunately bitter experience prevents me from being too nasty on this one, because too many times I've been through the process of having good test policies in place, followed by senior management decreeing that in order to meet deadlines, testing and documentation will have to fall by the wayside 'just for a few weeks'. I know it would count as justifiable homicide, but I still can't afford the court time.;)
1. Not always true by a long way, especially when you're coding for devices with limited space. It can also lead to unnecessary duplication, overly convoluted logic to avoid modifying existing code, unnecessary duplication, poor performance and unnecessary duplication.
2. Bug fixes are dangerous? Really? That could have saved me a lot of time at my job before last.:D
3. If you think deleting code causes information to be lost, you need to review your source code control policies. Now. Yes, it can be dangerous to remove crufty looking old code, because it frequently contains years worth of minor fixes to deal with bizarre edge cases, device oddities and the suchlike. But you know what? Those should all be well commented in the code, and covered by appropriate tests that will ensure your new version works too. If they're not, you might need to review some other policies as well.
Except we know where Apple stands on competition. They'd rather do it in the courtroom than in the labs these days. Which is why they're rushing to sue people for using black rounded rectangles, and rushing equally quickly to copy the 7" tablet form factor that they swore nobody wanted.
THE COURT: Okay. Welcome back. Please take a seat. We had a few more departures in your absence. Let's continue with the questions. The next question is, have you or a family member or someone very close to you ever been involved in a lawsuit, either as a plaintiff, a defendant, or as a witness?
You need to read Samsung's reply, which is in the Groklaw article linked from the page. It answers all your points, and does it in a clear and definitive way. It also makes clear a lot of their other arguments, which you conveniently ignore here; that he indisputably failed to follow the judge's instructions, introducing inaccurate 'expert testimony' of his own that was wrong on just about every point of law that the jury ruled on. It's indisputable because he's been running his mouth off about it ever since.
Stop being disingenuous. It's pretty clear that Samsung stole the design for their shoe completely from Apple. How else would they have come up with a design that's black and roughly foot shaped? Coincidence?
But... that's not what we do.:) Rumblefish works specifically for independent artists, not labels or rights organizations.
I guess what you need to do now is get those specific birds to post on Slashdot about how happy they are with the service they're receiving from Rumblefish, then.
You shouldn't be 'working on resolving the issue with eeplox's video'. You should have released it immediately, apologised, and passed on a sum of money to compensate him for any advertisements you benefited from on his video and the inconvenience and insult you've caused him.
Then maybe you could look at putting the PR side of this to rights.
Re:I have a shorter Tetris implementation
on
Tetris In 140 Bytes
·
· Score: 1
Aw. It's kind of endearing when idiots try to use logic.
Let's look at where the flaws in your argument are, shall we? From your list of statements:
1. This is irrelevant to your argument, as you don't use it in your later reasoning. You're trying to associate your argument with an obvious fact to strengthen it by its proximity to that fact, I guess. 2. This is a very incomplete statement - deliberately so to conceal the dishonesty in your approach. A fuller version of it is as follows: "In some games, one player reaching a victory condition can trigger defeat conditions for other players." 3. This is a restating of what you're trying and failing to demonstrate.
The modified version of statement 2 is something we agree on, and we've already discussed some examples.
Your initial paragraph, though, contains a heinous logical flaw. What you're claiming is this: there are some victory conditions that also trigger defeat. Therefore, all victory conditions trigger defeat. That's a doozy of a logical fallacy. It's the "Some birds are green. A blackbird is a bird. Therefore a blackbird is green." argument.
Your claim that statement 2 leads to statement three is also utterly unsupported. Even if we accepted your definition of statement 2 rather than the accurate one, it's fundamentally the same logical problem; you're making an unwarranted generalisation from the fact that some defeat conditions can trigger a victory to a claim that all defeat conditions can trigger a victory, which isn't true.
You're trying to argue that black is white.
I'm also going to bring this up in every response to you from now on, because you're too much of a coward to address it. In support of your claim that all games must have victory conditions, you cited "Game Development Essentials" by Jeannie Novak. However, on page 185 of this book, Jeannie Novak writes:
Many puzzle games have no victory conditions. In Tetris, the game just gets increasingly difficult until the player decides to stop.
So, your options:
1) You are wrong. I am right. Games can have no victory conditions, and industry experts give Tetris as an example of such a game. 2) You claim to be right, and also accuse the industry experts you earlier said should be trusted are lying hypocritical asses who know nothing about games.
I'll give you a clue. It's option one. And if you had any intellectual integrity you'd apologise for your mistake and stop digging.
Re:I have a shorter Tetris implementation
on
Tetris In 140 Bytes
·
· Score: 1
You're still trying to fudge things, I see? The first two victory conditions you describe exist in some modes of some versions of Tetris and yes, you can see them as victory conditions. The third thing you list is not a victory condition. It is a loss condition. This is why the industry expert you cited in one of your other replies says that such games have no victory conditions.
You made the appeal to authority; your authorities do not back you up. This is where you admit you were wrong, or demonstrate you are delusional. These are the only two options you have. Sorry.
Re:I have a shorter Tetris implementation
on
Tetris In 140 Bytes
·
· Score: 1
Multiplayer Tetris does not have the same victory condition as single player Tetris, though. The condition for being the winner in two player Tetris is to still be playing when the other player has lost. At this point you have won the game. You are the victor, and nothing that then happens will change this fact. Some implementations will stop gameplay immediately at that point and throw up a "Player One Wins!" message. Others may allow the player to continue. But in both cases, that player is the winner of the multiplayer game.
We can extrapolate that for any number of players. In an n-player game of multiplayer Tetris, the victory condition is to still be playing when (n-1) players have lost. In a two-player game, one player must lose. In a three-player game, two must lose. In a 32-player networked monstrosity of a Tetris game, 31 players must lose before the last man standing is declared the winner. I take it you see the problem when we apply this to one player - the victory condition becomes that 0 players have lost. The game becomes 'press start to win'. Clearly that's not the case - you wouldn't accept a Tetris game that when you press start immediately throws up a message saying "Player One Wins!" and stops - so this victory condition isn't valid.
I'd like to deliver a bit of a killer blow to your argument now. You reference "Game Development Essentials" by Jeannie Novak. I'd like to quote to you from the top of page 185.
Many puzzle games have no victory conditions. In Tetris, the game just gets increasingly difficult until the player decides to stop.
Your industry professionals don't agree with you. They agree with me. She also mentions other types of game that don't have explicit victory conditions, but it's hard to get more specific than that statement. Many puzzle games have no victory conditions - exactly as I've claimed all along. She even cites the very same example as I did.
Slashdot Mirror
I recall the time they found those fossilized mosquitoes
And before long, they were cloning DNA
Now I'm being chased by some irate veloceraptors
Well, believe me... this has been one lousy day
Jurassic Park is frightning in the dark
All the dinosaurs are running wild
Someone shut the fence off in the rain
I admit it's kinda eerie
But this proves my chaos theory
And I don't think I'll be coming back again
Oh no
I cannot approve of this attraction
'Cause getting disemboweled always makes me kinda mad
A huge tyrannosaurus ate our lawer
Well, I suppose that proves... they're really not all bad
Jurassic Park is frightning in the dark
All the dinosaurs are running wild
Someone let T. Rex out of his pen
I'm afraid those things'll harm me
'Cause they sure don't act like Barney
And they think that I'm their dinner, not their friend
Oh no
Jurassic Park is frightning in the dark
All the dinosaurs are running wild
What a crummy weekend this has been
Well, this sure ain't no E-ticket
Think I'll tell them where to stick it
'Cause I'm never coming back this way again
Oh no... oh no
I wish I could determine pi
"Eureka!" cried the great inventor.
Christmas pudding, Christmas pie
To the problem's very center.
Twenty digits (omitting the 3, which everyone can remember anyway), and I find it very memorable.
Don't be foolish. Of course Steve Jobs didn't pick the wrong tablet size. If Jobs and reality are ever in conflict, reality is wrong.
In particular it isn't news to Linus. Which is how git got its name.
I can tell the difference between a constant and a variable, and I know whether to put an apostrophe in 'yours'. If your IQ really is slightly above average, then the average is pretty woeful these days, and I'm glad mine isn't down there.
Your 'easy peasy' solution isn't that easy peasy after all if you apply some thought to it, of course. Because you have to know what time period to calculate your k over, and as the overhead changes you're either going to end up with too long a period, in which case you'll still be calculating based on old data, or you're going to end up with too short a period in which case your progress bar will jerk around frantically as the load on the system varies.
The real answer is the one that you dismissed; it's impossible to create an accurate progress bar representing the time taken by an operation, because things that change that time can (and will) happen during the operation, which will leave you in an inaccurate state for some part of the operation, or lead to counter-intuitive behaviour of the progress bar. Given that, the goal of the developer shouldn't be to create an accurate progress bar; it should be to create one that gives the impression of being accurate enough or change the way progress is represented so that it doesn't give the misleading impression that it's about providing an accurate time to completion.
All these constants go out of the window if anything else starts accessing the drive as well, of course, and they're actually variable based on file system and a variety of other things.
The relevant questions were asked of the jury. Hogan gave misleading answers to those questions.
If the jury had found for Samsung on every point, despite Hogan's possible bias against Samsung and their position, of course there wouldn't be a basis to demand a new trial. A better question might be whether Apple would be demanding a new trial had an anti-Apple zealot made it onto the jury by concealing their past history with Apple and then browbeating the other jurors into ignoring and misinterpreting law in a way that favoured Samsung.
And I think we all know the answer to that one.
See, you're proving the point that being able to write more than 140 characters doesn't prevent you from being an irrational asshat with nothing useful to say. Everything you say in your first paragraph is inaccurate. Everything you say in your second paragraph is unsupported and subjective.
In what way does imposing a 140-character limit constitute 'dumbing down'? You haven't done anything to defend that view, which isn't supported by reality. Yes, some people write dumb things in 140 characters. But some people write dumb things in more than 140 characters. Limiting the space does at least force you to consider what you're saying, especially if your initial attempt runs to slightly more than 140 characters, as you have to decide what is redundant and what isn't.
The truth of it is as always that dumb people will say dumb things, and smart people will say smart things. The smart ones will use Twitter in ways where it's appropriate and other resources where Twitter isn't the right tool for the job. The dumb ones will make incoherent anonymous personal attacks on people on Slashdot, apparently.
It's easy to fall into the trap of thinking that Twitter is just for inanity, because unfortunately that's the majority content of the internet in general. But it can be useful, and the 140-character limit is not inherently dumbing down. And I suspect you know it, which is why you haven't defended that claim in the slightest and resorted to pitiful anonymous ad hominem.
The ability to get a coherent message into 140 characters isn't 'dumbing down' by any measure. Verbal diarrhea can be every bit as bad.
1. Good rebuttal. No, seriously, proof by dogmatic assertion is great.
Of course it causes all these things. If you're refusing to modify existing code, then you can't refactor it to handle extra cases, which is going to lead to unnecessary duplication (and probably hideous cut/paste code). It will expand the size of the codebase, because this is what happens when you add code, which will eventually cause problems on some platforms (trust me - I've been there).
2. Turn in your coding license. Now. Except for a very small subset of coders working on very specialised projects and using formal proofs of correctness, anyone who claims their code contains (or should contain) no bugs when first written is a fool, and a dangerous fool at that.
3. That may be your experience. Rolling back version control history to find out where defects were introduced can be very useful, and if the tools are good enough (which they are) it isn't exactly difficult either.
As for the idea that you can't track all dependencies from the deleted code to the whole system, if that's true to the extent that you claim then your design is screwed.
Unfortunately bitter experience prevents me from being too nasty on this one, because too many times I've been through the process of having good test policies in place, followed by senior management decreeing that in order to meet deadlines, testing and documentation will have to fall by the wayside 'just for a few weeks'. I know it would count as justifiable homicide, but I still can't afford the court time. ;)
1. Not always true by a long way, especially when you're coding for devices with limited space. It can also lead to unnecessary duplication, overly convoluted logic to avoid modifying existing code, unnecessary duplication, poor performance and unnecessary duplication.
2. Bug fixes are dangerous? Really? That could have saved me a lot of time at my job before last. :D
3. If you think deleting code causes information to be lost, you need to review your source code control policies. Now. Yes, it can be dangerous to remove crufty looking old code, because it frequently contains years worth of minor fixes to deal with bizarre edge cases, device oddities and the suchlike. But you know what? Those should all be well commented in the code, and covered by appropriate tests that will ensure your new version works too. If they're not, you might need to review some other policies as well.
That's what the tests are for, surely? :D
Except we know where Apple stands on competition. They'd rather do it in the courtroom than in the labs these days. Which is why they're rushing to sue people for using black rounded rectangles, and rushing equally quickly to copy the 7" tablet form factor that they swore nobody wanted.
You'd be better off waiting for selenorhodanemod, azidodithiocarbonatemod or dicobalt-octacarbonylmod, maybe.
Well, it sure beats raising cattle.
There were no such court instructions. The 10 years claim has been thoroughly debunked. Three cheers for transcripts!
http://www.groklaw.net/article.php?story=20120923233451725
THE COURT: Okay. Welcome back. Please take a seat. We had a few more departures in your absence. Let's continue with the questions. The next question is, have you or a family member or someone very close to you ever been involved in a lawsuit, either as a plaintiff, a defendant, or as a witness?
You need to read Samsung's reply, which is in the Groklaw article linked from the page. It answers all your points, and does it in a clear and definitive way. It also makes clear a lot of their other arguments, which you conveniently ignore here; that he indisputably failed to follow the judge's instructions, introducing inaccurate 'expert testimony' of his own that was wrong on just about every point of law that the jury ruled on. It's indisputable because he's been running his mouth off about it ever since.
Stop being disingenuous. It's pretty clear that Samsung stole the design for their shoe completely from Apple. How else would they have come up with a design that's black and roughly foot shaped? Coincidence?
Amen. This is why cases of intentional homicide per capita are four times higher in the UK than the US.
http://en.wikipedia.org/wiki/List_of_countries_by_intentional_homicide_rate
Oh no, wait a second. It's the US where more people are intentionally murdered. Guess all that self-defence didn't really pay off...
This may be true. But the fact remains that you're making shit up, and recognising this doesn't imply any lack of smartness.
I guess what you need to do now is get those specific birds to post on Slashdot about how happy they are with the service they're receiving from Rumblefish, then.
You shouldn't be 'working on resolving the issue with eeplox's video'. You should have released it immediately, apologised, and passed on a sum of money to compensate him for any advertisements you benefited from on his video and the inconvenience and insult you've caused him.
Then maybe you could look at putting the PR side of this to rights.
Aw. It's kind of endearing when idiots try to use logic.
Let's look at where the flaws in your argument are, shall we? From your list of statements:
1. This is irrelevant to your argument, as you don't use it in your later reasoning. You're trying to associate your argument with an obvious fact to strengthen it by its proximity to that fact, I guess.
2. This is a very incomplete statement - deliberately so to conceal the dishonesty in your approach. A fuller version of it is as follows:
"In some games, one player reaching a victory condition can trigger defeat conditions for other players."
3. This is a restating of what you're trying and failing to demonstrate.
The modified version of statement 2 is something we agree on, and we've already discussed some examples.
Your initial paragraph, though, contains a heinous logical flaw. What you're claiming is this: there are some victory conditions that also trigger defeat. Therefore, all victory conditions trigger defeat. That's a doozy of a logical fallacy. It's the "Some birds are green. A blackbird is a bird. Therefore a blackbird is green." argument.
Your claim that statement 2 leads to statement three is also utterly unsupported. Even if we accepted your definition of statement 2 rather than the accurate one, it's fundamentally the same logical problem; you're making an unwarranted generalisation from the fact that some defeat conditions can trigger a victory to a claim that all defeat conditions can trigger a victory, which isn't true.
You're trying to argue that black is white.
I'm also going to bring this up in every response to you from now on, because you're too much of a coward to address it. In support of your claim that all games must have victory conditions, you cited "Game Development Essentials" by Jeannie Novak. However, on page 185 of this book, Jeannie Novak writes:
So, your options:
1) You are wrong. I am right. Games can have no victory conditions, and industry experts give Tetris as an example of such a game.
2) You claim to be right, and also accuse the industry experts you earlier said should be trusted are lying hypocritical asses who know nothing about games.
I'll give you a clue. It's option one. And if you had any intellectual integrity you'd apologise for your mistake and stop digging.
You're still trying to fudge things, I see? The first two victory conditions you describe exist in some modes of some versions of Tetris and yes, you can see them as victory conditions. The third thing you list is not a victory condition. It is a loss condition. This is why the industry expert you cited in one of your other replies says that such games have no victory conditions.
You made the appeal to authority; your authorities do not back you up. This is where you admit you were wrong, or demonstrate you are delusional. These are the only two options you have. Sorry.
Multiplayer Tetris does not have the same victory condition as single player Tetris, though. The condition for being the winner in two player Tetris is to still be playing when the other player has lost. At this point you have won the game. You are the victor, and nothing that then happens will change this fact. Some implementations will stop gameplay immediately at that point and throw up a "Player One Wins!" message. Others may allow the player to continue. But in both cases, that player is the winner of the multiplayer game.
We can extrapolate that for any number of players. In an n-player game of multiplayer Tetris, the victory condition is to still be playing when (n-1) players have lost. In a two-player game, one player must lose. In a three-player game, two must lose. In a 32-player networked monstrosity of a Tetris game, 31 players must lose before the last man standing is declared the winner. I take it you see the problem when we apply this to one player - the victory condition becomes that 0 players have lost. The game becomes 'press start to win'. Clearly that's not the case - you wouldn't accept a Tetris game that when you press start immediately throws up a message saying "Player One Wins!" and stops - so this victory condition isn't valid.
I'd like to deliver a bit of a killer blow to your argument now. You reference "Game Development Essentials" by Jeannie Novak. I'd like to quote to you from the top of page 185.
Your industry professionals don't agree with you. They agree with me. She also mentions other types of game that don't have explicit victory conditions, but it's hard to get more specific than that statement. Many puzzle games have no victory conditions - exactly as I've claimed all along. She even cites the very same example as I did.