Something that may cost you money starting 2011. MPEG-LA has indicated that it's likely to require royalties for streaming (not encoding; simply making available in a streamable fashion) H.264 starting then, with the final decisions on pricing and such to be made in December 2009, last I checked.
Of course for the next year or so you're ok.
The fact is, the video codec landscape on the web just doesn't look very good.
> then declaring that people born in winter suffer from a lifelong plight, without > even bothering to provide genuine reasoning
You seem to be somewhat confused. There's varied observational data, predating this study, showing that children born in winter tend to do (very slightly) worse in life. The question hast been _why_ this is the case.
This study points out that:
1) Children born in winter are (very slightly) more likely to be born to teen mothers. 2) There are existing studies comparing children born to teen mothers to other children,
and those born to teen mothers tend to do slightly worse. Again, without saying
_why_, but that's the observation. Various hypotheses could be advanced to explain
it, of course. 3) One could assume (and this is an assumption) that children born to teen mothers are,
on average, the same year round and assume the same for children born to non-teen
mothers. One could then see, under this assumption, how much of the difference
observed above in item 1 is accounted for by the known observed differences of item 2.
Depending on how well the numbers one gets from the procedure in item 3 match those observed in item 1, and on how confident one feels in the assumptions made in item 3, one could make the argument that one has discovered something about the causes of item 1: namely that they are likely to be the same as the causes of item 2, whatever those are. Note that the claim is not that one has established causation of anything. However one has advanced a hypothesis: if the causative mechanisms of item 2 are discovered and can be controlled for when studying the data for item 1, one could see whether the effect of item 1 remains.
Maybe. It depends on how it's set up. In Chrome (the browser) the webkit renderers are run in separate processes and those processes are sandboxed so as to not have any access to resources other than the ipc communication channel with the master process....
As it happens, IE8's support for CSS2.1 is fairly good in the sense that everything that is clearly defined in the spec is in fact implemented, to my knowledge.
That does mean that things that are _not_ clearly defined might not be interoperable with other browsers. That's not exactly IE's fault; it's the spec's fault. The other browsers are not exactly interoperable with each other on those points either.
It also means that CSS features that are not in CSS2.1 (e.g. many of the CSS3 Selectors features) are not supported in IE8.
Javascript is not object-oriented in any of the traditional senses of the word. It provides features you can build an OO-like system on top of, but so does any language with closures and first-class functions...
If intellectuals actually tended to make decisions based on evidence, you might have a point. But most non-scientist (that includes the social sciences, usually). intellectuals in fact do not. They do perhaps make them based on thinking and logic. So did Aristotle, in deciding that men have more teeth than women.
Of the scientists, things are more or less hit-and-miss depending on field.
I recommend reading if you're willing to be a little depressed. The rats section, as well as the one about physics. Things haven't gotten better since then, sadly.
> our schools are full of intellectual types trying to convince kids that book-learnin' is > important, and that scientific method works.
They don't do a very good job of this because they never actually teach the scientific method (in particular what it means to form a hypothesis, what it means to test it, and how to figure out what your test says).
> Bring on the less intelligent, wholesome, family-oriented Real(tm) Americans(tm) > who can just Know things
Both the people you describe and the so-called intellectuals "just Know things". Some of them hide it better than others, of course. And some are more pretentious than others.
So per acre we get (50-150)*60/(2.2*1000) == 1.4-4.2 tons.
Given the 627 million ton production figure, that comes out to somewhere between 150 million and 450 million acres devoted to wheat cultivation. An acre is about 4047 square meters, so that gives us somewhere between 600,000 and 1,800,000 square kilometers devoted to wheat cultivation right now.
Borlaug's work raised yields by a factor of 3 or so, right? Therefore without his work achieving similar wheat production would have required an additional 1,200,000 to 3,600,000 square kilometers (120 million to 360 million hectares) devoted to wheat cultivation.
Similar methods have been applied to other cereal crops, of course. From the same Wikipedia article on Agriculture, maize production is 721 million metric tons. World-average yields are in the 4 tons per hectare range (http://www.fao.org/docrep/004/ad452e/ad452e0m.htm). That gives about 180 million hectares. Again, assuming yields rose 3x or so due to Borlaug's work that would have meant 360 million additional hectares of maize.
We haven't even looked at rice (which has total worldwide production similar to wheat and maize) or barley (about 4x less) yet.
These are all ballpark numbers of course, but 1 billion hectares isn't sounding all that implausible to me based on the above.
The problem is that people want a mix. Your typical news site wants text flow with a navigation+multimedia application around it. gmail wants text flow with a mail client around it. Google docs wants text/flow with a word processor around it. A wiki often enough wants text flow with an HTML editor around it (though some wikis are of course still using textareas for editing).
> This may be resolved over time as all the different engines approach the theoretical > limits of how fast you can make JavaScript
Given that JITs always involve heuristics and that the various JavaScript jits are taking very different approaches, I'm not sure this will happen. I think it more likely that we'll have testcases on which Nitro is 2-5x faster than Spidermonkey and other testcases on which Spidermonkey is 2-5x faster than Nitro (and similar for comparisons to V8) and on which all those numbers will be 2-5x faster than interpreters were 2 years ago (which is about where IE is right now).
> Performance concerns with "fill color" and such are not an issue because they are > offloaded to the graphics card.
The original poster's concern was with _setting_ the fill color. Since the format for the set is a string that allows the full CSS color syntax and hence has to be parsed with a full CSS parser, changing the fill color is in fact somewhat expensive. It's comparable in time spent to the fill operation itself in browsers last I tested.
I'm not sure why services should need exceptions. Why should there not just be free trade in services?
Examples of services we currently do NOT have free trade in: legal, medical, certified public accountant. For these, in addition to any professional examinations (which do make sense) there are also education requirements which give existing members of the profession veto power over who is allowed to practice the profession in the US. The result, as with any monopoly, is high prices. Precisely the sort of situation free trade is in theory supposed to address.
I can assure you there is no shortage of doctors in India who would be willing to work in the US if they were allowed to and are qualified to do so. Legal and CPA involve some knowledge about the specifics of local regulations, but I'm sure if the market were there there would once again be no shortage of takers.
Of course I doubt this sort of change to our trade agreements will ever be made, given the lobbying power of the AMA and the various bar associations.
> Learning A does mean you're note spending the same time learning B.
"not", of course. Proofreading is another important skill that's undertaught, and in my opinion more important than fast typing. Now if only I actually applied it to my Slashdot comments....;)
> using the computer by typing letters into it is the main form of data entry for developers
While maybe true (and I'm not convinced; a lot of my data entry as a developer is the delete key and the copy and paste keys as code is refactored; or did you assume that developers are all writing brand-new code all the time), my point was that data entry is a very small percentage of total time using a computer for a developer. Again, unless you're writing brand-new code from scratch.
> why would you expect them to learn other aspects of the trade?
Maybe they have instead focused on learning other things that are more useful? Learning A does mean you're note spending the same time learning B.
> They seem to not think that efficient data entry is important.
In my experience it's not. Efficient reading of code, yes. Efficient understanding of code, yes. Efficient editing of existing code, yes. Efficient creation of large amounts of new text, not nearly as important.
Depends on the project, of course.
> why do you people think that a simple skill such as touch-typing is not important and > not something students should be taught?
I didn't say that, now did I? I just pointed out that judging a developer by how fast he types may not be a very good idea. In fact, it's probably a terrible idea.
Similarly, judging an author by how fast he types is a bad idea.
On the other hand, a secretary or a stenographer, that might be a more relevant metric.
> Seriously, why is it not important to learn how to type efficiently?
Lots of things are important to learn. Typing efficiently is somewhere on the list, not particularly near the top, in my opinion. If you have time to do it, great. If not, it may or may not be a problem depending on your career aspirations.
> I guess we just live in a world where people are happy with close enough, good enough.
Of course. Engineering is all about tradeoffs. If as a developer I have the choice between working on typing faster and learning about a new data structure that may be relevant to my work, which one should I pick? It really depends on the situation; settling for worse typing but a better algorithm might be better in some cases; going the other way might be in ours.
> FYI, good enough always gets replaced by done well eventually.
All else being equal, yes. All else is usually not equal.
Is typing speed really the gating factor in code production?
For me, except for the most trivial of situations, it's always been the design, compilation, testing, etc. Amount of actual code that needs to be typed is dwarfed by the amount of thinking about what needs to be typed.
As a counterexample, compiling the Mozilla source is most certainly I/O bound: I can do a full tree compile about 2-3x faster there warm than cold.
In practice, for different projects different things will be the limiting factors for compilation. Have lots of headers? More likely to be I/O bound. Have only one large file with some code that triggers an O(N^2) algorithm in the compiler's optimizer? More likely to be CPU bound.
What I _can_ guarantee you is that if you're compiling Mozilla and using gnome-terminal then redirecting all the output from the compile to a file will speed up your compile considerably, assuming you're using a -j setting high enough to utilize your cores well. the terminal app will suck up CPU like crazy to show all that text scrolling by.
How is this not of the same ethical caliber of spiking trees? You mean this isn't as likely to kill people as spiking trees is? If so, possibly true.
Spiking trees is about as despicable as anything I've seen people do recently. About the moral equivalent of disabling the brakes on someone's SUV because you think they should be driving a car that gets better gas mileage.
> Unless Adobe suddenly gets its shit together, that's not something any browser developer > can fix.
Actually, it is. Just have to put the plug-in in a separate process. Safari's working on that; so is Firefox. Then it can crash its little sandbox all it wants...
> Our 'ancient' washing machine got clothes clean and never ripped a single garment
Sure. I'm not saying the old one was always bad. Just that there are certain cases in which the new one is better (e.g. I have in fact had issues with older washing machines ripping garments that got caught on the agitator and stretched too much).
> It sits in a utility room and I don't hear it when the door is closed, so quieter is of > no benefit.
To you, sure. Mine sits in the corner of the kitchen, so I can assure you that quieter is of benefit to me.
> It looks like they are DIFFERENT but not better
Or rather they're better in ways that don't matter to you. That's unfortunate, but likely to be the case for some subset of users no matter what improvements are made.
> Planned obsolescence on the other hand can cost me plenty
Sure thing; I never claimed that planned obsolescence was a good thing.;)
They wash clothes more quietly, don't rip them as much, use less water (lower operating costs for those of us who pay for water), do a better job of washing ("clean" vs "not clean" is not a binary state). That's off the top of my head; if I were seriously comparing washing machines I'm pretty sure there would be more in that list.
Slashdot Mirror
> Image file formats and HTML pages are not Turing complete, while Javascript is
Depends on how you define "image file" (is PostScript allowed?) and "HTML page" (is client-side XSLT allowed?).
> And today, I can put it out on the web
Something that may cost you money starting 2011. MPEG-LA has indicated that it's likely to require royalties for streaming (not encoding; simply making available in a streamable fashion) H.264 starting then, with the final decisions on pricing and such to be made in December 2009, last I checked.
Of course for the next year or so you're ok.
The fact is, the video codec landscape on the web just doesn't look very good.
> then declaring that people born in winter suffer from a lifelong plight, without
> even bothering to provide genuine reasoning
You seem to be somewhat confused. There's varied observational data, predating this study, showing that children born in winter tend to do (very slightly) worse in life. The question hast been _why_ this is the case.
This study points out that:
1) Children born in winter are (very slightly) more likely to be born to teen mothers.
2) There are existing studies comparing children born to teen mothers to other children,
and those born to teen mothers tend to do slightly worse. Again, without saying
_why_, but that's the observation. Various hypotheses could be advanced to explain
it, of course.
3) One could assume (and this is an assumption) that children born to teen mothers are,
on average, the same year round and assume the same for children born to non-teen
mothers. One could then see, under this assumption, how much of the difference
observed above in item 1 is accounted for by the known observed differences of item 2.
Depending on how well the numbers one gets from the procedure in item 3 match those observed in item 1, and on how confident one feels in the assumptions made in item 3, one could make the argument that one has discovered something about the causes of item 1: namely that they are likely to be the same as the causes of item 2, whatever those are. Note that the claim is not that one has established causation of anything. However one has advanced a hypothesis: if the causative mechanisms of item 2 are discovered and can be controlled for when studying the data for item 1, one could see whether the effect of item 1 remains.
Maybe. It depends on how it's set up. In Chrome (the browser) the webkit renderers are run in separate processes and those processes are sandboxed so as to not have any access to resources other than the ipc communication channel with the master process....
> Can you defend this claim?
As it happens, IE8's support for CSS2.1 is fairly good in the sense that everything that is clearly defined in the spec is in fact implemented, to my knowledge.
That does mean that things that are _not_ clearly defined might not be interoperable with other browsers. That's not exactly IE's fault; it's the spec's fault. The other browsers are not exactly interoperable with each other on those points either.
It also means that CSS features that are not in CSS2.1 (e.g. many of the CSS3 Selectors features) are not supported in IE8.
I never felt "if I could write faster I could have done beter", but I _have_ felt "If only I could write more efficiently my hand would hurt less"...
> And who composes an essay so fast that the limiting factor is the physical act of writing?
Anyone reasonable writing the SAT essay portion, since time is so limited there and requirements on writing quality so low.
Same with AP history tests, in my experience.
Power factor is described fairly well at http://en.wikipedia.org/wiki/Power_factor
I'm surprised that the requiement is a _max_ power factor, not a min one... Generally higher power factor is more desirable.
Javascript is not object-oriented in any of the traditional senses of the word. It provides features you can build an OO-like system on top of, but so does any language with closures and first-class functions...
If intellectuals actually tended to make decisions based on evidence, you might have a point. But most non-scientist (that includes the social sciences, usually). intellectuals in fact do not. They do perhaps make them based on thinking and logic. So did Aristotle, in deciding that men have more teeth than women.
Of the scientists, things are more or less hit-and-miss depending on field.
I recommend reading if you're willing to be a little depressed. The rats section, as well as the one about physics. Things haven't gotten better since then, sadly.
> our schools are full of intellectual types trying to convince kids that book-learnin' is
> important, and that scientific method works.
They don't do a very good job of this because they never actually teach the scientific method (in particular what it means to form a hypothesis, what it means to test it, and how to figure out what your test says).
> Bring on the less intelligent, wholesome, family-oriented Real(tm) Americans(tm)
> who can just Know things
Both the people you describe and the so-called intellectuals "just Know things". Some of them hide it better than others, of course. And some are more pretentious than others.
First off, the article says 1 billion hectares, not 10 billion. That does make your 10,000,000 km^2 number correct, though.
Let's run some numbers.
According to http://en.wikipedia.org/wiki/Agriculture, wheat production for 2004 was 627 milion metric tons. Wheat yields seem to be in the 50-150 bushel per acre range (see http://www.cotf.edu/ete/modules/climate/GCremote5.html and http://wiki.answers.com/Q/What_is_the_average_yield_of_wheat_per_acre). A bushel of wheat is generally taken to be 60 pounds (see http://extension.missouri.edu/publications/DisplayPub.aspx?P=G4020).
So per acre we get (50-150)*60/(2.2*1000) == 1.4-4.2 tons.
Given the 627 million ton production figure, that comes out to somewhere between 150 million and 450 million acres devoted to wheat cultivation. An acre is about 4047 square meters, so that gives us somewhere between 600,000 and 1,800,000 square kilometers devoted to wheat cultivation right now.
Borlaug's work raised yields by a factor of 3 or so, right? Therefore without his work achieving similar wheat production would have required an additional 1,200,000 to 3,600,000 square kilometers (120 million to 360 million hectares) devoted to wheat cultivation.
Similar methods have been applied to other cereal crops, of course. From the same Wikipedia article on Agriculture, maize production is 721 million metric tons. World-average yields are in the 4 tons per hectare range (http://www.fao.org/docrep/004/ad452e/ad452e0m.htm). That gives about 180 million hectares. Again, assuming yields rose 3x or so due to Borlaug's work that would have meant 360 million additional hectares of maize.
We haven't even looked at rice (which has total worldwide production similar to wheat and maize) or barley (about 4x less) yet.
These are all ballpark numbers of course, but 1 billion hectares isn't sounding all that implausible to me based on the above.
The problem is that people want a mix. Your typical news site wants text flow with a navigation+multimedia application around it. gmail wants text flow with a mail client around it. Google docs wants text/flow with a word processor around it. A wiki often enough wants text flow with an HTML editor around it (though some wikis are of course still using textareas for editing).
> This may be resolved over time as all the different engines approach the theoretical
> limits of how fast you can make JavaScript
Given that JITs always involve heuristics and that the various JavaScript jits are taking very different approaches, I'm not sure this will happen. I think it more likely that we'll have testcases on which Nitro is 2-5x faster than Spidermonkey and other testcases on which Spidermonkey is 2-5x faster than Nitro (and similar for comparisons to V8) and on which all those numbers will be 2-5x faster than interpreters were 2 years ago (which is about where IE is right now).
> Performance concerns with "fill color" and such are not an issue because they are
> offloaded to the graphics card.
The original poster's concern was with _setting_ the fill color. Since the format for the set is a string that allows the full CSS color syntax and hence has to be parsed with a full CSS parser, changing the fill color is in fact somewhat expensive. It's comparable in time spent to the fill operation itself in browsers last I tested.
I'm not sure why services should need exceptions. Why should there not just be free trade in services?
Examples of services we currently do NOT have free trade in: legal, medical, certified public accountant. For these, in addition to any professional examinations (which do make sense) there are also education requirements which give existing members of the profession veto power over who is allowed to practice the profession in the US. The result, as with any monopoly, is high prices. Precisely the sort of situation free trade is in theory supposed to address.
I can assure you there is no shortage of doctors in India who would be willing to work in the US if they were allowed to and are qualified to do so. Legal and CPA involve some knowledge about the specifics of local regulations, but I'm sure if the market were there there would once again be no shortage of takers.
Of course I doubt this sort of change to our trade agreements will ever be made, given the lobbying power of the AMA and the various bar associations.
Why free trade in goods only? What about services?
Put another way, why only expose blue-collar workers in the US to global competition?
> Learning A does mean you're note spending the same time learning B.
"not", of course. Proofreading is another important skill that's undertaught, and in my opinion more important than fast typing. Now if only I actually applied it to my Slashdot comments.... ;)
> using the computer by typing letters into it is the main form of data entry for developers
While maybe true (and I'm not convinced; a lot of my data entry as a developer is the delete key and the copy and paste keys as code is refactored; or did you assume that developers are all writing brand-new code all the time), my point was that data entry is a very small percentage of total time using a computer for a developer. Again, unless you're writing brand-new code from scratch.
> why would you expect them to learn other aspects of the trade?
Maybe they have instead focused on learning other things that are more useful? Learning A does mean you're note spending the same time learning B.
> They seem to not think that efficient data entry is important.
In my experience it's not. Efficient reading of code, yes. Efficient understanding of code, yes. Efficient editing of existing code, yes. Efficient creation of large amounts of new text, not nearly as important.
Depends on the project, of course.
> why do you people think that a simple skill such as touch-typing is not important and
> not something students should be taught?
I didn't say that, now did I? I just pointed out that judging a developer by how fast he types may not be a very good idea. In fact, it's probably a terrible idea.
Similarly, judging an author by how fast he types is a bad idea.
On the other hand, a secretary or a stenographer, that might be a more relevant metric.
> Seriously, why is it not important to learn how to type efficiently?
Lots of things are important to learn. Typing efficiently is somewhere on the list, not particularly near the top, in my opinion. If you have time to do it, great. If not, it may or may not be a problem depending on your career aspirations.
> I guess we just live in a world where people are happy with close enough, good enough.
Of course. Engineering is all about tradeoffs. If as a developer I have the choice between working on typing faster and learning about a new data structure that may be relevant to my work, which one should I pick? It really depends on the situation; settling for worse typing but a better algorithm might be better in some cases; going the other way might be in ours.
> FYI, good enough always gets replaced by done well eventually.
All else being equal, yes. All else is usually not equal.
> I've seen developers who can't touch-type
Is typing speed really the gating factor in code production?
For me, except for the most trivial of situations, it's always been the design, compilation, testing, etc. Amount of actual code that needs to be typed is dwarfed by the amount of thinking about what needs to be typed.
As a counterexample, compiling the Mozilla source is most certainly I/O bound: I can do a full tree compile about 2-3x faster there warm than cold.
In practice, for different projects different things will be the limiting factors for compilation. Have lots of headers? More likely to be I/O bound. Have only one large file with some code that triggers an O(N^2) algorithm in the compiler's optimizer? More likely to be CPU bound.
What I _can_ guarantee you is that if you're compiling Mozilla and using gnome-terminal then redirecting all the output from the compile to a file will speed up your compile considerably, assuming you're using a -j setting high enough to utilize your cores well. the terminal app will suck up CPU like crazy to show all that text scrolling by.
> Comments like that lead me to believe that you're one of those people that are the reason
> why people still prefer to use Windows.
That comment was just a description of the Unix philosophy, without endorsement thereof.
It seems like an accurate description. See http://www.jwz.org/doc/worse-is-better.html for more expansion of that.
You seem to disagree with the philosophy. That's fine; it's not exactly the best philosophy in the world. ;)
How is this not of the same ethical caliber of spiking trees? You mean this isn't as likely to kill people as spiking trees is? If so, possibly true.
Spiking trees is about as despicable as anything I've seen people do recently. About the moral equivalent of disabling the brakes on someone's SUV because you think they should be driving a car that gets better gas mileage.
> Unless Adobe suddenly gets its shit together, that's not something any browser developer
> can fix.
Actually, it is. Just have to put the plug-in in a separate process. Safari's working on that; so is Firefox. Then it can crash its little sandbox all it wants...
> Our 'ancient' washing machine got clothes clean and never ripped a single garment
Sure. I'm not saying the old one was always bad. Just that there are certain cases in which the new one is better (e.g. I have in fact had issues with older washing machines ripping garments that got caught on the agitator and stretched too much).
> It sits in a utility room and I don't hear it when the door is closed, so quieter is of
> no benefit.
To you, sure. Mine sits in the corner of the kitchen, so I can assure you that quieter is of benefit to me.
> It looks like they are DIFFERENT but not better
Or rather they're better in ways that don't matter to you. That's unfortunate, but likely to be the case for some subset of users no matter what improvements are made.
> Planned obsolescence on the other hand can cost me plenty
Sure thing; I never claimed that planned obsolescence was a good thing. ;)
> What progress?
They wash clothes more quietly, don't rip them as much, use less water (lower operating costs for those of us who pay for water), do a better job of washing ("clean" vs "not clean" is not a binary state). That's off the top of my head; if I were seriously comparing washing machines I'm pretty sure there would be more in that list.