If the crew is relying on technology to manufacture its rocket fuel to get home from the hydrogen and oxygen locked up in the Martian ice then it had better work - first time.
Yeah, it's a shame we have no ice here on Earth with which to test this system. Anyway, the rocket booster that lifted Armstrong and Aldrin off the moon had to "work the first time", and they still signed up.
History is full of shortsighted people telling us what scientists can't possibly do, sometimes only months before they do it.
During my thesis work, I had a lot of strain on the muscles and tendons on the pinky-side of my forearms. I actually had to stop all work for about four days at one point. Once I got the split keyboard, the problem disappeared. (It was also helped by using Dragon Naturally Speaking to dictate parts of my thesis.)
Going back to my old keyboard afterward, I also found that the keys are stiffer. I think that was also part of it.
What a bizarre way to report the story. The news is not that terrabit densities have been achieved; rather, that GMR will not be the technique that will get us there. Hardly news at all.
Ok, let's assume that these things are untestable, as you say. My point is that Design by Contract means minimizing the portions of the program that are untestable. If, even after careful consideration, your particular application has large portions that are untestable, then granted, Design by Contract won't help much for those parts. I won't argue with that.
What I argue with is your assertion (no pun intended) that such parts are of a "higher level" than those parts which are testable. I contend that they are merely of a different "kind". GUIs are full of this kind of thing. I grant that GUIs are hard to analyze with DbC, but I claim that mony other parts of a program benefit tremendously from this kind of analysis.
Your example of perceived latency is a perfect example of this, since real-time programmers do this kind of analysis for exactly this reason.
True, there are certain things that cannot be captured by executable assertions. However, I disagree that it's a matter of "level". You can have high-level, abstract assertions just as well as low-level ones. The examples you gave are just assertions of a kind that can't be checked automatically at runtime, not a level.
Having said that, I think the examples you gave are more amenable to runtime checking than you might think. Checking time constraints is trivial--all you need is a couple calls to gettimeofday--though the challenge here would be to find a systematic way to put these checks in all the right places. A more fundamental challenge is to reason about the delay that might occur during various operations, in order to convince yourself that you will indeed satisfy the assertions. However, none of this is impossible, as you seem to imply. For instance, using timeouts can help you put an upper bound on the delay of I/O operations.
GUI assertions are different, though these are still possible. The key is that you should Design by Contract, just as the hardware folks design for testability. In other words, don't simply code the way you already do, and just throw in a few assertions; rather, you change the way you code in order to make it amenable to assertions to the greatest possible extent.
In the case of a GUI, the idea is to leave everything in data structures as late as possible, and then make the actual rendering stage trivial. Then, right up to the renderer, you can assert that the text has a certain colour. The rendering stage itself may not be amenable to assertions, but the idea is to keep that as small, as simple, and as widely-used as possible.
Assertions don't replace testing; rather, Design by Contract multiplies the tests' effectiveness.
I use Design by Contract, and program by writing the assertions first. By the time the program runs without violating any assertions, it needs very little interactive debugging.
Are we talking about the same thing here? I meant for the owner of the box to prevent it from booting from a floppy. You seem to be referring to the black-hat.
...
with only a couple of minutes of access the same attacker could boot the machine from a floppy and Game Over.
All you have to do is tell the BIOS not to boot from a floppy, and then put a password on the BIOS. The BIOS password has to be a good one though. Make it a strong random sequence of letters. Then, to remember it, put it on a sticky note on your monitor.
I understand his resentment that the "GNU" is dropped from "GNU/Linux", considering the amount of work he has done. However, as you say, "GNU" is a really dumb name; but more importantly, consider that a "Linux user group" really is a group of Linux users. That is, they are all using the Linux kernel. The name is accurate.
Ok, they are also, without exception, all using GNU. However, I'd be willing to bet that they are also all using a PCI bus, without exception, as well as RAM, TCP/IP, and a host of other technologies. Should these all be included in the user group's name?
I'd also be willing to bet that the many of topics discussed at meetings of such a user group would apply only to GNU/Linux, and not to GNU/Hurd or any other GNU system. The behaviour of the threading system, or the layout of the/proc filesystem, or any number of other topics truly are Linux-specific.
Regardless of what I think, Stallman has done more good for the world by being a hard-ass than any number of watered-down imitators would. How many of us have the gonads to spend our career fighting for something we believe in? I say, good for him.
Interesting. I have never read that book, though I did read Bill Opdyke's thesis over a decade ago. Perhaps that is where I got this idea, though I think it's not too much of a leap to imagine I thought of it independently, since I'm sure it's a conclusion many have reached. It's not exactly rocket science.
Just like any writing, the author of code has an audience in mind. Too often, this audience is the computer or compiler. However, the compiler will be able to handle just about anything you throw at it--see the obfuscated C contest for evidence of this--so to consider only the compiler will leave all other audiences (including yourself in a few months' time) in the dark.
Think of your code as a document that describes how something is done. Always imagine that it is being read by an intelligent person who doesn't already know how or why this thing is done in a certain way.
Oh, and never define words in terms of themselves. This is not helpful:
int markedTreeCount;/* How many trees have been marked */
Consider: if you saw a definition like this in a dictionary, you'd laugh out loud. Every definition should either (1) completely avoid all the words in the term being defined, or if that is too cumbersome, (2) have a reference to a document/glossary/whatever that describes those words in more detail. If your project has no such glossary, it probably needs one.
That was Isaac Asimov. I just read him quoted by Arthur C. Clarke in a book of essays called Report on Planet Three. I think the quote was that the solar system "consists of Jupiter plus debris" (taking the sun for granted, of course), though Clarke may have been paraphrasing.
Re:Development Processes be damned..
on
Bitter Java
·
· Score: 1
The good ones are language-agnostic. However, ones like the Command pattern just make up for missing language features.
Here's one error: you shouldn't compare the surface area of the Earth with the cross-sectional area of the person. It should be cross-sectional in both cases. That makes your probability too small by a factor of four.
I don't know about you, but I still feel pretty safe.
I compared icc to gcc on a recent project, and came to two conclusions that surprised me. The first is that icc can understand gcc-oriented code very well, including the asm syntax. I was pleasantly surprised at how easy it was to switch from gcc to icc.
The second conclusion is that gcc is better at massive inlining. The coding style I used on this project was to make heavy use of inline functions instead of macros. Often, to get decent code to be generated would require a few dozen functions to be inlined into each other, and the results to be attacked by -O3. Afterward, these things would produce small, fairly tight code sequences of only a dozen or so instructions.
When I switched to icc, I noticed an immediate tenfold decrease in performance. The culprit: lack of inlining. icc has a number of strict requirements for functions that are to be inlined, and most of my functions broke at least one of these rules. (For instance, ironically enough, it can't inline functions that contain asm directives.) For some of them, I couldn't tell what rule was being broken; I could only see that the function wasn't inlined. Furthermore, icc essentially ignores the "inline" directive, so there was nothing I could do about it. By contrast, gcc obeys "inline" unless that is totally impossible.
Granted, the optimizations that gcc does after inlining are less than ideal, but people are working on that, and I gather that the 3.x releases are supposed to be much better than the 2.x. Anyway, that was a price I was willing to pay in order to use inline functions instead of macros.
If it's impossible to stop curious humans from investigating this place in 10,000 years, why not leave instructions on how they might do that more safely?
Slashdot Mirror
Couldn't a ship have an artificial magnetic field that served the same purpose? I wonder how much power that would require?
I particularly like this one:
Yeah, it's a shame we have no ice here on Earth with which to test this system. Anyway, the rocket booster that lifted Armstrong and Aldrin off the moon had to "work the first time", and they still signed up.History is full of shortsighted people telling us what scientists can't possibly do, sometimes only months before they do it.
You can't use it right now because their requests have been multiplicated by 20.
During my thesis work, I had a lot of strain on the muscles and tendons on the pinky-side of my forearms. I actually had to stop all work for about four days at one point. Once I got the split keyboard, the problem disappeared. (It was also helped by using Dragon Naturally Speaking to dictate parts of my thesis.)
Going back to my old keyboard afterward, I also found that the keys are stiffer. I think that was also part of it.
Oops. That's "terabit".
What a bizarre way to report the story. The news is not that terrabit densities have been achieved; rather, that GMR will not be the technique that will get us there. Hardly news at all.
Can't stars have storms?
Ok, let's assume that these things are untestable, as you say. My point is that Design by Contract means minimizing the portions of the program that are untestable. If, even after careful consideration, your particular application has large portions that are untestable, then granted, Design by Contract won't help much for those parts. I won't argue with that.
What I argue with is your assertion (no pun intended) that such parts are of a "higher level" than those parts which are testable. I contend that they are merely of a different "kind". GUIs are full of this kind of thing. I grant that GUIs are hard to analyze with DbC, but I claim that mony other parts of a program benefit tremendously from this kind of analysis.
Your example of perceived latency is a perfect example of this, since real-time programmers do this kind of analysis for exactly this reason.
True, there are certain things that cannot be captured by executable assertions. However, I disagree that it's a matter of "level". You can have high-level, abstract assertions just as well as low-level ones. The examples you gave are just assertions of a kind that can't be checked automatically at runtime, not a level.
Having said that, I think the examples you gave are more amenable to runtime checking than you might think. Checking time constraints is trivial--all you need is a couple calls to gettimeofday--though the challenge here would be to find a systematic way to put these checks in all the right places. A more fundamental challenge is to reason about the delay that might occur during various operations, in order to convince yourself that you will indeed satisfy the assertions. However, none of this is impossible, as you seem to imply. For instance, using timeouts can help you put an upper bound on the delay of I/O operations.
GUI assertions are different, though these are still possible. The key is that you should Design by Contract, just as the hardware folks design for testability. In other words, don't simply code the way you already do, and just throw in a few assertions; rather, you change the way you code in order to make it amenable to assertions to the greatest possible extent.
In the case of a GUI, the idea is to leave everything in data structures as late as possible, and then make the actual rendering stage trivial. Then, right up to the renderer, you can assert that the text has a certain colour. The rendering stage itself may not be amenable to assertions, but the idea is to keep that as small, as simple, and as widely-used as possible.
Assertions don't replace testing; rather, Design by Contract multiplies the tests' effectiveness.
I use Design by Contract, and program by writing the assertions first. By the time the program runs without violating any assertions, it needs very little interactive debugging.
Are we talking about the same thing here? I meant for the owner of the box to prevent it from booting from a floppy. You seem to be referring to the black-hat.
:-)
Anyway, I was only kidding.
Oh, wait...
I understand his resentment that the "GNU" is dropped from "GNU/Linux", considering the amount of work he has done. However, as you say, "GNU" is a really dumb name; but more importantly, consider that a "Linux user group" really is a group of Linux users. That is, they are all using the Linux kernel. The name is accurate.
/proc filesystem, or any number of other topics truly are Linux-specific.
Ok, they are also, without exception, all using GNU. However, I'd be willing to bet that they are also all using a PCI bus, without exception, as well as RAM, TCP/IP, and a host of other technologies. Should these all be included in the user group's name?
I'd also be willing to bet that the many of topics discussed at meetings of such a user group would apply only to GNU/Linux, and not to GNU/Hurd or any other GNU system. The behaviour of the threading system, or the layout of the
Regardless of what I think, Stallman has done more good for the world by being a hard-ass than any number of watered-down imitators would. How many of us have the gonads to spend our career fighting for something we believe in? I say, good for him.
Interesting. I have never read that book, though I did read Bill Opdyke's thesis over a decade ago. Perhaps that is where I got this idea, though I think it's not too much of a leap to imagine I thought of it independently, since I'm sure it's a conclusion many have reached. It's not exactly rocket science.
Thanks for the reference!
Think of your code as a document that describes how something is done. Always imagine that it is being read by an intelligent person who doesn't already know how or why this thing is done in a certain way.
Oh, and never define words in terms of themselves. This is not helpful:
Consider: if you saw a definition like this in a dictionary, you'd laugh out loud. Every definition should either (1) completely avoid all the words in the term being defined, or if that is too cumbersome, (2) have a reference to a document/glossary/whatever that describes those words in more detail. If your project has no such glossary, it probably needs one....the US patent office will close some time before 2012, as there will be nothing left to invent.
That was Isaac Asimov. I just read him quoted by Arthur C. Clarke in a book of essays called Report on Planet Three. I think the quote was that the solar system "consists of Jupiter plus debris" (taking the sun for granted, of course), though Clarke may have been paraphrasing.
The good ones are language-agnostic. However, ones like the Command pattern just make up for missing language features.
Sounds like you need to read your parent post. He wasn't questioning Slashdot's editorial decisions.
Here's one error: you shouldn't compare the surface area of the Earth with the cross-sectional area of the person. It should be cross-sectional in both cases. That makes your probability too small by a factor of four.
I don't know about you, but I still feel pretty safe.
I compared icc to gcc on a recent project, and came to two conclusions that surprised me. The first is that icc can understand gcc-oriented code very well, including the asm syntax. I was pleasantly surprised at how easy it was to switch from gcc to icc.
The second conclusion is that gcc is better at massive inlining. The coding style I used on this project was to make heavy use of inline functions instead of macros. Often, to get decent code to be generated would require a few dozen functions to be inlined into each other, and the results to be attacked by -O3. Afterward, these things would produce small, fairly tight code sequences of only a dozen or so instructions.
When I switched to icc, I noticed an immediate tenfold decrease in performance. The culprit: lack of inlining. icc has a number of strict requirements for functions that are to be inlined, and most of my functions broke at least one of these rules. (For instance, ironically enough, it can't inline functions that contain asm directives.) For some of them, I couldn't tell what rule was being broken; I could only see that the function wasn't inlined. Furthermore, icc essentially ignores the "inline" directive, so there was nothing I could do about it. By contrast, gcc obeys "inline" unless that is totally impossible.
Granted, the optimizations that gcc does after inlining are less than ideal, but people are working on that, and I gather that the 3.x releases are supposed to be much better than the 2.x. Anyway, that was a price I was willing to pay in order to use inline functions instead of macros.
If it's impossible to stop curious humans from investigating this place in 10,000 years, why not leave instructions on how they might do that more safely?