P2P is a technological success in reducing the load on any one point on the network.
Reducing relative to what? Heck, USENET is a more efficient distribution mechanism than P2P.
I think he meant that P2P reduces the load on the original distributor of the information, which is definitely true as compared to hosting something on a website. It's good for the distributor, bad for everyone else (though faster with a decent swarm). Your counter about Usenet is true as well, Usenet is actually pretty efficient overall since all the data is effectively cached at each ISP (I think - not too certain of the technical details). However, this only works as long as the overall volume of Usenet traffic is low enough for it to be stored nearby, so it's definitely not scalable in the way most P2P solutions are.
Someone else posted somewhere here that it doesn't matter if the file is marked or not, and that if you download the file from IE or Firefox it is STILL picked up and loaded from the desktop by IE. Sounds like part of the problem is that dll's aren't being checked for safety before loading; whether this is a general "feature" in Windows or something IE specific, I have absolutely no idea, I haven't used Windows in a while so I can't check myself...
Safari should NOT be auto-dumping files onto the Windows desktop. PERIOD.
Totally agreed. I'd go further - no website should be able to trigger any action on my computer that persists after I close the damn browser window without my explicit permission, apart from saving cookies and leaving an entry in my history log (even then, only if I've enabled both of these things).
That said, IE is worse here - downloading files without my permission is bad form, but a pre-installed system app loading DLLs from any old place that it finds them, especially one of the most common places to dump downloaded files, is just idiotic.
While this is a reasonable guess, it's about the same as guessing heavier objects fall faster. Consider electron-hole pairs in a silicon lattice. They act very much like electron-positron pairs. However, electrons fall down, and holes fall up. To me, it would seem odd if anti-matter fell down.
To a physicist, though, it would not square well with everything we know if anti-matter fell up. In particular it would violate the equivalence principle of general relativity, and would be at odds with the general idea that energy density (roughly speaking) causes gravitational attraction, since anti-matter most definitely has positive energy density.
You can't change the size of an array once it's allocated (which simplifies memory management, rather than the JIT), but you can change its contents. I.e., it's certainly not the same kind of immutable as that of, say, String. Furthermore, there's no language that can do much better than that without either a) allocating more space than necessary up-front so that the array can then be expanded to fill it if needed (reallocating if you grow to fill the original array), or b) using linked lists to store the array, which is generally a performance killer thanks to increased cache misses. And you can do both of those things in Java, either by hand or with an ArrayList or LinkedList, which is what people usually do.
And then there's the whole 'Evolution disclaimer' issue that's been kicking around. The scientific response to a disclaimer about how evolution isn't 100% proven true and there are alternate theories has been somewhat absurd. I've never understood it, if someone put such a disclaimer in about Einstein's relativity I'd applaud them, or Newton's gravity, but for some reason Darwin's work is off limits for disclaimers (disclaimer -> I have seen a disclaimer about Newtonian gravity before, basically saying that, while it's useful, it's also believed to be false and that there are newer, better methods of understanding gravity).
No scientific work should need such a disclaimer - it's implicit in the study of science that all "facts" are really open for debate if better or contradictory evidence comes in to play. You're right, Newton's theory of gravity has been thoroughly supplanted by Einstein's, so it makes sense to mention the fact that Newton's theory is just an approximation; currently there is no evidence that there is any theory that overtakes evolution in such a way, so it does not make sense to put a disclaimer. The implication that the nutjobs want to foster by putting such a disclaimer on evolution is that it is somehow less valid than the rest of science, which is a freaking lie.
BTW, this movie is ridiculous - the theory of evolution caused the Holocaust? Wow...at one point I was under the impression Ben Stein was intelligent, but he's really proved me wrong on that by signing on with this drivel-fest.
For instance, SDS (Proshares Ultrashort S&P 500) gained 2.49% this past month versus a 1.69% loss in the S&P 500; SDS should "correspond to twice the inverse daily performance of the S&P 500" (finance.google.com).
Watch out, though - "twice the inverse daily performance" does not translate to "twice the inverse monthly performance" due to the magic of compounding.
For example, suppose the S&P gained 10% one day, and lost 10% the next. That would make for a two-day loss of 1%. But the SDS would have lost 20% the first day and gained 20% the second day, making for a two day loss of 4%! So even though the S&P has gone down over two days, the inverse tracking ETF has also gone down! Interestingly enough, in that situation both the leveraged inverse and the leveraged normal ETFs would end up at the same price.
Lesson: know exactly what you're doing when you buy an ultra, because the risk profile is totally different from an unleveraged ETF. Don't expect it to match over more than a day or two.
That's a radical interpretation of the text - like most results in computability theory, Rice's theorem says nothing of much use to anyone that's considering what kinds of real tasks you can possibly perform with a computer. Most of these theorems merely use some spinoff of Cantor's diagonalization argument to show that - surprise! - you can't write a program to do something that's completely and utterly ridiculous to expect a program to do. These theorems are true, but the fun comes when you give a layman's explanation of the unreasonable task at hand and it "seems like" something a human could do. But most of the tasks turn out to be equivalent to solving any and every problem you can imagine, and once you realize that you discover that these impossibility theorems have nothing at all to say about AI, they are really about forcing us to better specify our problem domains. If I can't solve the Riemann hypothesis, then it's certainly not a disproof of AI to realize that a computer can't solve a problem that contains the Riemann hypothesis as a sub-problem!
Not that I'm saying we will get computers to program as well as we do, by any means. That's a whole other can of worms, and to me is more an issue of extremely difficult engineering (possibly too difficult for our feeble minds) than anything else. I'm just saying that abstract arguments are never going to rule out the possibility, and generally they don't even help us see what paths we should or shouldn't pursue.
Theory: the "I know you guys are just going to mod me down for this, but..." line is a guaranteed way to pick up a +5 moderation, no matter what the content of the post is.
I know you guys are just going to mod me down for this, but seriously, I think there's a pattern here.
You're right, of course, on both counts - don't know how I miscounted that, guess I hadn't quite woken up yet! I also didn't notice the parenthesis, which would have negated the whole point of my comment! That's what I get for Slashdotting before my coffee...
Your points are well taken. The "you can't make everyone a criminal" argument doesn't hold legal weight. However, especially in situations where nobody is directly harmed or directly deprived of property, you would think that perhaps there should be a consitutional prohibition on criminalizing a large percentage of the citizenry...frankly, if even 10% of the population is made criminal by a law, that should shed some very serious doubt on the fairness of that law, as it reeks of mob rule.
Unfortunately Americans seem comfortable with letting the majority shit on the minority every chance it gets, thus embracing the worst thing about democracy (two wolfs and a sheep voting on what's for dinner, etc - where's the farmer with the shotgun when you need him?), so I doubt if this will change any time soon.
"Any copyrighted content?" ? ("95%+ directly copied from copyrighted work?" ? "DMCA" : "Minimum wage operator, is this parody, educational or other fair use?") : "Go on"
Ah, the fabled sexternary operator, nice to meet you! I can just smell all the minimalist legacy C programmers wetting themselves right now, getting excited over how unintelligible they could have made their code had they had access to such a beast in The One True Programming Language (TM) before they had to be tainted by this whole "class thing" that the kids are so excited about.
Modern ID/creationism does not make predictions, because a prediction arises from the limitations of a theory.
Excellently put, this is really the basis of the scientific method, and most people don't understand it. The power of a theory is that it is weak - every event that a theory can explain with tweaking of its variables that doesn't actually happen for some real world situation is a mark against the theory. Not as strong a mark against the theory as an event that has happened that cannot fit with the theory, mind you (a theory is allowed, however, to be agnostic on many or most events, like most theories are), but it is a mark against. Thus the rule of thumb is, first, look for proof that a theory is wrong; second, look for the simplest of the not-wrong theories, where you define simple as above.
Science can't explain a lot of things. People often bring this up to explain why religion and the humanities are "better." But I see the exact opposite situation. Einstein's equation does not contain in it the ability to explain why the earth is repelled by the Sun. By no stretch of the imagination could it explain this fact, as it is directly at odds with the rest of the theory - if the Earth WAS repelled by the Sun, we would have to discard Einstein's equation as a basic for gravitational physics. But religion could quite easily accommodate that. It could also explain why God loves it when you eat baby brains, why the sky is green, and why eight plus seven is equal to zero. All of which means the God theory is capable of explaining way too much.
More practically, this issue comes up in neural network training. Having a network with too many nodes leads to overfitting the data; you can't pick out any real patterns because you are able to "explain" any sort of data that comes in. Same thing with polynomial fits - with a high degree polynomial, I can fit any curve, which usually just means I'm fitting the noise rather than the underlying pattern. "God" is the original infinite-order polynomial, a function you might as well just define by listing all the points in it rather than finding any sort of order. In fact, "God" is the weakest theory of them all, because it has no content.
That said, a particular religion has a theory of God with significantly fewer free variables than the generic notion, so it comes closer to a real theory. However, the range of incorrect observations that could be accounted for is still many orders of magnitude higher than any scientifically acceptable theory, so take that as you will...
All you can do ever with ID theory is try to falsify evolution theory, and then propose ID as the alternative. You can never go further than that. It can never be "science", because you can't repeatably and reliably test a being that exists and acts outside the system of the universe. ID theory is only philosophy. I'm not saying ID is right or wrong. I actually believe in an old Earth ID theory, but that's part of my religious belief. What I'm just saying is that if you have a philosophical theory, then it should be taught in a philosophy class, along with string theory.
Actually, I disagree with this (well, not the part about string theory - you're absolutely right, it's probably pure fantasy, even if there are some interesting ideas, and its zealots are deluding themselves if they can't see why their faith in the theory is too strong). But the whole threat of ID is that it is being presented as "science." Or rather, it's being presented in order to subtly shift the definition of science so that in Science 2.0, inconvenient facts for religion can be democracied away at will.
Of course, ID's greatest strength (that it claims not to be an explicitly religious theory, and thus can be taught in schools) is also its greatest weakness. Why? Simple.
1) Something created us. 2) If it was God, stop - theory is religious, can't be taught in schools. 3) Otherwise, aliens did it. 4) If it was aliens, then who created the aliens? 5) Return to 2), repeat until either a) the theory is religious and God did it, or b) evolution did it. 6)... 7) Profit
ID can never possibly make it all the way to profit, any way it turns out, so...
However, I disagree with the notion that if ID was correct you would still have your hands tied as far as investigating the designer. DNA is essentially code, and you can learn a lot about a programmer by reading their code, even if it is compiled. The problem becomes one of forensics rather than philosophy, but unless the designer was actively attempting to hide the design, I highly doubt that it would be very difficult to learn something about them...at least if you presume finite resources in design and deployment, I'm sure you could quite effectively propose, debunk, and revise theories about the designer. That would be science; current ID is not, as you correctly note.
Though I suspect that it was more of an excuse for a joke than a genuine misunderstanding.
Indeed - couldn't resist the setup, sorry about that!
This whole group as unit vs. group as collection thing is quite the irritating topic for me, all jokes aside. I tutor for the SATs, and it tests this stuff quite often (if it's been a while since you've taken it, they've added a grammar section now to bias the test further towards the humanities). Students always get upset when I tell them that, in fact, ETS does consider the phrase "The British Virgin Islands are in the Carribean" to be grammatically incorrect (if you doubt the mistake here, check the first sentence of the Wikipedia page, though you'll notice that when referring to the islands as a collection, the plural is used; same issues come up with "the United States," where you are only supposed to use the plural when actually talking about the collection of states, not the country). I suppose there's a bit of logic in it, but really...these are such piddling points to be testing high school students on, yet the SAT is chock full of this crap.
Frankly, I don't care how anyone says anything as long as the meaning is clear, and the singular/plural distinction so rarely causes actual confusion in this regard. To each his (or their, if you prefer) own...
value types - now java can often automatically put objects on the stack and this makes the complexity cost of value types hardly worth the benefits.
And this is definitely a good thing. However, it is being touted as if it's the solution to the entire heavyweight object problem. It is not - plain and simple, objects are too bloated to use if you need to shuffle around and process large amounts of data. If I want to store a list of half a million vectors and do some geometry with them, in Java the only real solution is to break the vectors apart and store them as floats, because there is just too much data manipulated if you use objects, which takes both a time and a storage toll. It also forces all your helper routines to take plain old float arrays - you might as well be writing C code, for all the type safety that gives you. You end up forced to give up all the great things about OO programming, all because you're forced to make do with the pathetic set of lightweight value types that Java provides. [No complex type? Come on, guys...] And then we're told that to add a feature like value types would hurt the OO-nature of the language? I suppose making an int a full-fledged object would be reasonable, then, right?
I'm not saying that this is a huge problem - I still use Java anyways, as despite its little glitches I find it to be overall less painful than C or C++, and I really do think that it is improving (and if it ceases, I'll just jump ship to Python). But it's kind of annoying that for years we have been told that this type of thing is not a problem at all, and that furthermore, that the only workaround is to put supreme faith in the JVM to bless us with everything we need. I'd kind of prefer if Sun just came out and said, "We don't give a glistening poo nugget about people trying to do hardcore computation in Java. Deal with it!" rather than pretending that the solution is already in our hands. Because it's not!
Yes, the JIT compiler is written in C, but you are wrong that a better optimizing C compiler could beat a really good JIT. The whole point of JIT is that it can use current information about how a program is running and do things like arrange objects in memory to increase the cache hit rate. The best C compiler in the world just doesn't have the amount of information available that it would need to do things like this.
That's not to say this all currently works in practice, though. Sun has been telling everyone for the past five years that the JVMs are so robust and intelligent that you don't need lightweight objects to do fast computation (for things like vector math), that you can just use plain old Java objects and the JVM will figure out how to optimize these, and anybody that's ever actually programmed some physics or graphics in Java knows that those claims are still crap. (Though I'm told this version of Java is much better about this stuff, to be fair)
However, failures in implementation aside, there are very good arguments that suggest that as we go forward, JIT compilers will eventually overtake statically compiled code when it comes to speed. IMO the current Java 6 JVM is a pretty good first step towards this ideal JIT compiler; maybe I'd qualify it as a very early alpha version of The Real Thing. Certainly much more of an improvement than the past few versions. It's unfortunate, however, that Sun continues to pretend that they've already got it all figured out and running smoothly, when there is obviously so much more work to do. It's also quite irksome that they ignore most performance-related RFEs, simply promising that the magical JIT will fix everything in the next version...
Indeed - Sun made a lot of big mistakes early on that have severely hampered Java's acceptance since then:
1) The first VMs were truly awful and slow
2) Terrible browser integration with applets
3) AWT as a whole was just a mess, and Swing didn't do much to help things.
4) Brought the language out as a trimmed down C++, only to realize that some of the stuff in C++ was actually useful and put it back in later (it happened with generics and static imports, and if reason takes hold it will eventually happen with operator overloading)
1) is pretty much fixed now on the desktop, but when you go to the mobile world you're basically bac to first-gen VM territory. It will be interesting to see if Dalvik is much better than your run-of-the-mill J2ME VM these days; I'm sure it's possible, but I think it's yet to be proven (I'd love to see actual tests side by side!). 2) is irrelevant for phones (interestingly enough, apparently Android can't load Java applets from the browser - ha!), but supposedly close to being fixed on PCs - of course, this is now a decade late, years after everyone has written off the applet as a delivery mechanism. 3) is still making Java development hell, so I'm thrilled that Google has decided to throw the whole mess out and start new, I suspect Google will do it much better. Maybe some of their interface code, once opened up, will be useful enough to swim upstream and help out "real" Java?
Jonathan Schwartz's blog post seems to indicate that Sun would prefer to milk this for the publicity rather than cause a fuss over it. Whatever happened behind the scenes, I took that post as a white flag from Sun, basically saying, "Look, we're not on board for a bunch of reasons, but we've got no beef here, let's all try to get along and spin this to each of our needs."
Even if the VM is not officially Java, you're still ending up with a whole lot of development energy invested in Java, which is good for Sun. I really hope there's no way they are stupid enough to bring this to court just to make a few bucks...
FWIW, people haven't exactly been blown away by the user-friendliness of Android's interface, either, at least as used inside the emulator - now maybe a lot of this is because it's awkward to simulate mobile phone controls on a PC screen, but I'm not entirely sure. The difference, of course, between Android and Windows Mobile is that the current incarnation of Android is as an early prototype, not a finished product; Google has been pretty clear about the fact that they are actively seeking input from the public, so it's likely that the product will improve substantially before it actually hits phones. That's one reason it's very smart to release things and collect input for a while before they are used. Anyone that played with early Sugar (the OLPC OS) prototypes and has since gotten to use an actual release candidate XO knows that even over the course of several months, the entire feel of an OS can change considerably if it is under active development, especially if the developers actually listen to people trying to use it.
I agree with the "cool" comment - if Google does this right, they'll push an iPhone-style campaign and make sure everyone wants one months before they are even out.
It's been a long time since I thought of alt.pave.the.earth...
I remember trolling there quite often, they really hated the suggestion they team up with the alt.chrome.the.moon people - go figure, I always figured the nutters would want to band together.
Seriously, though you've gotta love Japan. Once I was driving over some of those awful annoying hum generator strips on the highway here in the US (you know, the ones that wake you up if you fall asleep and start to swerve off the road), and it occurred to me that someone with enough time and money could make simple melodies by changing the spacings between the things. Typical music dork fantasy. As impractical a person as I usually am, even I laughed at the thought; the Japanese went ahead and built the damn thing! Fantastic, I really gotta go there some day. Gotta work out that whole language barrier thing first, I fear...
IMO, Python got the thumbs down for three reasons, 1) there are far more Java developers out there than Python, 2) there is a much larger body of useful Java code for developers to draw on, and 3) adding Python on top of Java is much simpler than the other way around - all that's needed is to get Jython up and running. I'm hoping that support will be added at the OS level at some point before release, it would be a great addition and make certain kinds of development much easier. Java + Python is a pretty good combo, as each one tends to make up for the deficiencies of the other, except when it comes to speed.
Right, but there are problems with try/catch for fragmented services.
Suppose four different phones implement the same functionality in different ways. Now you've got to have four different try/catch segments, and best case scenario, you're going to trip three of those every time you call the thing. Not only is this slow as all hell (catching an exception is one of the slowest ops in Java), it is an abuse of the exception mechanism. Exceptions are supposed to be used for exceptional situations, not for normal control flow.
Any decent programmer can work around this - just do all the try/catches once at init, and store the results, then use a switch to decide what to do when stuff happens more often. But it's not very clean - I'd much rather be able to write Latitude myLat = myGPS.hasLatitude()?myGPS.getLatitude():null; or something like that (I don't remember off the top of my head how it's actually done in Android), rather than checking how each phone does it and create a whole mess of code to deal with it.
Slashdot Mirror
Someone else posted somewhere here that it doesn't matter if the file is marked or not, and that if you download the file from IE or Firefox it is STILL picked up and loaded from the desktop by IE. Sounds like part of the problem is that dll's aren't being checked for safety before loading; whether this is a general "feature" in Windows or something IE specific, I have absolutely no idea, I haven't used Windows in a while so I can't check myself...
That said, IE is worse here - downloading files without my permission is bad form, but a pre-installed system app loading DLLs from any old place that it finds them, especially one of the most common places to dump downloaded files, is just idiotic.
Shame on all.
BTW, this movie is ridiculous - the theory of evolution caused the Holocaust? Wow...at one point I was under the impression Ben Stein was intelligent, but he's really proved me wrong on that by signing on with this drivel-fest.
Watch out, though - "twice the inverse daily performance" does not translate to "twice the inverse monthly performance" due to the magic of compounding.
For example, suppose the S&P gained 10% one day, and lost 10% the next. That would make for a two-day loss of 1%. But the SDS would have lost 20% the first day and gained 20% the second day, making for a two day loss of 4%! So even though the S&P has gone down over two days, the inverse tracking ETF has also gone down! Interestingly enough, in that situation both the leveraged inverse and the leveraged normal ETFs would end up at the same price.
Lesson: know exactly what you're doing when you buy an ultra, because the risk profile is totally different from an unleveraged ETF. Don't expect it to match over more than a day or two.
That's a radical interpretation of the text - like most results in computability theory, Rice's theorem says nothing of much use to anyone that's considering what kinds of real tasks you can possibly perform with a computer. Most of these theorems merely use some spinoff of Cantor's diagonalization argument to show that - surprise! - you can't write a program to do something that's completely and utterly ridiculous to expect a program to do. These theorems are true, but the fun comes when you give a layman's explanation of the unreasonable task at hand and it "seems like" something a human could do. But most of the tasks turn out to be equivalent to solving any and every problem you can imagine, and once you realize that you discover that these impossibility theorems have nothing at all to say about AI, they are really about forcing us to better specify our problem domains. If I can't solve the Riemann hypothesis, then it's certainly not a disproof of AI to realize that a computer can't solve a problem that contains the Riemann hypothesis as a sub-problem!
Not that I'm saying we will get computers to program as well as we do, by any means. That's a whole other can of worms, and to me is more an issue of extremely difficult engineering (possibly too difficult for our feeble minds) than anything else. I'm just saying that abstract arguments are never going to rule out the possibility, and generally they don't even help us see what paths we should or shouldn't pursue.
Theory: the "I know you guys are just going to mod me down for this, but..." line is a guaranteed way to pick up a +5 moderation, no matter what the content of the post is.
I know you guys are just going to mod me down for this, but seriously, I think there's a pattern here.
You're right, of course, on both counts - don't know how I miscounted that, guess I hadn't quite woken up yet! I also didn't notice the parenthesis, which would have negated the whole point of my comment! That's what I get for Slashdotting before my coffee...
Your points are well taken. The "you can't make everyone a criminal" argument doesn't hold legal weight. However, especially in situations where nobody is directly harmed or directly deprived of property, you would think that perhaps there should be a consitutional prohibition on criminalizing a large percentage of the citizenry...frankly, if even 10% of the population is made criminal by a law, that should shed some very serious doubt on the fairness of that law, as it reeks of mob rule.
Unfortunately Americans seem comfortable with letting the majority shit on the minority every chance it gets, thus embracing the worst thing about democracy (two wolfs and a sheep voting on what's for dinner, etc - where's the farmer with the shotgun when you need him?), so I doubt if this will change any time soon.
Science can't explain a lot of things. People often bring this up to explain why religion and the humanities are "better." But I see the exact opposite situation. Einstein's equation does not contain in it the ability to explain why the earth is repelled by the Sun. By no stretch of the imagination could it explain this fact, as it is directly at odds with the rest of the theory - if the Earth WAS repelled by the Sun, we would have to discard Einstein's equation as a basic for gravitational physics. But religion could quite easily accommodate that. It could also explain why God loves it when you eat baby brains, why the sky is green, and why eight plus seven is equal to zero. All of which means the God theory is capable of explaining way too much.
More practically, this issue comes up in neural network training. Having a network with too many nodes leads to overfitting the data; you can't pick out any real patterns because you are able to "explain" any sort of data that comes in. Same thing with polynomial fits - with a high degree polynomial, I can fit any curve, which usually just means I'm fitting the noise rather than the underlying pattern. "God" is the original infinite-order polynomial, a function you might as well just define by listing all the points in it rather than finding any sort of order. In fact, "God" is the weakest theory of them all, because it has no content.
That said, a particular religion has a theory of God with significantly fewer free variables than the generic notion, so it comes closer to a real theory. However, the range of incorrect observations that could be accounted for is still many orders of magnitude higher than any scientifically acceptable theory, so take that as you will...
Of course, ID's greatest strength (that it claims not to be an explicitly religious theory, and thus can be taught in schools) is also its greatest weakness. Why? Simple.
1) Something created us.
2) If it was God, stop - theory is religious, can't be taught in schools.
3) Otherwise, aliens did it.
4) If it was aliens, then who created the aliens?
5) Return to 2), repeat until either a) the theory is religious and God did it, or b) evolution did it.
6)
7) Profit
ID can never possibly make it all the way to profit, any way it turns out, so...
However, I disagree with the notion that if ID was correct you would still have your hands tied as far as investigating the designer. DNA is essentially code, and you can learn a lot about a programmer by reading their code, even if it is compiled. The problem becomes one of forensics rather than philosophy, but unless the designer was actively attempting to hide the design, I highly doubt that it would be very difficult to learn something about them...at least if you presume finite resources in design and deployment, I'm sure you could quite effectively propose, debunk, and revise theories about the designer. That would be science; current ID is not, as you correctly note.
This whole group as unit vs. group as collection thing is quite the irritating topic for me, all jokes aside. I tutor for the SATs, and it tests this stuff quite often (if it's been a while since you've taken it, they've added a grammar section now to bias the test further towards the humanities). Students always get upset when I tell them that, in fact, ETS does consider the phrase "The British Virgin Islands are in the Carribean" to be grammatically incorrect (if you doubt the mistake here, check the first sentence of the Wikipedia page, though you'll notice that when referring to the islands as a collection, the plural is used; same issues come up with "the United States," where you are only supposed to use the plural when actually talking about the collection of states, not the country). I suppose there's a bit of logic in it, but really...these are such piddling points to be testing high school students on, yet the SAT is chock full of this crap.
Frankly, I don't care how anyone says anything as long as the meaning is clear, and the singular/plural distinction so rarely causes actual confusion in this regard. To each his (or their, if you prefer) own...
I'm not saying that this is a huge problem - I still use Java anyways, as despite its little glitches I find it to be overall less painful than C or C++, and I really do think that it is improving (and if it ceases, I'll just jump ship to Python). But it's kind of annoying that for years we have been told that this type of thing is not a problem at all, and that furthermore, that the only workaround is to put supreme faith in the JVM to bless us with everything we need. I'd kind of prefer if Sun just came out and said, "We don't give a glistening poo nugget about people trying to do hardcore computation in Java. Deal with it!" rather than pretending that the solution is already in our hands. Because it's not!
Yes, the JIT compiler is written in C, but you are wrong that a better optimizing C compiler could beat a really good JIT. The whole point of JIT is that it can use current information about how a program is running and do things like arrange objects in memory to increase the cache hit rate. The best C compiler in the world just doesn't have the amount of information available that it would need to do things like this.
That's not to say this all currently works in practice, though. Sun has been telling everyone for the past five years that the JVMs are so robust and intelligent that you don't need lightweight objects to do fast computation (for things like vector math), that you can just use plain old Java objects and the JVM will figure out how to optimize these, and anybody that's ever actually programmed some physics or graphics in Java knows that those claims are still crap. (Though I'm told this version of Java is much better about this stuff, to be fair)
However, failures in implementation aside, there are very good arguments that suggest that as we go forward, JIT compilers will eventually overtake statically compiled code when it comes to speed. IMO the current Java 6 JVM is a pretty good first step towards this ideal JIT compiler; maybe I'd qualify it as a very early alpha version of The Real Thing. Certainly much more of an improvement than the past few versions. It's unfortunate, however, that Sun continues to pretend that they've already got it all figured out and running smoothly, when there is obviously so much more work to do. It's also quite irksome that they ignore most performance-related RFEs, simply promising that the magical JIT will fix everything in the next version...
Indeed - Sun made a lot of big mistakes early on that have severely hampered Java's acceptance since then:
1) The first VMs were truly awful and slow
2) Terrible browser integration with applets
3) AWT as a whole was just a mess, and Swing didn't do much to help things.
4) Brought the language out as a trimmed down C++, only to realize that some of the stuff in C++ was actually useful and put it back in later (it happened with generics and static imports, and if reason takes hold it will eventually happen with operator overloading)
1) is pretty much fixed now on the desktop, but when you go to the mobile world you're basically bac to first-gen VM territory. It will be interesting to see if Dalvik is much better than your run-of-the-mill J2ME VM these days; I'm sure it's possible, but I think it's yet to be proven (I'd love to see actual tests side by side!). 2) is irrelevant for phones (interestingly enough, apparently Android can't load Java applets from the browser - ha!), but supposedly close to being fixed on PCs - of course, this is now a decade late, years after everyone has written off the applet as a delivery mechanism. 3) is still making Java development hell, so I'm thrilled that Google has decided to throw the whole mess out and start new, I suspect Google will do it much better. Maybe some of their interface code, once opened up, will be useful enough to swim upstream and help out "real" Java?
Jonathan Schwartz's blog post seems to indicate that Sun would prefer to milk this for the publicity rather than cause a fuss over it. Whatever happened behind the scenes, I took that post as a white flag from Sun, basically saying, "Look, we're not on board for a bunch of reasons, but we've got no beef here, let's all try to get along and spin this to each of our needs."
Even if the VM is not officially Java, you're still ending up with a whole lot of development energy invested in Java, which is good for Sun. I really hope there's no way they are stupid enough to bring this to court just to make a few bucks...
FWIW, people haven't exactly been blown away by the user-friendliness of Android's interface, either, at least as used inside the emulator - now maybe a lot of this is because it's awkward to simulate mobile phone controls on a PC screen, but I'm not entirely sure. The difference, of course, between Android and Windows Mobile is that the current incarnation of Android is as an early prototype, not a finished product; Google has been pretty clear about the fact that they are actively seeking input from the public, so it's likely that the product will improve substantially before it actually hits phones. That's one reason it's very smart to release things and collect input for a while before they are used. Anyone that played with early Sugar (the OLPC OS) prototypes and has since gotten to use an actual release candidate XO knows that even over the course of several months, the entire feel of an OS can change considerably if it is under active development, especially if the developers actually listen to people trying to use it.
I agree with the "cool" comment - if Google does this right, they'll push an iPhone-style campaign and make sure everyone wants one months before they are even out.
It's been a long time since I thought of alt.pave.the.earth...
I remember trolling there quite often, they really hated the suggestion they team up with the alt.chrome.the.moon people - go figure, I always figured the nutters would want to band together.
Seriously, though you've gotta love Japan. Once I was driving over some of those awful annoying hum generator strips on the highway here in the US (you know, the ones that wake you up if you fall asleep and start to swerve off the road), and it occurred to me that someone with enough time and money could make simple melodies by changing the spacings between the things. Typical music dork fantasy. As impractical a person as I usually am, even I laughed at the thought; the Japanese went ahead and built the damn thing! Fantastic, I really gotta go there some day. Gotta work out that whole language barrier thing first, I fear...
IMO, Python got the thumbs down for three reasons, 1) there are far more Java developers out there than Python, 2) there is a much larger body of useful Java code for developers to draw on, and 3) adding Python on top of Java is much simpler than the other way around - all that's needed is to get Jython up and running. I'm hoping that support will be added at the OS level at some point before release, it would be a great addition and make certain kinds of development much easier. Java + Python is a pretty good combo, as each one tends to make up for the deficiencies of the other, except when it comes to speed.
Right, but there are problems with try/catch for fragmented services.
Suppose four different phones implement the same functionality in different ways. Now you've got to have four different try/catch segments, and best case scenario, you're going to trip three of those every time you call the thing. Not only is this slow as all hell (catching an exception is one of the slowest ops in Java), it is an abuse of the exception mechanism. Exceptions are supposed to be used for exceptional situations, not for normal control flow.
Any decent programmer can work around this - just do all the try/catches once at init, and store the results, then use a switch to decide what to do when stuff happens more often. But it's not very clean - I'd much rather be able to write Latitude myLat = myGPS.hasLatitude()?myGPS.getLatitude():null; or something like that (I don't remember off the top of my head how it's actually done in Android), rather than checking how each phone does it and create a whole mess of code to deal with it.