More to the point than KFG's answer, Star Trek is not science.
The real question is why objects would disappear, not why they wouldn't. In the real world, everything has to go somewhere and the idea that you can tear something apart at the molecular level and send it somewhere in a "beam" is absurd.
Nuclear waste is dangerous, but it's not magically dangerous. If we send it up in sufficiently small loads, scattering one across what is probably an isolated area isn't going to be the end of the world. We can clean it up; it doesn't magically contaminate everything it touches for ever and ever with no ability to clean it up. It's just a hazardous material.
Plus, the containers are already going to have to be strong just to survive normal stresses. I wouldn't be surprised that they already will be specced to survive most catastrophic releases.
I say this because it's important that people not think that radioactive waste is so magically dangerous that we always need to add "just one more layer" of protection before we're somehow 100% from the radioactivity bogeyman, and thus never take advantage of one of the better energy sources we have. It's an engineering problem, nothing more.
Ultimately, this point is moot, because the general public already does see radioactivity as magically dangerous and the magical thinkers are going to put themselves into the situation where they'd rather have the (magically dangerous) waste with them on the planet, but out of sight, rather than actually removed from our living space, but briefly and highly-visibly in the air.... There's a reason I keep coming back to the word "magical". Nothing makes even normally rational, scientifically-minded people unhinge their minds like adding the word "radioactive" to the discussion.
And that's what I meant by bending the definition around to make it a more interesting question.
But I reject the idea that you can take the question and my answer, and then choose the reading of the question that makes my answer the worst. (I'm not offended, I'm just talking semantics here.) I answered the question as given; bending it after the fact is unfair.
If you want to talk about ultimate outcomes of the human race, that's great, but you need to put that in the question. The question as written seems to imply a question about individuals.
You also bend the definition of memories into a very specific, almost philosophical definition. I stuck to a biological definition, which, again, in the absence of further clarification up front is a perfectly defensible position, and you can make a good argument that it's the natural definition to use, especially in an individual context.
The reason I reject the idea that you can pick the definitions after the fact is that if I had answered your question, you could have equally well turned around and said "Well, I was talking about individual biological memories. 1/10." That's not an argument, that's a logic game, and that's not a valid grade, it's a clusterfuck.
Do memories hinder or help people in their effort to learn from the past and succeed in the present?
Holy cow, was that an essay question?
"Given that people with no memories demonstrably fail to learn anything, including simple things like where they are or what day it is, clearly they help."
If I were taking this test, I could easily expand that into the 5-Paragraph Magic Form I was taught for writing Unreadable Insipid Essays (TM), but why? For that matter I could cut that down by another half and still answer the question with this argument that I find undeniable.
(I could twist and stretch the definition of "memory" and "learning" to make it not true, but across most combination of definitions of memory and learning this argument holds. You'd have to get pretty pedantically biological to make it false.)
OK... so you end up with a site where user can post otherwise-illegal videos for free and won't be sued by any of the big companies.
I can see why this is in the interests of the users. I can see why this is in the interest of YouTube. But this is in the interests of the copyright owners because...?
Not gonna happen with YouTube ceasing to be the YouTube we know. If they weren't interested in defending their copyrights we already wouldn't have a problem.
I'll freely admit that I haven't thought the whole thing through and I'm not a language designer, but I'd submit having <> working on references to arrays the same way that it does on normal arrays would get me at least most of the way there, allowing me to pass a scalar that provides an overloaded <> or a ref to an array and have the behavior flattened. Currently, that's a "Not a GLOB reference" error.
Enough that I'd wipe off the language support part of the advantage, anyhow. (Libraries would take some time but that's inevitable.)
OK, that's what I get for taking people's examples at face value and not checking them.
I've played around a bit more and found that while (my $val = <@something>) mostly does what I'm looking for, but I'm still not seeing an obvious way to take <@something> and get a reference to that iterator that I can pass somewhere else through syntax, rather than wrapping it in my ArrayIterator blessed-scalar class. Which means I still can't see a clean way to write a function to take an array or an iterator without writing a ref($it) eq 'ARRAY' check, which is still enough to keep libraries from supporting iterators in general, and the perl modules I'm seeing say that there hasn't been a consensus on what to do about this point, either.
It's the little things that add up; there's a fundamental disconnect between "arrays" and "iterators" that is just barely enough to keep you from using one as the other routinely, which is what you need for extensive library support.
Previously, I complained that he left the definition of "highbrow" totally underspecified. I am amused to see this quote:
Apart from the Merchant Ivory analogy, I deliberately left the definition of "highbrow" rather vague, partly because I wanted to see what interpretation my readers would put on it.
A valid idea, but he should have said he was using a vague definition up-front. (I do it often myself, so I know it can be done without also destroying the ability to make a point.)
Here, I'm going to grump a little about another underlying assumption this guy seems to be taking axiomatically, which is that there are no games that have been high-brow yet. Be sure you understand what an "axiom" is: It is something you take as given to be true and bend the rest of your argument around. Axioms can not really be "wrong". The question is, does the implications of the axiom correspond to the real world in a useful or enlightening way?
My problem with taking this axiomatically is I think it sort of ends up begging the question he's trying to pose. If he actually took the time to formulate a definition of "high-brow", he could almost certainly find a game that matched the definition, which would wreck his point. Odds are, it would be one of the games he mentioned. Instead, he seems to simply take it as given that there have been no truly high-brow games.
I'm not certain that this "highbrow" adjective he's trying to develop is a useful distinction. (Note: The entire purpose of an adjective is to provide a useful distinction, between the nouns that possess the distinction and those that don't, with the obvious extension into fuzzy logic.) It splits the set of all of the thousands of existing games into two sets: "Lowbrow", containing all of them, and "highbrow", containing none of them. At the moment, this is the very definition of a useless adjective, and if nothing has met his bar yet (with the possible exception of a currently-unattainable technology component), nothing is going to.
(Note: While he doesn't state that he is using this axiom, I infer it from the previous paragraph; the best way to explain his tossing out every game in existence is that he axiomatically assumed none of them meet the bar. He claims it's because we're not there yet; I'm disputing this claim and claiming he stacked the deck from the get-go.)
In other words, you can't pass that iterator around. Instead, Perl expands it fully into a list, and passes the list around.
That's not passing an iterator, that's passing a list. Perl turns it into a list at the earliest available opportunity because nothing can handle getting an iterator. One of the key characteristics of an iterator is that it doesn't suck the entire file into memory all at once, even if you pass it into something else.
To the best of my knowledge, you just can't quite get to Python cleanliness. In Python, "for x in y" implicitly calls "iter(y)", and iter() on something that is already an iterator returns the iterator itself. Thus, "for x on y" is actually pretty powerful. So far as I know, there is no equivalent Perl formulation, because you can write "for my $x (@TrueList)" or "while (my $x = <$MyIter>)", but there is no syntactic way to unify that into the Python equivalent without an explicit check or wrap. (And I have a "ArrayWrap" iterator that lets you write "while (my $x = <$ArrayIter>)", although if $x might be an "undef" that you want that gets tricky; Python has better support there, too.)
I'd accept "while (my $x = <$UnblessedArrayRef>)" and live with the undef issue (I can guarantee no undef until the iterator is exhausted), but that doesn't work. (Just checked.) In Python the equivalent is still "for x in y". If I want to pass something an iterator that may either come from a list or a DB query, I have to manually wrap the list. (And I do that pretty frequently.)
And since I have DB queries that may be large and I really, truly want to iterate, not pull the whole list down in memory (when the list is already in memory, I've either already guaranteed the list is short or already paid the price), I don't have the option of just blowing the thing out to an array.
Perl has iterator support, but it's much thinner than Python's, and surprisingly it's more a syntactical problem than a language capability problem.
Context: I've been professionally programming Perl for years now. I prefer Python.
If you try Python again, and try to find ways of using the extra features it has that Perl either doesn't have, or are borderline impossible to effectively use, you'll actually get a better understanding of some of the value of Perl 6. Perl 6, at least on the feature checklist, will blow past Python if it manages to come out reasonably soon. (Whether or not it will be more useful remains to be seen, but I'm comfortably open-minded about that. Whether or not Python will also catch up in its own way, potentially before Perl 6 comes out, also remains to be seen; there has been longstanding interest in the Python world in many of the "optional static typing"-sort of things that Perl is adding, and Python will have the advantage of being able to see how Perl 6's design seems to be working out. Anyhow....)
Python generators seem like a gimmick until the day you write a useful generator that would be literally 5 times longer and more complicated without the generator support. In the latest Python, these have been updated to full co-routines (although it was already possible to do the same thing by making a generator out of a method of an instance, this is somewhat cleaner and the interface will be shared and that's good). I believe Perl will be picking up this feature and more.
Python's class system is a lot cleaner and I've found that once you wrap your head around metaclasses, they are a type of magic that can give a module an amazingly clean interface.
And one of my long-standing complaints about Perl is that its hashes can only use strings as keys; the ability to directly and fully use objects as keys is incredibly helpful. (I know there are some modules to try to fake that in Perl but they always seem to have dangerous "gotchas".)
The other nice thing that Perl 6 can offer that you can see in Python is simply that when these features are integrated and specified in the language, you can use them more fully to your advantage. You can write an iterator in Perl 5 and overload the <> operator to iterate on it, and I do. But libraries don't take iterators, they take "lists" or "hashes" or whatever. In Python, because the iterator support is built in, everything that in Perl would take a list for the purposes of iterating on it takes an iterator instead, which turns out to be incredibly flexible as you can now feed that function not merely an array, but an iterator that may pull things off the network, or feed it processed hash keys or values, or every process every node of a complicated data structure. (I've used that latter trick several times in a program with a tree-basis; create an iterator and specify the iterator's characteristics, then let the iterator worry about traversal while some other function does something to every node in the iterator, like save it to a file.)
Perl 6 should be able to do all of these things and more, and believe me, if it ever comes out it'll offer real value once you learn what's going on. Expect it to take probably a couple of years for the community to fully work out which patterns are the best.
In the meantime, Perl 6 is useless until it comes out. I hope it does, because it would definitely make my resume look a little more relevant.
Mr. Costikyan's comments are almost entirely based on an "inherent value" theory of games, which is an interesting philosophical idea but has neither predictive value nor practical value in the real world, where only "a thing is worth what somebody else will pay for it" actually works.
If you can't put a five-year-old game on the shelf and sell copies of it for $50, then, proof by concrete demonstration, the game isn't worth $50. If retailers can only move older games with deep discounts, then, proof by concrete demonstration, the value of the games has dropped over time.
You can complain that people should be more willing to try old games. That makes some sense to me, but I benefit greatly from that attitude since I no longer mind being a few years behind the curve if it means saving big bucks. But the value of those older games is still less than it used to be.
Pretty much happens to movies, TV, computer programs of all other kinds, and to some extent music (where what typically happens is that once the value of a CD drops far enough it simply disappears, rather than dropping in price, but it's the same effect).
There are two things now I'm looking for in tactics and RPGs now: Skippable cut scenes, and turns that don't take for-freakin' ever.
Advance Wars is the ideal; slow eye candy on one end of the options, dropping down to a quick blip and numbers changing on the other. FFX-2 actually did pretty well in this department, too, with the fancy battle animations that FF is known for being reducible to momentary blips inline with the rest of the battle.
(Not having endless random battles is beginning to factor in there, but I can still tolerate it, although probably only because I've been playing RPG games since they consisted of little more than random battles, like the Bard's Tale.)
I'm not sure if that's a stab at me or at PA or me for agreeing with them...
Uh, it's neither. It's total agreement with you. RPGs have gotten eaten by the "real time" buzzword, even though the idea really stinks. You just can't control multiple people in realtime. Don't try. If you want to do that, your "party" needs to be just the one character. That has been done successfully.
Same thing happened to strategy games. Try to find a turn-based strategy game. (I know of Civ. Any others that are still around?) Personally, I find the idea of a "strategy" game that also requires fast twitch responses to play successfully downright oxymoronic. Games are sacrificing (a certain kind of) depth at the altar of "real-time".
(Certainly there are "deep" fighting games like Soul Calibur, but that's not the same kind of deep I mean.)
I seriously doubt the rumble motor provides any feedback about how well it's doing. (The only thing that would be useful for is diagnostic purposes, and the human can already tell pretty well that rumble isn't working.) So, even when the rumble feature is present, from the console's point of view, the commands to start/stop/modulate the motor already go into a black hole and the programmer just has to trust that the rumble feature is working as intended.
At first I thought the FFXIII combat system might be a neat idea.
However, lately I've been playing Star Ocean: 'Till the End of Time and it has the same basic system, you control one character and the other two just go off and do their thing in a live-action combat system. And I'm not particularly enjoying it. Granted, Star Ocean really fucked up in having an incentive to keep your character out of the line of fire so that that damnably fragile "Bonus Battle Guage" doesn't get broken, thus encouraging the player to play a support character that just hangs out and sometimes heals people while the computer lays the smack down. But then, I wouldn't be surprised FFXIII ends up the same way, because predicting which support will become necessary when is certainly something the human will be better at.
So far, I still prefer the "Active Time System" of FFX or Grandia II by a mile. I'd also accept the FFX-2 combat system, at least in terms of timing. But don't get so stuck up the ass with the "real-time" buzzword that you sacrifice control over the team to its alter.
Doing the bare minimum at your job is not a praiseable accomplishment.
Improvement is.
If you emit nothing but negative feedback, if even improvement is met with negative feedback because the improvement doesn't make it to "perfection" or some other standard, the psychological result is as predictable as the sun rising tomorrow: Lack of interest in continuing to try and ever diminishing performance. It's a bit odd that anybody thinks relentless negativity can have any other effect. (But there are entire major ideologies currently built around this very idea, that a tarnished but pretty good product is so, so very bad that letting blackest evil win is preferable; identifying which is left as an exercise for the reader.)
Extra double bonus points for continually raising the putative bar every time someone comes close, and continuing to emit nothing but negative feedback. Triple bonus points for being even more critical as improvements are made and the remaining imperfections stand out that much more clearly.
But to be fair, is it just me or have they been doing a lot better lately? Certainly I've noticed fewer, and I've appreciated it.
I know it's more fun to bitch about people, but you ought to hand out some kudos every once in a while too. We could do with a bit more of that on the Intarweb.
Apparently, the basis of XSS is to make a link that appears like a valid URL but that will, in some clients, execute as a javascript code
No, that's just one way to do it. XSS is any insertion of Javascript code into a site that shouldn't be there, and there are a surprising number of ways to do that. <a href="javascript:alert('hi!')">text</a> is just one of the easier ones.
I say this because people need to be aware that links are not the only vector. My favorite one I've seen so far is <bgsound src='javascript:bad_code()'>. If you choose poorly and are trying to filter out bad tags (instead of what you should be doing, specifying only exactly what tags and attributes are allowed and forbidding anything else that looks like a tag), did you remember to block out the BGSOUND tag? If not, that auto-executes; it doesn't even need to be clicked. (IE may have closed that; I saw this in the IE 4 era.)
Well, with the first iterations of the time machine device, they did.
However, the movies made based on these events were never released from the studio archives, as they correctly guessed that once the novelty of watching a naked Arnold Schwarzenegger randomly spin in space and do nothing wore off, it wouldn't be a very compelling movie. You just can't carry a movie for an hour-and-a-half with that.
I don't live in the US, but even I can see that most news stations are firmly pro Bush. How else do you explain the free passes and non-quetsions that get askled of him.
"Not being as hard on Bush as you think they should be" does not constitute "supporting Bush".
Find me a Bush policy that the press actually supports, not just "doesn't bash on as much as you'd like".
As was recently pointed out here in another context, the average story about even a Bush speech will be a couple of snippets from his speech, often out-of-context, frequently so much so that the putative quotes actually say something he didn't, and generally if I read the speech and read their summary, I feel they focused either on the weakest or least important point of the speech while simply ignoring the rest. I don't think this constitutes being "pro-Bush".
As for not asking the hard questions, that's just because journalists aren't particularly capable of figuring out what the hard questions are. Also, given a choice between asking a hard question and getting their access potentially cut off, or just lobbing the soft question, they'll take the soft questions. (I select that example because it went all the way to the top.)
Slashdot Mirror
More to the point than KFG's answer, Star Trek is not science.
The real question is why objects would disappear, not why they wouldn't. In the real world, everything has to go somewhere and the idea that you can tear something apart at the molecular level and send it somewhere in a "beam" is absurd.
Nuclear waste is dangerous, but it's not magically dangerous. If we send it up in sufficiently small loads, scattering one across what is probably an isolated area isn't going to be the end of the world. We can clean it up; it doesn't magically contaminate everything it touches for ever and ever with no ability to clean it up. It's just a hazardous material.
... There's a reason I keep coming back to the word "magical". Nothing makes even normally rational, scientifically-minded people unhinge their minds like adding the word "radioactive" to the discussion.
Plus, the containers are already going to have to be strong just to survive normal stresses. I wouldn't be surprised that they already will be specced to survive most catastrophic releases.
I say this because it's important that people not think that radioactive waste is so magically dangerous that we always need to add "just one more layer" of protection before we're somehow 100% from the radioactivity bogeyman, and thus never take advantage of one of the better energy sources we have. It's an engineering problem, nothing more.
Ultimately, this point is moot, because the general public already does see radioactivity as magically dangerous and the magical thinkers are going to put themselves into the situation where they'd rather have the (magically dangerous) waste with them on the planet, but out of sight, rather than actually removed from our living space, but briefly and highly-visibly in the air.
And that's what I meant by bending the definition around to make it a more interesting question.
But I reject the idea that you can take the question and my answer, and then choose the reading of the question that makes my answer the worst. (I'm not offended, I'm just talking semantics here.) I answered the question as given; bending it after the fact is unfair.
If you want to talk about ultimate outcomes of the human race, that's great, but you need to put that in the question. The question as written seems to imply a question about individuals.
You also bend the definition of memories into a very specific, almost philosophical definition. I stuck to a biological definition, which, again, in the absence of further clarification up front is a perfectly defensible position, and you can make a good argument that it's the natural definition to use, especially in an individual context.
The reason I reject the idea that you can pick the definitions after the fact is that if I had answered your question, you could have equally well turned around and said "Well, I was talking about individual biological memories. 1/10." That's not an argument, that's a logic game, and that's not a valid grade, it's a clusterfuck.
Yes, I was answering the question, not trying for High School Grammar Correctness (TM), which has only a weak relation to Real World Grammar (TM).
:)
I freely use "they" as an indefinite singular pronoun and you can't stop me.
"Given that people with no memories demonstrably fail to learn anything, including simple things like where they are or what day it is, clearly they help."
If I were taking this test, I could easily expand that into the 5-Paragraph Magic Form I was taught for writing Unreadable Insipid Essays (TM), but why? For that matter I could cut that down by another half and still answer the question with this argument that I find undeniable.
(I could twist and stretch the definition of "memory" and "learning" to make it not true, but across most combination of definitions of memory and learning this argument holds. You'd have to get pretty pedantically biological to make it false.)
OK... so you end up with a site where user can post otherwise-illegal videos for free and won't be sued by any of the big companies.
I can see why this is in the interests of the users. I can see why this is in the interest of YouTube. But this is in the interests of the copyright owners because...?
Not gonna happen with YouTube ceasing to be the YouTube we know. If they weren't interested in defending their copyrights we already wouldn't have a problem.
I'd sing your praises and be happy to be wrong.
I'll freely admit that I haven't thought the whole thing through and I'm not a language designer, but I'd submit having <> working on references to arrays the same way that it does on normal arrays would get me at least most of the way there, allowing me to pass a scalar that provides an overloaded <> or a ref to an array and have the behavior flattened. Currently, that's a "Not a GLOB reference" error.
Enough that I'd wipe off the language support part of the advantage, anyhow. (Libraries would take some time but that's inevitable.)
OK, that's what I get for taking people's examples at face value and not checking them.
I've played around a bit more and found that while (my $val = <@something>) mostly does what I'm looking for, but I'm still not seeing an obvious way to take <@something> and get a reference to that iterator that I can pass somewhere else through syntax, rather than wrapping it in my ArrayIterator blessed-scalar class. Which means I still can't see a clean way to write a function to take an array or an iterator without writing a ref($it) eq 'ARRAY' check, which is still enough to keep libraries from supporting iterators in general, and the perl modules I'm seeing say that there hasn't been a consensus on what to do about this point, either.
It's the little things that add up; there's a fundamental disconnect between "arrays" and "iterators" that is just barely enough to keep you from using one as the other routinely, which is what you need for extensive library support.
Here, I'm going to grump a little about another underlying assumption this guy seems to be taking axiomatically, which is that there are no games that have been high-brow yet. Be sure you understand what an "axiom" is: It is something you take as given to be true and bend the rest of your argument around. Axioms can not really be "wrong". The question is, does the implications of the axiom correspond to the real world in a useful or enlightening way?
My problem with taking this axiomatically is I think it sort of ends up begging the question he's trying to pose. If he actually took the time to formulate a definition of "high-brow", he could almost certainly find a game that matched the definition, which would wreck his point. Odds are, it would be one of the games he mentioned. Instead, he seems to simply take it as given that there have been no truly high-brow games.
I'm not certain that this "highbrow" adjective he's trying to develop is a useful distinction. (Note: The entire purpose of an adjective is to provide a useful distinction, between the nouns that possess the distinction and those that don't, with the obvious extension into fuzzy logic.) It splits the set of all of the thousands of existing games into two sets: "Lowbrow", containing all of them, and "highbrow", containing none of them. At the moment, this is the very definition of a useless adjective, and if nothing has met his bar yet (with the possible exception of a currently-unattainable technology component), nothing is going to.
(Note: While he doesn't state that he is using this axiom, I infer it from the previous paragraph; the best way to explain his tossing out every game in existence is that he axiomatically assumed none of them meet the bar. He claims it's because we're not there yet; I'm disputing this claim and claiming he stacked the deck from the get-go.)
In other words, you can't pass that iterator around. Instead, Perl expands it fully into a list, and passes the list around.
That's not passing an iterator, that's passing a list. Perl turns it into a list at the earliest available opportunity because nothing can handle getting an iterator. One of the key characteristics of an iterator is that it doesn't suck the entire file into memory all at once, even if you pass it into something else.
To the best of my knowledge, you just can't quite get to Python cleanliness. In Python, "for x in y" implicitly calls "iter(y)", and iter() on something that is already an iterator returns the iterator itself. Thus, "for x on y" is actually pretty powerful. So far as I know, there is no equivalent Perl formulation, because you can write "for my $x (@TrueList)" or "while (my $x = <$MyIter>)", but there is no syntactic way to unify that into the Python equivalent without an explicit check or wrap. (And I have a "ArrayWrap" iterator that lets you write "while (my $x = <$ArrayIter>)", although if $x might be an "undef" that you want that gets tricky; Python has better support there, too.)
I'd accept "while (my $x = <$UnblessedArrayRef>)" and live with the undef issue (I can guarantee no undef until the iterator is exhausted), but that doesn't work. (Just checked.) In Python the equivalent is still "for x in y". If I want to pass something an iterator that may either come from a list or a DB query, I have to manually wrap the list. (And I do that pretty frequently.)
And since I have DB queries that may be large and I really, truly want to iterate, not pull the whole list down in memory (when the list is already in memory, I've either already guaranteed the list is short or already paid the price), I don't have the option of just blowing the thing out to an array.
Perl has iterator support, but it's much thinner than Python's, and surprisingly it's more a syntactical problem than a language capability problem.
Context: I've been professionally programming Perl for years now. I prefer Python.
If you try Python again, and try to find ways of using the extra features it has that Perl either doesn't have, or are borderline impossible to effectively use, you'll actually get a better understanding of some of the value of Perl 6. Perl 6, at least on the feature checklist, will blow past Python if it manages to come out reasonably soon. (Whether or not it will be more useful remains to be seen, but I'm comfortably open-minded about that. Whether or not Python will also catch up in its own way, potentially before Perl 6 comes out, also remains to be seen; there has been longstanding interest in the Python world in many of the "optional static typing"-sort of things that Perl is adding, and Python will have the advantage of being able to see how Perl 6's design seems to be working out. Anyhow....)
Python generators seem like a gimmick until the day you write a useful generator that would be literally 5 times longer and more complicated without the generator support. In the latest Python, these have been updated to full co-routines (although it was already possible to do the same thing by making a generator out of a method of an instance, this is somewhat cleaner and the interface will be shared and that's good). I believe Perl will be picking up this feature and more.
Python's class system is a lot cleaner and I've found that once you wrap your head around metaclasses, they are a type of magic that can give a module an amazingly clean interface.
And one of my long-standing complaints about Perl is that its hashes can only use strings as keys; the ability to directly and fully use objects as keys is incredibly helpful. (I know there are some modules to try to fake that in Perl but they always seem to have dangerous "gotchas".)
The other nice thing that Perl 6 can offer that you can see in Python is simply that when these features are integrated and specified in the language, you can use them more fully to your advantage. You can write an iterator in Perl 5 and overload the <> operator to iterate on it, and I do. But libraries don't take iterators, they take "lists" or "hashes" or whatever. In Python, because the iterator support is built in, everything that in Perl would take a list for the purposes of iterating on it takes an iterator instead, which turns out to be incredibly flexible as you can now feed that function not merely an array, but an iterator that may pull things off the network, or feed it processed hash keys or values, or every process every node of a complicated data structure. (I've used that latter trick several times in a program with a tree-basis; create an iterator and specify the iterator's characteristics, then let the iterator worry about traversal while some other function does something to every node in the iterator, like save it to a file.)
Perl 6 should be able to do all of these things and more, and believe me, if it ever comes out it'll offer real value once you learn what's going on. Expect it to take probably a couple of years for the community to fully work out which patterns are the best.
In the meantime, Perl 6 is useless until it comes out. I hope it does, because it would definitely make my resume look a little more relevant.
OK, probably more than 10-15 years from now, but, yes.
Mr. Costikyan's comments are almost entirely based on an "inherent value" theory of games, which is an interesting philosophical idea but has neither predictive value nor practical value in the real world, where only "a thing is worth what somebody else will pay for it" actually works.
If you can't put a five-year-old game on the shelf and sell copies of it for $50, then, proof by concrete demonstration, the game isn't worth $50. If retailers can only move older games with deep discounts, then, proof by concrete demonstration, the value of the games has dropped over time.
You can complain that people should be more willing to try old games. That makes some sense to me, but I benefit greatly from that attitude since I no longer mind being a few years behind the curve if it means saving big bucks. But the value of those older games is still less than it used to be.
Pretty much happens to movies, TV, computer programs of all other kinds, and to some extent music (where what typically happens is that once the value of a CD drops far enough it simply disappears, rather than dropping in price, but it's the same effect).
Oh, hey, forgot about that. I think if I stop in to my local Gamestop and they have that I may just trade Star Ocean in for it without finishing.
Thanks.
There are two things now I'm looking for in tactics and RPGs now: Skippable cut scenes, and turns that don't take for-freakin' ever.
Advance Wars is the ideal; slow eye candy on one end of the options, dropping down to a quick blip and numbers changing on the other. FFX-2 actually did pretty well in this department, too, with the fancy battle animations that FF is known for being reducible to momentary blips inline with the rest of the battle.
(Not having endless random battles is beginning to factor in there, but I can still tolerate it, although probably only because I've been playing RPG games since they consisted of little more than random battles, like the Bard's Tale.)
Perhaps it's a global version of Quantum Immortality.
(I don't "believe" in the multiverse (while acknowledging that my "belief" is irrelevant), but it's an interesting idea.)
Same thing happened to strategy games. Try to find a turn-based strategy game. (I know of Civ. Any others that are still around?) Personally, I find the idea of a "strategy" game that also requires fast twitch responses to play successfully downright oxymoronic. Games are sacrificing (a certain kind of) depth at the altar of "real-time".
(Certainly there are "deep" fighting games like Soul Calibur, but that's not the same kind of deep I mean.)
I seriously doubt the rumble motor provides any feedback about how well it's doing. (The only thing that would be useful for is diagnostic purposes, and the human can already tell pretty well that rumble isn't working.) So, even when the rumble feature is present, from the console's point of view, the commands to start/stop/modulate the motor already go into a black hole and the programmer just has to trust that the rumble feature is working as intended.
"Emulating" an event black hole isn't that hard.
At first I thought the FFXIII combat system might be a neat idea.
However, lately I've been playing Star Ocean: 'Till the End of Time and it has the same basic system, you control one character and the other two just go off and do their thing in a live-action combat system. And I'm not particularly enjoying it. Granted, Star Ocean really fucked up in having an incentive to keep your character out of the line of fire so that that damnably fragile "Bonus Battle Guage" doesn't get broken, thus encouraging the player to play a support character that just hangs out and sometimes heals people while the computer lays the smack down. But then, I wouldn't be surprised FFXIII ends up the same way, because predicting which support will become necessary when is certainly something the human will be better at.
So far, I still prefer the "Active Time System" of FFX or Grandia II by a mile. I'd also accept the FFX-2 combat system, at least in terms of timing. But don't get so stuck up the ass with the "real-time" buzzword that you sacrifice control over the team to its alter.
If you emit nothing but negative feedback, if even improvement is met with negative feedback because the improvement doesn't make it to "perfection" or some other standard, the psychological result is as predictable as the sun rising tomorrow: Lack of interest in continuing to try and ever diminishing performance. It's a bit odd that anybody thinks relentless negativity can have any other effect. (But there are entire major ideologies currently built around this very idea, that a tarnished but pretty good product is so, so very bad that letting blackest evil win is preferable; identifying which is left as an exercise for the reader.)
Extra double bonus points for continually raising the putative bar every time someone comes close, and continuing to emit nothing but negative feedback. Triple bonus points for being even more critical as improvements are made and the remaining imperfections stand out that much more clearly.
But to be fair, is it just me or have they been doing a lot better lately? Certainly I've noticed fewer, and I've appreciated it.
I know it's more fun to bitch about people, but you ought to hand out some kudos every once in a while too. We could do with a bit more of that on the Intarweb.
Yes. That would be worth at least 11,620 off your Slashdot UID.
I say this because people need to be aware that links are not the only vector. My favorite one I've seen so far is <bgsound src='javascript:bad_code()'>. If you choose poorly and are trying to filter out bad tags (instead of what you should be doing, specifying only exactly what tags and attributes are allowed and forbidding anything else that looks like a tag), did you remember to block out the BGSOUND tag? If not, that auto-executes; it doesn't even need to be clicked. (IE may have closed that; I saw this in the IE 4 era.)
Well, with the first iterations of the time machine device, they did.
However, the movies made based on these events were never released from the studio archives, as they correctly guessed that once the novelty of watching a naked Arnold Schwarzenegger randomly spin in space and do nothing wore off, it wouldn't be a very compelling movie. You just can't carry a movie for an hour-and-a-half with that.
Find me a Bush policy that the press actually supports, not just "doesn't bash on as much as you'd like".
As was recently pointed out here in another context, the average story about even a Bush speech will be a couple of snippets from his speech, often out-of-context, frequently so much so that the putative quotes actually say something he didn't, and generally if I read the speech and read their summary, I feel they focused either on the weakest or least important point of the speech while simply ignoring the rest. I don't think this constitutes being "pro-Bush".
As for not asking the hard questions, that's just because journalists aren't particularly capable of figuring out what the hard questions are. Also, given a choice between asking a hard question and getting their access potentially cut off, or just lobbing the soft question, they'll take the soft questions. (I select that example because it went all the way to the top.)