Comment Re:Science vs. Policy (Score 1) 278
My argument was nnot about whether particular climate models are accurate or not. It was about whether the study of climate qualifies as a science.
My argument was nnot about whether particular climate models are accurate or not. It was about whether the study of climate qualifies as a science.
Again, higher temperatures (no matter who caused them) = polar ice melting = higher sea levels.
You won't have more land. You will have a lot less land.
The problem is, every time a problem is solved, the definition of true AI changes.
Did the turing test change recently? Hadn't noticed. Did someone inform Marvin Minsky?
viruses not virii. You sound like an idiot.
The problem is, you break doesn't machines much finer then you do the human brain.
Please stop! I can't take any more of this!
It's a problem because it requires programmers to concern themselves with low-level tedious details that the compiler could handle for them
So basically your statement can be reduced to is "If you're lazy and stupid, don't use C". I'm fine with that. But I'd like to add that if you're lazy and stupid, don't program at all, become a manager.
C is especially bad because the language doesn't even have a way to talk about the size of an array. When you pass an array to a function, all size info is lost. This sucks.
How is that a problem? Pass the size in a separate variable. Put the array in a struct and add a member for the size. Or add a function to your struct that returns the size. Whatever. The possibilities are there. If you don't use them because programming in C is less cushy than in other languages, the fault is entirely yours. There is nothing in C preventing you from writing proper code. You just have to do it, with the understanding that it will be more work. But it's hardly impossible.
That's exactly the problem. If you think to add features first, security later you have already made a fundamental mistake. Writing secure code is not a matter of adding extra checking later. It means writing good, proper code right from the start. One of the most obvious consequences of that is not to use functions like sprintf at all, but use substitutes that allow and in fact demand proper length checking.
My $0.05: Of course managers never see a business case for adding security checking later. There is no obvious way it will make the company more money, so something "more important" will take precedent. But on the other hand, not writing secure code right from the start also means the programmer is not making a habit of writing good code. It shows a serious problem with their attitude toward their own work. That is not to say that there won't still be mistakes made, but a lot of them can be prevented right from the start.
There are two ways to write error-free programs; only the third one works.
