6 ms·

I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill

I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill not know?

notretarded 6y ago
Probably more than you'd think, although they'd not be so dumb as to vocalise it as one's career depends entirely on one's percieved capabilities.
- myth2018 6y ago
  Actually at least Carmack did. Why would vocalizing that be dumb? It's actually not a matter of perceived capabilities, but of concrete results, and, in the case of those guys, there aren't plenty of room for discussion on this regard..
- enriquto 6y ago
  > one's career depends entirely on one's percieved capabilities This may be true in many fields, but not in science and engineering.
martindbp 6y ago
> What does John Carmack not know? Vim or Emacs IIRC.
myth2018 6y ago
> What does John Carmack not know? As of 2014, relational databases. https://mobile.twitter.com/ID_AA_Carmack/status/457916010234777600 https://mobile.twitter.com/ID_AA_Carmack/status/457916010234...
watermelon59 6y ago
Not exactly that, but when reading Coders at Work I was surprised to learn that a lot of big names in our field use "printf debugging" and don't like actual debugging tools. Made me feel less bad about it :)
- enriquto 6y ago
  It's not only a matter of usage. Many good programmers will argue that "actual debugging tools" are mostly useless and that logging the execution of your program is a more productive use of your time. In some sense, time spent inside the debugger is lost forever. On the other hand, the time spend writing good logging code is really worth, and will be especially helpful to detect future bugs that you have not yet written. I'm not a good programmer, but I can say very proudly that I've never used any debugger (except for assembly language, where the debugger is more like an interactive shell).
- Drdrdrq 6y ago
  Not a big name myself, but I'm always surprised that this surprises people. I mostly use print statements, simply because a) every environment has them, b) there is much less (none) fiddling involved to set them up, and c) because debugging is rarely needed anyway, assuming you are working on your own / your team's code (and that you are half good). I think the last time I have used a debugger was on what I think would be a definition of spaghetti code - not proud of it, but I did learn not to do that. :)
  - Tainnor 6y ago
    This is interesting, I use the debugger a lot, in whatever language. I've debugged with CLI interfaces and I've used IDEs. I don't want to claim this is superior to printf debugging, or whatever other technique. I just like seeing the code executing, and debugging some weird error can sometimes be an almost relaxing activity, as you just step through the code one by one and try to keep track of what's happening without needing to think more than 2 or 3 steps ahead. That said, I'm also the guy who will happily put breakpoints into internal framework code (e.g. Spring Boot) so that I can understand why the framework doesn't do what it's supposed to do. Usually, I find the answer, although maybe in some cases it would have been more economical to use a workaround instead, but that would leave me dissatisfied...
    - hamburglar 6y ago
      I rarely use the debugger in highly async systems (e.g. node) because it's just a mess, but in C/C++/Go/Java where there actually are good debuggers and you tend to have chunks (e.g. entire functions) of synchronous code, I find it very, very helpful to step line-by-line through most nontrivial code at least once for any major code path. A long time ago, I had a sort-of mentor who, whenever he looked at new code, asked the author "have you single-stepped through it yet?" so I did it to humor him, but the number of times I caught errors was eye-opening, so to this day I still like to do it.
renewiltord 6y ago
Following JC, as of one year ago, he didn't know much about AI, NNs and DL. Last week, he achieved familiarity. I believe him.

I'd love to see lists like this from more high-profile programmers. What does John Carmack not know? What does Dan Bernstein not know? What does Bryan Cantrill not know?

notretarded 6y ago

Probably more than you'd think, although they'd not be so dumb as to vocalise it as one's career depends entirely on one's percieved capabilities.

myth2018 6y ago
Actually at least Carmack did. Why would vocalizing that be dumb? It's actually not a matter of perceived capabilities, but of concrete results, and, in the case of those guys, there aren't plenty of room for discussion on this regard..
enriquto 6y ago
> one's career depends entirely on one's percieved capabilities This may be true in many fields, but not in science and engineering.

martindbp 6y ago

> What does John Carmack not know? Vim or Emacs IIRC.

myth2018 6y ago

> What does John Carmack not know? As of 2014, relational databases. https://mobile.twitter.com/ID_AA_Carmack/status/457916010234777600 https://mobile.twitter.com/ID_AA_Carmack/status/457916010234...

watermelon59 6y ago

Not exactly that, but when reading Coders at Work I was surprised to learn that a lot of big names in our field use "printf debugging" and don't like actual debugging tools. Made me feel less bad about it :)

enriquto 6y ago
It's not only a matter of usage. Many good programmers will argue that "actual debugging tools" are mostly useless and that logging the execution of your program is a more productive use of your time. In some sense, time spent inside the debugger is lost forever. On the other hand, the time spend writing good logging code is really worth, and will be especially helpful to detect future bugs that you have not yet written. I'm not a good programmer, but I can say very proudly that I've never used any debugger (except for assembly language, where the debugger is more like an interactive shell).
Drdrdrq 6y ago
Not a big name myself, but I'm always surprised that this surprises people. I mostly use print statements, simply because a) every environment has them, b) there is much less (none) fiddling involved to set them up, and c) because debugging is rarely needed anyway, assuming you are working on your own / your team's code (and that you are half good). I think the last time I have used a debugger was on what I think would be a definition of spaghetti code - not proud of it, but I did learn not to do that. :)
- Tainnor 6y ago
  This is interesting, I use the debugger a lot, in whatever language. I've debugged with CLI interfaces and I've used IDEs. I don't want to claim this is superior to printf debugging, or whatever other technique. I just like seeing the code executing, and debugging some weird error can sometimes be an almost relaxing activity, as you just step through the code one by one and try to keep track of what's happening without needing to think more than 2 or 3 steps ahead. That said, I'm also the guy who will happily put breakpoints into internal framework code (e.g. Spring Boot) so that I can understand why the framework doesn't do what it's supposed to do. Usually, I find the answer, although maybe in some cases it would have been more economical to use a workaround instead, but that would leave me dissatisfied...
  - hamburglar 6y ago
    I rarely use the debugger in highly async systems (e.g. node) because it's just a mess, but in C/C++/Go/Java where there actually are good debuggers and you tend to have chunks (e.g. entire functions) of synchronous code, I find it very, very helpful to step line-by-line through most nontrivial code at least once for any major code path. A long time ago, I had a sort-of mentor who, whenever he looked at new code, asked the author "have you single-stepped through it yet?" so I did it to humor him, but the number of times I caught errors was eye-opening, so to this day I still like to do it.

renewiltord 6y ago

Following JC, as of one year ago, he didn't know much about AI, NNs and DL. Last week, he achieved familiarity. I believe him.