4 ms·

"Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" — Ker

"Debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?" — Kernighan, Brian. The Elements of Programming Style (2e). McGraw-Hill, 1978.

userbinator 2y ago
By becoming even more clever: https://www.linusakesson.net/programming/kernighans-lever/index.php https://www.linusakesson.net/programming/kernighans-lever/in...
- IshKebab 2y ago
  Very unconvincing. If you become cleverer you can just write even more clever code and still not be able to debug it.
  - chmod775 2y ago
    Great!
- nine_k 2y ago
  It's a nice interpretation. I prefer a different approach: "smart is good; clever isn't smart". If you have to express something in a clever, that is, highly contrived but actually working way, it means that you lack the right way to express it, and maybe your mental model of the problem is not that good. The theory of epicycles is clever; Kepler's laws are smart.
- darkwater 2y ago
  This can probably true for some people, but still will not work for many other. One probable outcome of a frustrated debugging session is "let's rewrite/refactor it to make it easier to debug next time", and not self-enlightenment.
chii 2y ago
> how will you ever debug it? By being so smart that your program has obviously zero bugs in it!
- nosianu 2y ago
  This view is too static. That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time. Also, it is way too expensive to try to cover every single conceivable possibility, so we deliberately leave holes. For non-trivial things we often prefer to wait to see what problems actually come up during use, and then fix exactly those, but not the many more problems that could come up but are too unlikely and/or too costly to guard against. In a living environment the software lives too, and keeps changing and adapting.
  - chii 2y ago
    you might've missed the quip, since this whole thread is about a quote, which i'm countering with an alternative quote from Hoare > There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.
  - boomlinde 2y ago
    > That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time. It sounds to me like you are describing a change of problem, not bugs in the solution. If in the future someone redefines the concept of a Sudoku puzzle such that this solution is no longer applicable, or tries to use the solution verbatim in a language which is different from K and therefore yields different results, it's not a bug in the original code that it's not a solution to that new problem. It's still a solution to the same problem it was always a solution to. I can see what you mean in a practical sense, but also consider (practically) that a lot of problems can be broken down into smaller, well-defined problems which are themselves practically immutable. You can throw the solutions to such problems out when you no longer need them, and come up with solutions to whatever new problems replaced the original problems.

userbinator 2y ago

By becoming even more clever: https://www.linusakesson.net/programming/kernighans-lever/index.php https://www.linusakesson.net/programming/kernighans-lever/in...

IshKebab 2y ago
Very unconvincing. If you become cleverer you can just write even more clever code and still not be able to debug it.
- chmod775 2y ago
  Great!
nine_k 2y ago
It's a nice interpretation. I prefer a different approach: "smart is good; clever isn't smart". If you have to express something in a clever, that is, highly contrived but actually working way, it means that you lack the right way to express it, and maybe your mental model of the problem is not that good. The theory of epicycles is clever; Kepler's laws are smart.
darkwater 2y ago
This can probably true for some people, but still will not work for many other. One probable outcome of a frustrated debugging session is "let's rewrite/refactor it to make it easier to debug next time", and not self-enlightenment.

chii 2y ago

> how will you ever debug it? By being so smart that your program has obviously zero bugs in it!

nosianu 2y ago
This view is too static. That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time. Also, it is way too expensive to try to cover every single conceivable possibility, so we deliberately leave holes. For non-trivial things we often prefer to wait to see what problems actually come up during use, and then fix exactly those, but not the many more problems that could come up but are too unlikely and/or too costly to guard against. In a living environment the software lives too, and keeps changing and adapting.
- chii 2y ago
  you might've missed the quip, since this whole thread is about a quote, which i'm countering with an alternative quote from Hoare > There are two methods in software design. One is to make the program so simple, there are obviously no errors. The other is to make it so complicated, there are no obvious errors.
- boomlinde 2y ago
  > That is not possible, because the environment can (and at some point always will) change which wasn't planned for due to a lack of working crystal balls. Data, user behavior, the network, the system(s) the software runs on can all change over time. It sounds to me like you are describing a change of problem, not bugs in the solution. If in the future someone redefines the concept of a Sudoku puzzle such that this solution is no longer applicable, or tries to use the solution verbatim in a language which is different from K and therefore yields different results, it's not a bug in the original code that it's not a solution to that new problem. It's still a solution to the same problem it was always a solution to. I can see what you mean in a practical sense, but also consider (practically) that a lot of problems can be broken down into smaller, well-defined problems which are themselves practically immutable. You can throw the solutions to such problems out when you no longer need them, and come up with solutions to whatever new problems replaced the original problems.