Heck, I'm not sure I've even seen adult oriented software titles for the PC or anything else either in the last bunch of years.
It's currently too politically dangerous to make an AO game for a console, and I think the console licenser (Nintendo, Sony, etc.) wouldn't greenlight it under almost any conditions.
The problem is that politically, every game is presumed to be virtually thrown at children of all ages. This doesn't seem to come up with any other medium; everybody knows AO magazines, PC games, videos, etc. are kept from children, and even M video games are getting better protected all the time. But for some reason, politicians still get to get away with the implicit idea that any given nasty game could well be a pack-in with the console. (Note that it's so implicit that Slashdotters as a whole don't even notice the premise.)
If it weren't for that, the "blame video games" crowd wouldn't have a case at all.
So, no AO games on consoles anytime soon. It's still too easy for one AO game to become representative of console games as a whole.
(Note that ultimately, this failure of logic isn't so much prudery or excessively zealous "protect the children" problems, because if that was the problem these same people would be screaming about internet porn and other such things. It all comes down to this idea that any 11 child can wander into Gamestop and the salespeople will thrust Debbie Does Dallas: PS3 Edition into their hands at the earliest available opportunity.)
In the absense of further knowledge, I'm somewhat skeptical about the hard drives being sensitive enough, but I mean that in the original meaning of "skeptical", as in, updated pending further evidence, not forever committed to not believing in it. Clearly, this guy thinks they are sensitive enough.
But if that hurdle can be cleared, processed correctly the data will be very useful. Most objections Slashdotters are going to raise will be irrelevant. Local aberrations will be cancelled out at the supernode, because the aberrations will only appear at that one node. Simple interference at constant frequencies is also easy to detect and mask out with "Introduction to Signal Processing"-level signal processing.
Merging the data together is a bit more challenging but should be doable.
The only thing I don't see is talking about knowing where the machines are in the real world, which would be very helpful, and that may be coming later. The other thing is that the system probably won't work very well with a simple "IsEarthquake" signal coming out of the clients; the supernodes really ought to examine all the data from its clients and then decide if there's an earthquake. Otherwise, several correctly-timed local abberations could all look like "earthquakes", even with completely different characteristics, if all that is going to the supernode is "IsEarthquake". Of course, the real system may already have both of these things covered and the article merely oversimplified.
Upshot is, signal processing can do some very surprising things with data that seems to consist almost entirely of noise, if you have enough data coming in.
That summary is incorrect; Perl does not have destructuring assignment, and that example is writting be someone who doesn't understand Perl lists. (Not they can be blamed; list flattening is one of the more braindead Perl decisions and I believe it has been acknowledged as such by Larry himself.)
$ perl my $a, $b, $c; [$a, [$b, $c]] = [1, [2, 3]]; ^D Can't modify single ref constructor in scalar assignment at - line 2, near "];" Execution of - aborted due to compilation errors.
The example you give is functionally identical to ($a, $b, $c, $d) = (1, 2, 3, 4); the extra layer of parens is fully meaningless and ($a, $b, ($c, $d)) = (1, 2, 3, 4) works exactly the same.
Perl can assign lists to lists, so you might call it first-order destructuring, but it can't (to the best of my knowledge) do it arbitrarily deeply like Python, Erlang, and other fully-destructuring languages.
True. I was assuming we were talking about Mozilla, which AFAIK has one bug tracker for all. check check check... yup, Mozilla and Firefox are both on bugs.mozilla.org. (Can't link though because slashdot links are banned.)
If the GP is correct, it's still bad usage of the bug system. If Team A feels the fault belongs to Team B, the correct response is to move the bug to Team B, not to close the bug.
They may get into a fight about whose responsibility it is, but such a fight is also a bug, as such responsibilities in such a large project basically are a part of the code and should also be clearly delimited. If you insist on using languages without automatic garbage management, "who's responisibility it is to deallocate this memory" is a fundamental part of the API.
I can't provide full scientific proof, because there is no scientific proof in this domain, which I regret.
The best actual "proof" is the following: There was a study a while ago that established productivity for a given programmer appeared to be constant across lines of code, regardless of the language. This study was, IIRC, done a while ago, against C, assembly, and a couple of other suspects, but it was a pretty good spread. Programmers can turn out a couple hundred lines of non-trivial code a day. The idea is that since this is true, you want the language where you need the fewest lines of code, all else being equal, to accomplish your task.
The details of this have been debated endlessly. My personal call is that it is "mostly true", with some important caveats (programmers not gaming the LOC count, and the real important metric is "lines of code the programmer has to think about"; frameworks can churn out thousands of lines of templates (MFC was horrible about this) and they don't count), but experience does bear this general idea out.
The general LOC multiplier for Python vs. Java on the small scale is usually thought to be 5-10x. It's hard to know exactly how accurate this is because Java makes doing small things enormously complicated; "Hello World" is at least three lines of real code (class definition, static main method declaration, and the print call which itself involves a method chain of the form X.Y.Z("Hello World"), not just a simple statement). However, it is also a reasonable to believe that Java continues to make things hard as you scale up, and there are some simply Python patterns that are effectively impossible in Java or require jumping through very complicated hoops. I also believe there are a few cases of Java programs ported to Python that bear this out, or possibly even more. (Sometimes you can end up with some multiplicative gains, where the 5-10x improvements actually start layering on top of each other; in real terms this usually translates to the ability to create a superior design in Python than what you can do in Java. There's a reason Java's got all of these code generation tools and bytecode hacking tools, whereas Python mostly doesn't.)
The productivity multiplier does seem to be similar.
I cut down my estimate for C# because while I'll cop to never using C#, it does seem to me to be somewhat better. As I alluded to, adding in closures in 2.0 will also be a significant step forward. (Closures are a feature I recommend learning about, as for a long time I saw programmers talking about them and I had no clue what they meant, but once I got over the learning curve I understood why they were so important. Some of the worst problems with the worst workarounds in Java come from the lack of closures or any equivalent functionality, require fully separate large complicated classes with new interfaces to achieve the same functionality, all with no gain in safety or functionality. This is one of the places you tend to get the layered benefits I alluded to...) So I don't know if the gain is as large.
On the other hand, C# does seem to make heavy weather of certain very easy constructs in Python.
So that's the general evidence. If you want to learn more and get a lot of opinions, you can search "Python productivity" on the web.
But I know in your shoes I'd be downloading IronPython and putting it through its paces.:) It is proper to be skeptical about productivity gains in a world where we have no concrete measure of productivity, but since I don't have concrete standards, all I can tell you is that my own experince matches the Blub Paradox to a T; whenever I do have to code in Java or C++ or anything else like that, I will see simple solutions to my problem in Python that require the equivalent of tens or hundreds of lines of code in those languages. (Heck, even in Perl I've wished for generators on more than one occasion, and unrolling a generator is no fun.)
On the other hand, query: Do high-energy (ie: high mass) photons have a gravitational effect? Or do the formulae only work given a rest mass?
The formulas work for all mass-energy, which photons possess. Photons thus do technically interact via gravitation. However, if you do the math, you'll find that the interaction is very, very small, to put it lightly, so while it is technically wrong to say "photons don't interact with each other", it isn't very wrong.
Somewhere in the great online book Reflections on Relativity, there is a discussion of "kugelblitz"s, which is a theoretical black hole that consists entirely of energy, which could be just a lot of photons. The term isn't in much use in science (though I did find at least one arxiv.org reference) because it's not very useful; in practice, a photonic kugelblitz is impossible, and once such a black hole forms, it would be indistinguishable from any other black hole. But it is theoretically possible, because all mass-energy contributes to the gravitational field.
Re:Sometimes I feel like a Luddite...
on
IronPython 1.0 is Born
·
· Score: 4, Informative
Thus I need to use a language that will "just run" on systems that I have no control over.
I think IronPython compiles down to CLR bytecode, so if you're shipping managed C#, you could just as well ship IronPython and nobody would notice, which is the entire point of this article in the first place.
However, whether or not you could benefit from learning Python is a decision only you can make. Python may increase your productivity 2-3x over C# or more (and that's fairly conservative, usually), but only after you learn it, which could be months.
However, if you end up always choosing the short-term expedient answer of sticking with the language you know (and the environment you know), you lose out on any productivity gain you might get from another environment or language; this is a general point, not one specific to this case.
In general, the "common environments" (Java,.Net, etc.) have the worst productivity characteristics, because anything worse then them simply dies. Anything that survives the overwhelming advantages that being one of the Big Guys gets you is generally surviving for a reason. The longer the survival, the better the sign, and most languages you've actually heard of have actually been around for years.
Again, I'm not trying to push you, just point out that for the costs there are benefits, too. I say what I'm saying because I believe (and see) too many developers trapping themselves in local maxima by always making the short-term decision. Ultimately, it's no skin off my nose.
BTW you can build full real apps in JScript.
You can, but the lack of namespacing starts to get troublesome as you start trying to build libraries, or use the libraries of others. Later versions of Javascript, which JScript will presumably track, will help with this a lot. Although based on what I see, it's nearly learning a new language anyhow. (In fact, the next version of Javascript borrows a lot from Python; generators are basically from Python, array comprehensions are from Haskell IIRC but the syntax is the Python one, and the most main-stream language with de-structuring assignment is Python.)
Re:Sometimes I feel like a Luddite...
on
IronPython 1.0 is Born
·
· Score: 2, Informative
My advice would be to get over the stylistic issues, and force yourself to do something significant in Python. (Ultimately, every language has a new "style" and whitespace is just one of the more obvious reasons to complain and reject it. Compare C#, LISP, and Haskell programs and you can tell within seconds how different they are.) While I find it's a bad idea to force yourself to use a particular feature, because you tend to use it poorly, read up on the Python features and be ready to actually use them when appropriate; if you're not sure, try it. If you're just writing C# in Python, you're not getting much benefit.
The danger to this plan is that you might find it hard to go back.
If that's just too much, try Ruby. My understanding is that its aesthetics come from Perl, which will probably let you "do your thing", whatever that is.
Python's better than JScript and you can build full, real apps in it, too.
I'm not saying this to "advocate Python", as evidenced by my Ruby suggestion. You'll be a better developer for trying it; everybody should learn a new language every couple of years, to keep in practice. And you might understand the C# features coming down the pike like closures that much better for developing in another environment that has them.
Re:Sometimes I feel like a Luddite...
on
IronPython 1.0 is Born
·
· Score: 3, Informative
"Another" programming language? It's just another implementation of Python, which has been around for about as long as Perl.
Besides, if it gets to the point where Microsoft is officially supporting it, it would be a major addition to the.Net platform. If I could both develop in Python and in.Net I might actually be willing to develop in.Net. What stops me from wanting to develop in.Net or on the Java platform is the god-awful primary languages they are built around. Java makes me want to scream, and C# is only slightly better, all in all.
The problem with using that form of reasoning is that the result is statistical. Even if the system "can't cope" with a Hispanic male on crutches and misidentifies him as an Asian female, it's not the end of the world, because there was already a chance the system would make a mistake anyhow.
Pointing out that a statistical system will have outliers and exceptions is nearly tautological and information-free. The question is, is it accurate enough to be more accurate than the same security system (which in this case should be considered the whole system including personnel, other measures, etc.) without the new tool?
In fact even now, the system as a whole will make mistakes even without computer vision involvement, because despite popular opinion to the contrary, humans aren't perfect and make mistakes too. (I made the same point about the idea of using face recognition in airports to identify terrorists; even if we stipulate perfect memory on the part of humans, the humans would still have a lot of false positives. Why were so many people ready to assume that the computers would do any better? So far, it doesn't work that way; I like to say if the computers beat the humans in a AI-type test, that's basically proof the test wasn't fair. Today, there are only a handful of exceptions to that. Someday, that won't be a useful rule-of-thumb.)
It certainly is difficult to make a useful system, but the outliers are just part of the problem, and pointing out that outliers exist doesn't provide evidence either way.
I'm by no means a windows guru, but I do know if Task Manager says the task is "not responding", that means it is no longer responding to Windows messages. The easiest way for that to happen is for the program to be single-threaded, and in the middle of a lengthy computation, thus never getting back to the message pump, which is what you're getting.
You might be able to write a relatively simple program that just periodically sends a message to the window and looks for a response; if it doesn't get it in a certain time period, it assumes it to be unresponsive. I don't know what message is best to send (I don't know if there's a "ping" message, although presumably Task Manager is doing something like that so maybe there is), but I'm sure there's something you can use.
Unfortunately, that's about as far as I can take you, except to also suggest that you don't need to whip out Visual Studio for this; any number of more pleasent languages will be able to do this, too. Python with the Win32 extensions, for instance, can send Windows messages directly with a wrapped SendMessage call.
In order to pose the question, you have to generate it randomly. If it's not random, you already lost.
In order to generate it, you're going to end up using a grammar.
Running grammars in reverse is merely a matter of patience (to explore the space of problems the test program will pose) and the right tools; it's a fundamental bit of computer science.
Granted, expecting spammers to be conversant with the fundamental elements of computer science is a pretty high bar, but it only takes one to leap it and the rest to buy the program from him.
The image tests have the advantage that done properly, it takes more than just patience and computer science fundamentals to crack, it would require fundamental advances in the art.
(Note that nowhere in this message do I claim that image tests are perfect; in fact everything I know is vulnerable to the "feed it to a human in another context (viz, 'porn') and let them do the work" attack, and there are also points to be made about how widespread any given grammar/image test becomes; I know a website where the image test actually is a constant and so far it doesn't seem to be a problem because of scale issues. My point is that text tests have an additional disadvantage. It's not an intrinsically bad idea, though.)
Google wouldn't be interested in hiring people who could crack this, merely because they can crack this. Might make a decent interview question, though.
(You might also be tempted to think that you could just use a really complicated grammar, but you are constrained by two things, the human supposedly reading and taking the test, and the complexity of the human language itself. By the time you write some problem generator that could reliably throw off a parser, you'll be reliably confusing the hell out of your human users, too.)
It might be worth pointing out the poster you are arguing with used the past tense and the only concrete chronological reference was to 1978. Arguing that people aren't doing it today doesn't do much about his point that they were doing it then.
I would hope they aren't wasting that kind of money today. It's one thing to try it for a while, it's another to keep trying it long after it's proven to be bunk.
If you're on Windows, look into using the Windows Scripting Host, which you almost certainly already have installed. Windows Scripting Host can run Javascript directly as sort of a super-batch file.
You can start by simply directly executing the commands you generate, but you should learn the basic filesystem objects so you can manipulate files more safely and directly.
I'm assuming you're not on UNIX, because in that case you should either learn some shell or Perl. I prefer Perl because its escaping mechanisms are much saner than shell's, but shell has the advantage that it already works like the command line. (It depends on how much of this you do. If you do it every day, take the time to learn the basic Perl, because the ability to build libraries and ease of escaping will pay back the time. You have to learn about lists and iterations and control structures in shell or Perl either way, so the actual differential for simple Perl is smaller than you might think.)
There are other options, too; I'm just trying to keep the learning minimal for maximal bang. (Personally, if I want maximal shell power I go for IPython, but that's much more obscure, and rare.)
This is not the survival strategy of a generalist, it's the way of a specialist. We've got all our eggs in one basket. That basket has paid off in many unique and useful ways, which allow us to do things like survive in environments that are radically different from the ones we initially evolved in, but fundamentally we're still specialized.
One of the unique aspects of humanity makes it really hard to make that statement.
Instead of considering a single human, consider "the human gene pool", in the "selfish gene" sense. In that case, the genes are protected not just by our bodies, but our technologies; from evolution's point of view, there is no distinction between "body" and "tool". In this sense, we are the ultimate generalists. The very fact that we live in so many environments is strong evidence that we are indeed generalists in the only sense that matters. As fascinating as 20th+ century technology is, it really hasn't increased the number of environments we live in very much. (It has increased the number we can live in, but not too many people are in a hurry to live on the bottom of the ocean yet.)
We're the only species that has any potential of eventually extending the biosphere off of Earth. Should that occur, it'll be because of our brains, at which point you can make a pretty decent point that they are the most important evolutionary development ever (yup, beating out even "multicelluar organisms" or "aerobic respiration"), even if the primary beneficiaries by mass will almost certainly still be bacteria. But we're not there yet...
Let's say I write a program that incorporates some GPL code and I release it under the public domain. Have I violated the GPL?
Yes; you redistributed code under terms (or the lack thereof) that violates the GPL.
Or, lets say I release it under the GPL, but then I refuse to pursue any litigation over violation of the license of my code.
You can refuse to pursue litigation, but the original authors can still seek it for their portions.
I'm reasonably confident about these answers, but if you remain unsatisfied, it's probably because the law is pretty broken in this area and it has still gone unnoticed by the legal system in general. You might find the the theory I developed to replace it interesting, as it far more clearly delineates responsibilities. In this case, the essential difference is that copyright law has a very fuzzy understanding of how two works can be merged as it was created in a static era, whereas my theory sort of sidesteps the problems altogether. But of course, it's just the rantings of some Internet whackjob, not the law of the land.
If nothing else, it might put your lack of satisfaction on firmer ground. The law that the GPL is built on is very fuzzy, so it's not really the GPL's fault that you can find corner cases where the result isn't clear.
Then who gets the freedom? Good question! The software itself.
What an amazingly awful argument. Who gives a rat's ass whether software itself is free? Is it going to thank me for setting it free or something?
Are you actually the troll your user name implies? I'll have to keep an eye on your posts; I just can't manage this sort of lateral thinking. May actually be a new sub-species of troll.
It's also worth pointing out that no major operation ever proceeds without "mistakes". I scare-quote "mistakes" because a lot of mistakes are often pretty subjective, too; for instance, it's too early to say that "Bluray is a mistake" because given that the console hasn't come on to the market yet, it could yet be every bit the success Sony is hoping for. But no major operation proceeds without more-or-less objective mistakes being made, too.
Merely pointing out "mistakes exist" is basically saying nothing. Some attempt to quantify the extent of the mistakes needs to be made, and a demonstration of some "non-mistake" option needs to be made. For instance, many people insist on perfection in all dimensions, and will simultaneously claim that a screen being too dim is a "mistake" and a too-short battery life is a "mistake", even though the two are in diametric opposition and there is no physical way to avoid making at least one of those "mistakes". Note I am using this as an example, so that means we're assuming other constraints prevent the other solutions like "larger battery".
Sony's problems at the moment are merely suggestive; prognosticating problems is a fun and entertaining pasttime and I've done it myself. But calling the contest over is overstepping the evidence by quite a lot.
People ought to take more responsibility tossing around the "mistake" label. It's easy to call something a mistake, it's a lot harder to demonstrate a better option. (Especially one that could have been chosen with the available info at the time the decision had to be made. This constraint is optional, but I for one have a harder time getting upset at a "mistake" that couldn't have reasonably been avoided without 20/20 hindsight.)
Disclaimer: Yeah, I'm probably gonna buy a Wii and neither of the PS3 or the XBox 360 as well.
Both of your points are merely special cases of swapping out uncommonly-used pages to include more of the working set.
Merely naming such special cases off does not constitute any extra argument that you should keep a large amount of swap around. (I already said a small amount was potentially useful, but even on a multi-user system the only way you're going to get even 10 seconds of programming code swapped out is if the system is already basically dead due to swapping.)
150 comments as I write this and I haven't seen anybody say this yet.
Processors have gotten faster, memory has gotten somewhat faster, hard drives have gotten monstrously larger, but hard drives have only gotten marginally faster since ten years ago.
Instead of measuring swap in terms of absolute size, measure it in terms of time-to-fill, if you were writing flat-out, which you never are with swap.
Let's say you have 1GB of memory and you use your rule-of-thumb for 2.5GB of swap. Using an average hard drive transfer of 50GB/sec (and I think that's actually read, not write, but as you'll see it doesn't really matter), if you're going to use that swap, it would take you nearly a minute to use that space, writing flat out. Writing's often slower so multiply by an appropriate amount.
Odds are you're not actually going to use it that way, so whatever is using that swap is probably going to take a lot longer, orders of magnitude more.
Do you really need a minute's worth of swap? Is there anything that is so critical that you can't afford to run out of memory, but you're willing to wait hours upon hours while the swap is fully utilized?
Swap has two purposes: To swap out uncommonly-used pages so you can load more of the current working set, and to extend the memory space available to programs. 10 years ago, when we had mere seconds of swap, this made more sense. You could load windows, and swap half of it out, and boy did you ever need that RAM. If you were going to load a Word document that didn't quite fit, swap could save your bum, and if it got too loaded, it'd still run out of memory. You could afford to wait because you only had a few seconds of swap, and short of a really pathological swapping pattern you could expect your operation to terminate in a couple of minutes.
The second use in modern times is basically pointless; just let the program fail. You almost certainly do not want to let the program spend the next hour swapping. The first use might still be valid, but you might as well only use a couple of seconds of swap; call it 100MB. Beyond that, nothing is really useful. And in Windows, excessive swapping also tends to basically lock up the machine which is something to be avoided.
Huge swap partitions, unless you have another use for them (some implementations of Linux suspend are the only ones I know) are basically a holdover from the past, religiously clung to by people who have been 'doing it this way' for over a decade. Skip the swap unless you know why you shouldn't.
Suppose instead of hard-coding the values of all the various skills, you tracked how often they were used, and dynamically decreased the value of overused skills, and increased the value of underused skills.
Overpowered skills would self-nerf, underpowered skills would self-enhance. You would still want to add a bit more structure, but the basic structure would be there.
I've actually wondered why they don't do something like this already; why tune, tune, tune manually, where you can't possibly keep up, when you can let the computer do it and just override as needed/desired?
Star Trek contains many overarching myths that are in the background and understood by all those who watch the show.
Yeah, I realized as soon as I hit "submit" that that was a bit strong.
What I meant was that there was no overarching "story" that was this one gigantic myth. Star Trek, being written by a lot of people with a lot of beliefs over a lot of time, certain does have recurring themes, but for any given overarching theme you can find an episode that seems to contradict it.
It had strong tendencies but is actually fairly incoherent if you really watch what the shows are saying. (While I'm normally really critical of Star Trek, I don't mean that as a critism; reality is incoherent too.)
There was nearly no over-arching Myth, but many of the episodes had mythic elements, some altogether too literally. (Remember when our intrepid crew encountered the actual, factual Greek God Apollo?)
But you miss the main point, which is thanks to the magic of Deconstruction, you can read anything you want into anything you want. So of course Star Trek has embedded myth, any embedded myth you want. It also contains deep wisdom about how post-feminist transgendered dialogs can be resolved in a quasi-imperialist milieu steeped in the rhetoric of oppressive patriarchial systemic dynamics in a quantum mechanical universe, if you look hard enough.
Slashdot Mirror
The problem is that politically, every game is presumed to be virtually thrown at children of all ages. This doesn't seem to come up with any other medium; everybody knows AO magazines, PC games, videos, etc. are kept from children, and even M video games are getting better protected all the time. But for some reason, politicians still get to get away with the implicit idea that any given nasty game could well be a pack-in with the console. (Note that it's so implicit that Slashdotters as a whole don't even notice the premise.)
If it weren't for that, the "blame video games" crowd wouldn't have a case at all.
So, no AO games on consoles anytime soon. It's still too easy for one AO game to become representative of console games as a whole.
(Note that ultimately, this failure of logic isn't so much prudery or excessively zealous "protect the children" problems, because if that was the problem these same people would be screaming about internet porn and other such things. It all comes down to this idea that any 11 child can wander into Gamestop and the salespeople will thrust Debbie Does Dallas: PS3 Edition into their hands at the earliest available opportunity.)
In the absense of further knowledge, I'm somewhat skeptical about the hard drives being sensitive enough, but I mean that in the original meaning of "skeptical", as in, updated pending further evidence, not forever committed to not believing in it. Clearly, this guy thinks they are sensitive enough.
But if that hurdle can be cleared, processed correctly the data will be very useful. Most objections Slashdotters are going to raise will be irrelevant. Local aberrations will be cancelled out at the supernode, because the aberrations will only appear at that one node. Simple interference at constant frequencies is also easy to detect and mask out with "Introduction to Signal Processing"-level signal processing.
Merging the data together is a bit more challenging but should be doable.
The only thing I don't see is talking about knowing where the machines are in the real world, which would be very helpful, and that may be coming later. The other thing is that the system probably won't work very well with a simple "IsEarthquake" signal coming out of the clients; the supernodes really ought to examine all the data from its clients and then decide if there's an earthquake. Otherwise, several correctly-timed local abberations could all look like "earthquakes", even with completely different characteristics, if all that is going to the supernode is "IsEarthquake". Of course, the real system may already have both of these things covered and the article merely oversimplified.
Upshot is, signal processing can do some very surprising things with data that seems to consist almost entirely of noise, if you have enough data coming in.
Perl can assign lists to lists, so you might call it first-order destructuring, but it can't (to the best of my knowledge) do it arbitrarily deeply like Python, Erlang, and other fully-destructuring languages.
True. I was assuming we were talking about Mozilla, which AFAIK has one bug tracker for all. check check check... yup, Mozilla and Firefox are both on bugs.mozilla.org. (Can't link though because slashdot links are banned.)
If the GP is correct, it's still bad usage of the bug system. If Team A feels the fault belongs to Team B, the correct response is to move the bug to Team B, not to close the bug.
They may get into a fight about whose responsibility it is, but such a fight is also a bug, as such responsibilities in such a large project basically are a part of the code and should also be clearly delimited. If you insist on using languages without automatic garbage management, "who's responisibility it is to deallocate this memory" is a fundamental part of the API.
I can't provide full scientific proof, because there is no scientific proof in this domain, which I regret.
:) It is proper to be skeptical about productivity gains in a world where we have no concrete measure of productivity, but since I don't have concrete standards, all I can tell you is that my own experince matches the Blub Paradox to a T; whenever I do have to code in Java or C++ or anything else like that, I will see simple solutions to my problem in Python that require the equivalent of tens or hundreds of lines of code in those languages. (Heck, even in Perl I've wished for generators on more than one occasion, and unrolling a generator is no fun.)
The best actual "proof" is the following: There was a study a while ago that established productivity for a given programmer appeared to be constant across lines of code, regardless of the language. This study was, IIRC, done a while ago, against C, assembly, and a couple of other suspects, but it was a pretty good spread. Programmers can turn out a couple hundred lines of non-trivial code a day. The idea is that since this is true, you want the language where you need the fewest lines of code, all else being equal, to accomplish your task.
The details of this have been debated endlessly. My personal call is that it is "mostly true", with some important caveats (programmers not gaming the LOC count, and the real important metric is "lines of code the programmer has to think about"; frameworks can churn out thousands of lines of templates (MFC was horrible about this) and they don't count), but experience does bear this general idea out.
The general LOC multiplier for Python vs. Java on the small scale is usually thought to be 5-10x. It's hard to know exactly how accurate this is because Java makes doing small things enormously complicated; "Hello World" is at least three lines of real code (class definition, static main method declaration, and the print call which itself involves a method chain of the form X.Y.Z("Hello World"), not just a simple statement). However, it is also a reasonable to believe that Java continues to make things hard as you scale up, and there are some simply Python patterns that are effectively impossible in Java or require jumping through very complicated hoops. I also believe there are a few cases of Java programs ported to Python that bear this out, or possibly even more. (Sometimes you can end up with some multiplicative gains, where the 5-10x improvements actually start layering on top of each other; in real terms this usually translates to the ability to create a superior design in Python than what you can do in Java. There's a reason Java's got all of these code generation tools and bytecode hacking tools, whereas Python mostly doesn't.)
The productivity multiplier does seem to be similar.
I cut down my estimate for C# because while I'll cop to never using C#, it does seem to me to be somewhat better. As I alluded to, adding in closures in 2.0 will also be a significant step forward. (Closures are a feature I recommend learning about, as for a long time I saw programmers talking about them and I had no clue what they meant, but once I got over the learning curve I understood why they were so important. Some of the worst problems with the worst workarounds in Java come from the lack of closures or any equivalent functionality, require fully separate large complicated classes with new interfaces to achieve the same functionality, all with no gain in safety or functionality. This is one of the places you tend to get the layered benefits I alluded to...) So I don't know if the gain is as large.
On the other hand, C# does seem to make heavy weather of certain very easy constructs in Python.
So that's the general evidence. If you want to learn more and get a lot of opinions, you can search "Python productivity" on the web.
But I know in your shoes I'd be downloading IronPython and putting it through its paces.
Somewhere in the great online book Reflections on Relativity, there is a discussion of "kugelblitz"s, which is a theoretical black hole that consists entirely of energy, which could be just a lot of photons. The term isn't in much use in science (though I did find at least one arxiv.org reference) because it's not very useful; in practice, a photonic kugelblitz is impossible, and once such a black hole forms, it would be indistinguishable from any other black hole. But it is theoretically possible, because all mass-energy contributes to the gravitational field.
I think IronPython compiles down to CLR bytecode, so if you're shipping managed C#, you could just as well ship IronPython and nobody would notice, which is the entire point of this article in the first place.
However, whether or not you could benefit from learning Python is a decision only you can make. Python may increase your productivity 2-3x over C# or more (and that's fairly conservative, usually), but only after you learn it, which could be months.
However, if you end up always choosing the short-term expedient answer of sticking with the language you know (and the environment you know), you lose out on any productivity gain you might get from another environment or language; this is a general point, not one specific to this case.
In general, the "common environments" (Java,
Again, I'm not trying to push you, just point out that for the costs there are benefits, too. I say what I'm saying because I believe (and see) too many developers trapping themselves in local maxima by always making the short-term decision. Ultimately, it's no skin off my nose.
You can, but the lack of namespacing starts to get troublesome as you start trying to build libraries, or use the libraries of others. Later versions of Javascript, which JScript will presumably track, will help with this a lot. Although based on what I see, it's nearly learning a new language anyhow. (In fact, the next version of Javascript borrows a lot from Python; generators are basically from Python, array comprehensions are from Haskell IIRC but the syntax is the Python one, and the most main-stream language with de-structuring assignment is Python.)
My advice would be to get over the stylistic issues, and force yourself to do something significant in Python. (Ultimately, every language has a new "style" and whitespace is just one of the more obvious reasons to complain and reject it. Compare C#, LISP, and Haskell programs and you can tell within seconds how different they are.) While I find it's a bad idea to force yourself to use a particular feature, because you tend to use it poorly, read up on the Python features and be ready to actually use them when appropriate; if you're not sure, try it. If you're just writing C# in Python, you're not getting much benefit.
The danger to this plan is that you might find it hard to go back.
If that's just too much, try Ruby. My understanding is that its aesthetics come from Perl, which will probably let you "do your thing", whatever that is.
Python's better than JScript and you can build full, real apps in it, too.
I'm not saying this to "advocate Python", as evidenced by my Ruby suggestion. You'll be a better developer for trying it; everybody should learn a new language every couple of years, to keep in practice. And you might understand the C# features coming down the pike like closures that much better for developing in another environment that has them.
"Another" programming language? It's just another implementation of Python, which has been around for about as long as Perl.
.Net platform. If I could both develop in Python and in .Net I might actually be willing to develop in .Net. What stops me from wanting to develop in .Net or on the Java platform is the god-awful primary languages they are built around. Java makes me want to scream, and C# is only slightly better, all in all.
Besides, if it gets to the point where Microsoft is officially supporting it, it would be a major addition to the
The problem with using that form of reasoning is that the result is statistical. Even if the system "can't cope" with a Hispanic male on crutches and misidentifies him as an Asian female, it's not the end of the world, because there was already a chance the system would make a mistake anyhow.
Pointing out that a statistical system will have outliers and exceptions is nearly tautological and information-free. The question is, is it accurate enough to be more accurate than the same security system (which in this case should be considered the whole system including personnel, other measures, etc.) without the new tool?
In fact even now, the system as a whole will make mistakes even without computer vision involvement, because despite popular opinion to the contrary, humans aren't perfect and make mistakes too. (I made the same point about the idea of using face recognition in airports to identify terrorists; even if we stipulate perfect memory on the part of humans, the humans would still have a lot of false positives. Why were so many people ready to assume that the computers would do any better? So far, it doesn't work that way; I like to say if the computers beat the humans in a AI-type test, that's basically proof the test wasn't fair. Today, there are only a handful of exceptions to that. Someday, that won't be a useful rule-of-thumb.)
It certainly is difficult to make a useful system, but the outliers are just part of the problem, and pointing out that outliers exist doesn't provide evidence either way.
I'm by no means a windows guru, but I do know if Task Manager says the task is "not responding", that means it is no longer responding to Windows messages. The easiest way for that to happen is for the program to be single-threaded, and in the middle of a lengthy computation, thus never getting back to the message pump, which is what you're getting.
You might be able to write a relatively simple program that just periodically sends a message to the window and looks for a response; if it doesn't get it in a certain time period, it assumes it to be unresponsive. I don't know what message is best to send (I don't know if there's a "ping" message, although presumably Task Manager is doing something like that so maybe there is), but I'm sure there's something you can use.
Unfortunately, that's about as far as I can take you, except to also suggest that you don't need to whip out Visual Studio for this; any number of more pleasent languages will be able to do this, too. Python with the Win32 extensions, for instance, can send Windows messages directly with a wrapped SendMessage call.
In order to pose the question, you have to generate it randomly. If it's not random, you already lost.
In order to generate it, you're going to end up using a grammar.
Running grammars in reverse is merely a matter of patience (to explore the space of problems the test program will pose) and the right tools; it's a fundamental bit of computer science.
Granted, expecting spammers to be conversant with the fundamental elements of computer science is a pretty high bar, but it only takes one to leap it and the rest to buy the program from him.
The image tests have the advantage that done properly, it takes more than just patience and computer science fundamentals to crack, it would require fundamental advances in the art.
(Note that nowhere in this message do I claim that image tests are perfect; in fact everything I know is vulnerable to the "feed it to a human in another context (viz, 'porn') and let them do the work" attack, and there are also points to be made about how widespread any given grammar/image test becomes; I know a website where the image test actually is a constant and so far it doesn't seem to be a problem because of scale issues. My point is that text tests have an additional disadvantage. It's not an intrinsically bad idea, though.)
Google wouldn't be interested in hiring people who could crack this, merely because they can crack this. Might make a decent interview question, though.
(You might also be tempted to think that you could just use a really complicated grammar, but you are constrained by two things, the human supposedly reading and taking the test, and the complexity of the human language itself. By the time you write some problem generator that could reliably throw off a parser, you'll be reliably confusing the hell out of your human users, too.)
It might be worth pointing out the poster you are arguing with used the past tense and the only concrete chronological reference was to 1978. Arguing that people aren't doing it today doesn't do much about his point that they were doing it then.
I would hope they aren't wasting that kind of money today. It's one thing to try it for a while, it's another to keep trying it long after it's proven to be bunk.
If you're on Windows, look into using the Windows Scripting Host, which you almost certainly already have installed. Windows Scripting Host can run Javascript directly as sort of a super-batch file.
You can start by simply directly executing the commands you generate, but you should learn the basic filesystem objects so you can manipulate files more safely and directly.
I'm assuming you're not on UNIX, because in that case you should either learn some shell or Perl. I prefer Perl because its escaping mechanisms are much saner than shell's, but shell has the advantage that it already works like the command line. (It depends on how much of this you do. If you do it every day, take the time to learn the basic Perl, because the ability to build libraries and ease of escaping will pay back the time. You have to learn about lists and iterations and control structures in shell or Perl either way, so the actual differential for simple Perl is smaller than you might think.)
There are other options, too; I'm just trying to keep the learning minimal for maximal bang. (Personally, if I want maximal shell power I go for IPython, but that's much more obscure, and rare.)
Instead of considering a single human, consider "the human gene pool", in the "selfish gene" sense. In that case, the genes are protected not just by our bodies, but our technologies; from evolution's point of view, there is no distinction between "body" and "tool". In this sense, we are the ultimate generalists. The very fact that we live in so many environments is strong evidence that we are indeed generalists in the only sense that matters. As fascinating as 20th+ century technology is, it really hasn't increased the number of environments we live in very much. (It has increased the number we can live in, but not too many people are in a hurry to live on the bottom of the ocean yet.)
We're the only species that has any potential of eventually extending the biosphere off of Earth. Should that occur, it'll be because of our brains, at which point you can make a pretty decent point that they are the most important evolutionary development ever (yup, beating out even "multicelluar organisms" or "aerobic respiration"), even if the primary beneficiaries by mass will almost certainly still be bacteria. But we're not there yet...
You can refuse to pursue litigation, but the original authors can still seek it for their portions.
I'm reasonably confident about these answers, but if you remain unsatisfied, it's probably because the law is pretty broken in this area and it has still gone unnoticed by the legal system in general. You might find the the theory I developed to replace it interesting, as it far more clearly delineates responsibilities. In this case, the essential difference is that copyright law has a very fuzzy understanding of how two works can be merged as it was created in a static era, whereas my theory sort of sidesteps the problems altogether. But of course, it's just the rantings of some Internet whackjob, not the law of the land.
If nothing else, it might put your lack of satisfaction on firmer ground. The law that the GPL is built on is very fuzzy, so it's not really the GPL's fault that you can find corner cases where the result isn't clear.
Then who gets the freedom? Good question! The software itself.
What an amazingly awful argument. Who gives a rat's ass whether software itself is free? Is it going to thank me for setting it free or something?
Are you actually the troll your user name implies? I'll have to keep an eye on your posts; I just can't manage this sort of lateral thinking. May actually be a new sub-species of troll.
how they've made huge mistakes with the console.
It's also worth pointing out that no major operation ever proceeds without "mistakes". I scare-quote "mistakes" because a lot of mistakes are often pretty subjective, too; for instance, it's too early to say that "Bluray is a mistake" because given that the console hasn't come on to the market yet, it could yet be every bit the success Sony is hoping for. But no major operation proceeds without more-or-less objective mistakes being made, too.
Merely pointing out "mistakes exist" is basically saying nothing. Some attempt to quantify the extent of the mistakes needs to be made, and a demonstration of some "non-mistake" option needs to be made. For instance, many people insist on perfection in all dimensions, and will simultaneously claim that a screen being too dim is a "mistake" and a too-short battery life is a "mistake", even though the two are in diametric opposition and there is no physical way to avoid making at least one of those "mistakes". Note I am using this as an example, so that means we're assuming other constraints prevent the other solutions like "larger battery".
Sony's problems at the moment are merely suggestive; prognosticating problems is a fun and entertaining pasttime and I've done it myself. But calling the contest over is overstepping the evidence by quite a lot.
People ought to take more responsibility tossing around the "mistake" label. It's easy to call something a mistake, it's a lot harder to demonstrate a better option. (Especially one that could have been chosen with the available info at the time the decision had to be made. This constraint is optional, but I for one have a harder time getting upset at a "mistake" that couldn't have reasonably been avoided without 20/20 hindsight.)
Disclaimer: Yeah, I'm probably gonna buy a Wii and neither of the PS3 or the XBox 360 as well.
Both of your points are merely special cases of swapping out uncommonly-used pages to include more of the working set.
Merely naming such special cases off does not constitute any extra argument that you should keep a large amount of swap around. (I already said a small amount was potentially useful, but even on a multi-user system the only way you're going to get even 10 seconds of programming code swapped out is if the system is already basically dead due to swapping.)
150 comments as I write this and I haven't seen anybody say this yet.
Processors have gotten faster, memory has gotten somewhat faster, hard drives have gotten monstrously larger, but hard drives have only gotten marginally faster since ten years ago.
Instead of measuring swap in terms of absolute size, measure it in terms of time-to-fill, if you were writing flat-out, which you never are with swap.
Let's say you have 1GB of memory and you use your rule-of-thumb for 2.5GB of swap. Using an average hard drive transfer of 50GB/sec (and I think that's actually read, not write, but as you'll see it doesn't really matter), if you're going to use that swap, it would take you nearly a minute to use that space, writing flat out. Writing's often slower so multiply by an appropriate amount.
Odds are you're not actually going to use it that way, so whatever is using that swap is probably going to take a lot longer, orders of magnitude more.
Do you really need a minute's worth of swap? Is there anything that is so critical that you can't afford to run out of memory, but you're willing to wait hours upon hours while the swap is fully utilized?
Swap has two purposes: To swap out uncommonly-used pages so you can load more of the current working set, and to extend the memory space available to programs. 10 years ago, when we had mere seconds of swap, this made more sense. You could load windows, and swap half of it out, and boy did you ever need that RAM. If you were going to load a Word document that didn't quite fit, swap could save your bum, and if it got too loaded, it'd still run out of memory. You could afford to wait because you only had a few seconds of swap, and short of a really pathological swapping pattern you could expect your operation to terminate in a couple of minutes.
The second use in modern times is basically pointless; just let the program fail. You almost certainly do not want to let the program spend the next hour swapping. The first use might still be valid, but you might as well only use a couple of seconds of swap; call it 100MB. Beyond that, nothing is really useful. And in Windows, excessive swapping also tends to basically lock up the machine which is something to be avoided.
Huge swap partitions, unless you have another use for them (some implementations of Linux suspend are the only ones I know) are basically a holdover from the past, religiously clung to by people who have been 'doing it this way' for over a decade. Skip the swap unless you know why you shouldn't.
I wonder if that's totally true.
Suppose instead of hard-coding the values of all the various skills, you tracked how often they were used, and dynamically decreased the value of overused skills, and increased the value of underused skills.
Overpowered skills would self-nerf, underpowered skills would self-enhance. You would still want to add a bit more structure, but the basic structure would be there.
I've actually wondered why they don't do something like this already; why tune, tune, tune manually, where you can't possibly keep up, when you can let the computer do it and just override as needed/desired?
Because the evidence suggests that they are incapable of a good new series.
Star Trek contains many overarching myths that are in the background and understood by all those who watch the show.
Yeah, I realized as soon as I hit "submit" that that was a bit strong.
What I meant was that there was no overarching "story" that was this one gigantic myth. Star Trek, being written by a lot of people with a lot of beliefs over a lot of time, certain does have recurring themes, but for any given overarching theme you can find an episode that seems to contradict it.
It had strong tendencies but is actually fairly incoherent if you really watch what the shows are saying. (While I'm normally really critical of Star Trek, I don't mean that as a critism; reality is incoherent too.)
There was nearly no over-arching Myth, but many of the episodes had mythic elements, some altogether too literally. (Remember when our intrepid crew encountered the actual, factual Greek God Apollo?)
But you miss the main point, which is thanks to the magic of Deconstruction, you can read anything you want into anything you want. So of course Star Trek has embedded myth, any embedded myth you want. It also contains deep wisdom about how post-feminist transgendered dialogs can be resolved in a quasi-imperialist milieu steeped in the rhetoric of oppressive patriarchial systemic dynamics in a quantum mechanical universe, if you look hard enough.
Isn't literary criticism fun?