Well - but if a h.265 licensee is sued for patents which concern the video codec, the other licensees and the MPEG-LA members will be threatened too, and those last-ones have a huge portfolio of other patents which they can use to force and protect them-selfs and their paying customers.
Unless the patent holder is a patent troll who doesn't produce anything and therefore can't violate a patent himself (unless someone in the MPEG-LA has a business patent on patent trolling, that is).
Well, you have to decide: Do you want to be treated as private person, or as provider? You cannot say "I'm provider where the private person rules are worse for me, but private person where the provider rules are worse for me."
A managed memory model does the opposite to teaching you memory management. What damage did Pascal do to your understanding of memory? I can't imagine any.
4) Doesn't meet user needs. Actually, that's the only real way a software can go wrong (the user doesn't need crashes or blow-ups, and he doesn't really care whether it was the spec which was wrong, or its implementation).
OK, you're writing wasteful C++ code, and then translating it into elegant Haskell which is probably just as wasteful (OK, one specific waste probably goes away, because I guess Haskell doesn't copy around the elements the same way your C++ code does). Now it's easy to make the C++ code less wasteful, how do you do it with Haskell? Or are Haskell compilers smart enough to optimize those inefficiencies away themselves (including the one which isn't in your C++ code, namely using separate iterations for getting the larger and smaller elements)?
And note that I'm not talking about the algorithmic inefficiency of taking the first element as pivot (which makes the algorithm quadratic if used on an already-sorted or almost sorted array). Although that's also an interesting point: In C++ it's easy to switch to median-of-three pivoting. How would you do it in Haskell (and how efficient would it be)?
Also, a common optimization is to switch to insertion sort for small (sub-)arrays. Again, this is easy to do in C++, but how would you do it in Haskell?
I suspect that any realistic quicksort code in Haskell would not be much simpler than in C++ (note also that your C++ code is not only more inefficient, but also more complex than it has to be; you better don't show that code to any potential employer:-)).
I can't remember having ever a battery dying on my calculator. I've got a calculator bought more than 20 years ago, and it still has the original battery, and it still works perfectly.
Having said that, the answer to your question is simple: Insert another battery.
Huh, when did they add lambdas to C++? I must have missed something.
Well, strictly speaking, they will add them in 2011 (this is when they will finally approve the new version of the C++ standard, which contains lambdas).
However, an implementation of lambdas using existing language facilities was already available in C++ for quite some time through boost.
If you're a good programmer, programming languages are easy. If you're curious about a language, you can learn the basics of it in a few hours and be adequate in the language in a weekend.
That depends. If the programming language is of the same style as those you already know, then yes. However, I doubt that e.g. a C programmer, no matter how excellent, would grasp a pure functional language in a weekend if he never learned about functional programming before. And no, the syntax wouldn't be the problem (indeed, functional languages tend to have relatively simple syntax).
Pointers, for example, make a lot more sense when you know they represent memory addresses.
It's both an advantage and a disadvantage to know that pointers represent memory addresses. It's an advantage because it gives you a simple model to think in. It's a disadvantage because it tempts you to use that model even where it doesn't apply (e.g. freely using typecasts on pointers and expecting it to work because it points to the same memory address, while the optimizer legally assumes it doesn't). Note that there are other metaphors you can use for pointers, which may be more helpful for the beginner (e.g. page/chapter/equation numbers; you wouldn't expect to get something meaningful if you use a page number as equation number).
Personally I think that if you're teaching programming, you should stick with a more abstract language.
I think you should be taught both a very abstract language and assembly. The very abstract language forces you to think about programming problems without caring about the concrete implementation on the computer (thus avoiding the trap of being caught in low-level thinking), and assembly forces you to consider the way computers work at a very low level (thus avoiding the trap of being caught in high-level thinking). And then you should learn C (or C++). Not so much because C is hard, but because learning those other languages already taught you those lessons you are too likely to mis-learn in C. And because it's on one hand high-level enough to recognize certain structures you learned in the high-level language, but also low-level enough that you can easily understand how it translates into the low-level assembly stuff, thus bridging the two levels.
Well, until you come up with a replicator, traditional property rights will have to remain. You simply cannot get any ramen without taking it away from someone else (unless you produce it yourself, but then the same applies to the stuff out of which you make ramen).
What bosses love to have around are smart people who get things done and don't mind working 60 hour weeks standard (up from there whenever anything surprising happens or is badly panned) for a 40-hour salary.
[...]
Every time you work long hours, you create expectations that your co-workers should work long hours too, and they will despise you for it.
There is no death which can be proved to be caused by global warming. But the victims of Kathrina are very likely victims of global warming. It's just as if some strong smoker dies from lung cancer. You cannot prove that the lung cancer in his case was caused by his smoking, but it's very likely.
"Pro Climate Change Alarmists" want to stop the earth from warming. Why? The earth is a big place, and likely to correct on it's own. Also, in a much longer time span than we've had recorded history, climate temps have fluctuated drastically.
Well, the problem may be that the "correction on its own" may lead to consequences that we humans wouldn't enjoy. On the large scale of things it doesn't even matter if half of the humans die, or even if humanity is completely extinguished. Forget about the question what is good for earth. Ask: What is good for us (but please, include all of humanity in "us", not just those few who have the advantage to live at places which might profit from warmer temperatures).
Does a rejected patent also cost some fee? (It would be reasonable, because after all, it did cost something to examine it). In that case, a good incentive would be that the first one who finds prior art gets some part of that fee.
Or simply $100*2^n for n years of protection. Protecting for one year would be cheap, $200. Almost everyone can afford that. Protecting for 10 years would be quite expensive, $102,400. Only reasonable if you can make lots of money from the invention. Protecting for 20 years would be prohibitively expensive, $104,857,600. No sane company would pay that much.
Slashdot Mirror
It's buggy.
Enter
(which is equivalent to #define foo bar)
and it will be "beautified" to
(which is equivalent to #define foobar)
How many programs make sense both on a phone and a gaming console?
Unless the patent holder is a patent troll who doesn't produce anything and therefore can't violate a patent himself (unless someone in the MPEG-LA has a business patent on patent trolling, that is).
ITYM: :-)
IDNW TL;DR MUISYP. CWAATAWTSISSTHTMUALTIWLT?
(Filter error: Don't use so many caps. It's like YELLING.
Answer: No it isn't. It's acronymising.)
Well, this partial thread was about using a "provider excuse" (leaving the WiFi open as public service) to get around rules for individuals.
Well, you have to decide: Do you want to be treated as private person, or as provider? You cannot say "I'm provider where the private person rules are worse for me, but private person where the provider rules are worse for me."
http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html
A managed memory model does the opposite to teaching you memory management.
What damage did Pascal do to your understanding of memory? I can't imagine any.
4) Doesn't meet user needs. Actually, that's the only real way a software can go wrong (the user doesn't need crashes or blow-ups, and he doesn't really care whether it was the spec which was wrong, or its implementation).
OK, you're writing wasteful C++ code, and then translating it into elegant Haskell which is probably just as wasteful (OK, one specific waste probably goes away, because I guess Haskell doesn't copy around the elements the same way your C++ code does). Now it's easy to make the C++ code less wasteful, how do you do it with Haskell? Or are Haskell compilers smart enough to optimize those inefficiencies away themselves (including the one which isn't in your C++ code, namely using separate iterations for getting the larger and smaller elements)?
And note that I'm not talking about the algorithmic inefficiency of taking the first element as pivot (which makes the algorithm quadratic if used on an already-sorted or almost sorted array). Although that's also an interesting point: In C++ it's easy to switch to median-of-three pivoting. How would you do it in Haskell (and how efficient would it be)?
Also, a common optimization is to switch to insertion sort for small (sub-)arrays. Again, this is easy to do in C++, but how would you do it in Haskell?
I suspect that any realistic quicksort code in Haskell would not be much simpler than in C++ (note also that your C++ code is not only more inefficient, but also more complex than it has to be; you better don't show that code to any potential employer :-)).
I can't remember having ever a battery dying on my calculator. I've got a calculator bought more than 20 years ago, and it still has the original battery, and it still works perfectly.
Having said that, the answer to your question is simple: Insert another battery.
"no more lambdas"
Huh, when did they add lambdas to C++? I must have missed something.
Well, strictly speaking, they will add them in 2011 (this is when they will finally approve the new version of the C++ standard, which contains lambdas).
However, an implementation of lambdas using existing language facilities was already available in C++ for quite some time through boost.
That depends. If the programming language is of the same style as those you already know, then yes. However, I doubt that e.g. a C programmer, no matter how excellent, would grasp a pure functional language in a weekend if he never learned about functional programming before. And no, the syntax wouldn't be the problem (indeed, functional languages tend to have relatively simple syntax).
It's both an advantage and a disadvantage to know that pointers represent memory addresses. It's an advantage because it gives you a simple model to think in. It's a disadvantage because it tempts you to use that model even where it doesn't apply (e.g. freely using typecasts on pointers and expecting it to work because it points to the same memory address, while the optimizer legally assumes it doesn't). Note that there are other metaphors you can use for pointers, which may be more helpful for the beginner (e.g. page/chapter/equation numbers; you wouldn't expect to get something meaningful if you use a page number as equation number).
I think you should be taught both a very abstract language and assembly. The very abstract language forces you to think about programming problems without caring about the concrete implementation on the computer (thus avoiding the trap of being caught in low-level thinking), and assembly forces you to consider the way computers work at a very low level (thus avoiding the trap of being caught in high-level thinking). And then you should learn C (or C++). Not so much because C is hard, but because learning those other languages already taught you those lessons you are too likely to mis-learn in C. And because it's on one hand high-level enough to recognize certain structures you learned in the high-level language, but also low-level enough that you can easily understand how it translates into the low-level assembly stuff, thus bridging the two levels.
if it's anything like the common tree, the rings might indicate its age
You mean, Jupiter made a rejuvenating cure?
Agreed: It's a lousy story.
Well, until you come up with a replicator, traditional property rights will have to remain. You simply cannot get any ramen without taking it away from someone else (unless you produce it yourself, but then the same applies to the stuff out of which you make ramen).
Be productive, but not too productive?
Be competent, but not too competent?
I guess that was the point.
Note the following emphasis:
[...]
There is no death which can be proved to be caused by global warming. But the victims of Kathrina are very likely victims of global warming.
It's just as if some strong smoker dies from lung cancer. You cannot prove that the lung cancer in his case was caused by his smoking, but it's very likely.
Well, the problem may be that the "correction on its own" may lead to consequences that we humans wouldn't enjoy. On the large scale of things it doesn't even matter if half of the humans die, or even if humanity is completely extinguished.
Forget about the question what is good for earth. Ask: What is good for us (but please, include all of humanity in "us", not just those few who have the advantage to live at places which might profit from warmer temperatures).
http://en.swpat.org/wiki/Defensive_patent_pools
Does a rejected patent also cost some fee? (It would be reasonable, because after all, it did cost something to examine it). In that case, a good incentive would be that the first one who finds prior art gets some part of that fee.
Or simply $100*2^n for n years of protection.
Protecting for one year would be cheap, $200. Almost everyone can afford that.
Protecting for 10 years would be quite expensive, $102,400. Only reasonable if you can make lots of money from the invention.
Protecting for 20 years would be prohibitively expensive, $104,857,600. No sane company would pay that much.
Given that I didn't anywhere state what my position is, I'm very astonished that you believe to know it.