3 ms·

The discussion centers largely around the trade-off between program efficiency and developer productivity but one thing I thought that's missing that's also inc

The discussion centers largely around the trade-off between program efficiency and developer productivity but one thing I thought that's missing that's also incredibly important is simply safety. Today a lot of applications are concurrent, networked, distributed and built in ways where high level or performance impacting features make sense to make sure your program remains in a valid state. Casey seems to take so much of his advice from his experience on game engines, which are an incredibly forgiving domain in many ways. You can have some bugs, you can drop some things over the network, it doesn't matter much. But you can't really do that in many other applications. If you had a big codebase for an application that is safety critical, going at it with his style of low-level programming you might make some very costly mistakes really quickly.

kamikaz1k 4y ago
Casey isn’t arguing with hypotheticals. Right in the discussion they explore a perf bug in the GitHub UI. So don’t strawman by drawing borders around sensitive domains. Because clean code ideas are still producing buggy code. (I am making an assumption that GitHub UI uses clean code ideas, but I feel comfortable doing that.)
- Barrin92 4y ago
  No need to make assumptions given that they dug into that issue and the problem was algorithmic. As Bob points out that's orthogonal to clean code ideas. If you chose the wrong datastructure or algorithm and have quadratic complexity all the micro-optimizations in the world aren't going to help you. The only strawman honestly is to pick someone at github writing shoddy code and then using that to argue against system architecture? It's pretty obvious that a text editor lagging on a paragraph of text isn't the consequnce of having wrapped something in a function. If you've written code slower than a human you don't have clean code, you just have bad code.
oreally 4y ago
I wouldn't go down that line. There is code that makes you -think- it's safer but all it really does is add more needless complexity. It's one of those things where the 'safety' result hasn't really been given a good measurement.

kamikaz1k 4y ago

Casey isn’t arguing with hypotheticals. Right in the discussion they explore a perf bug in the GitHub UI. So don’t strawman by drawing borders around sensitive domains. Because clean code ideas are still producing buggy code. (I am making an assumption that GitHub UI uses clean code ideas, but I feel comfortable doing that.)

Barrin92 4y ago
No need to make assumptions given that they dug into that issue and the problem was algorithmic. As Bob points out that's orthogonal to clean code ideas. If you chose the wrong datastructure or algorithm and have quadratic complexity all the micro-optimizations in the world aren't going to help you. The only strawman honestly is to pick someone at github writing shoddy code and then using that to argue against system architecture? It's pretty obvious that a text editor lagging on a paragraph of text isn't the consequnce of having wrapped something in a function. If you've written code slower than a human you don't have clean code, you just have bad code.

oreally 4y ago

I wouldn't go down that line. There is code that makes you -think- it's safer but all it really does is add more needless complexity. It's one of those things where the 'safety' result hasn't really been given a good measurement.