4 ms·

One of the best programmers I have known was a CS theory guy. We were working on these tightly-coupled multiprocessor machine which was quite unstable, and wou

by ajays 14y ago

One of the best programmers I have known was a CS theory guy. We were working on these tightly-coupled multiprocessor machine which was quite unstable, and would hard lockup if something went wrong in the program (requiring a walk over to the machine room, hitting the reset button, etc.). We would start hacking at our assignments quickly, and make innumerable trips to the machine room. This guy, on the other hand, would just sit and stare into space for a while; then jot down the entire program on paper. Then he would enter it into the editor, fix a couple of typos that the compiler caught, and run it. His program always worked on the first or second attempt. Funny part? he hated to program, and was a theoretician.

myle 14y ago
The best advice I had (from a theoretician) was that I should not try to randomly fix my code but I should understand why it does not work. How to do that? Can you prove (in the mathematical sense) that it always does what you want?
- grn 14y ago
  Giving a full proof that takes language semantics into account is very difficult. I think it isn't a practical way to verify programmes but maybe it'll be in future.
  - flogic 14y ago
    I don' think the advice is to do a proof, but rather to design and think about it in such a way that you could given enough time.
    - dllthomas 14y ago
      One of my CS theory profs had the policy, "A proof is anything that convinces me you could write a proof."
  - wikwocket 14y ago
    The advice isn't to mathematically prove anything, which as you mentioned is hard and may even be unsolvable. The advice is to look at the issue as you would a mathematical problem, critically and analytically. Don't use shotgun debugging or quick fixes, but instead try to understand the code thoroughly, what its goal is and how it accomplishes it. Instead of testing with random data, mentally walk through all the possibilities and branches. This is akin to making a mental model of what you are trying to do, and then verifying that the model is correct, and that your code matches the model.

by ajays 14y ago

myle 14y ago

The best advice I had (from a theoretician) was that I should not try to randomly fix my code but I should understand why it does not work. How to do that? Can you prove (in the mathematical sense) that it always does what you want?

grn 14y ago
Giving a full proof that takes language semantics into account is very difficult. I think it isn't a practical way to verify programmes but maybe it'll be in future.
- flogic 14y ago
  I don' think the advice is to do a proof, but rather to design and think about it in such a way that you could given enough time.
  - dllthomas 14y ago
    One of my CS theory profs had the policy, "A proof is anything that convinces me you could write a proof."
- wikwocket 14y ago
  The advice isn't to mathematically prove anything, which as you mentioned is hard and may even be unsolvable. The advice is to look at the issue as you would a mathematical problem, critically and analytically. Don't use shotgun debugging or quick fixes, but instead try to understand the code thoroughly, what its goal is and how it accomplishes it. Instead of testing with random data, mentally walk through all the possibilities and branches. This is akin to making a mental model of what you are trying to do, and then verifying that the model is correct, and that your code matches the model.