4 ms·

> Automation is what the computer is good at, it can have that job. Pre-commit hook is automation. It formats the code and gives you linting notes the moment y

> Automation is what the computer is good at, it can have that job. Pre-commit hook is automation. It formats the code and gives you linting notes the moment you write "git commit". > Like, why would I want to spend more mental bandwidth on tracking down whether every new goes with every delete than strictly necessary? It's not more mental bandwidth for me. Because I write the new, and directly delete at the point I need to, then I never think about it again. If I botch something, valgrind will tell me, even pinpointing it with line number. > ...other things that will do just fine with a smart pointer. If that works for you, use it. I have no objections.

dale_glass 3y ago
> Pre-commit hook is automation. It formats the code and gives you linting notes the moment you write "git commit". So isn't that a tool that enforces something upon the programmer? > If I botch something, valgrind will tell me, even pinpointing it with line number. What is the benefit of needing valgrind? Isn't it even better to have the task automated away so that the problem doesn't even come up?
- bayindirh 3y ago
  > So isn't that a tool that enforces something upon the programmer? It's a tool I voluntarily add to my workflow, which works the way I want, when I want, according to project needs. It's not a limitation put upon me by the language/compiler/whatnot. > What is the benefit of needing valgrind? Isn't it even better to have the task automated away so that the problem doesn't even come up? In most cases, performance (think of HPC levels of performance). If I don't need that kind of performance, I can just use the stack or smart pointers. If we're talking about moving to other programming languages, I'd rather not.
  - dale_glass 3y ago
    > It's a tool I voluntarily add to my workflow, which works the way I want, when I want, according to project needs. It's not a limitation put upon me by the language/compiler/whatnot. I spent a lot of time maintaining a lot of Perl code. While it was generally very well written, it also made me a big fan of strict, demanding compilers. Perl is quick to write, but can have very high debugging costs since it'll let you get away with a lot that it shouldn't like having a function called with arguments but that completely forgets to retrieve them. Based on my experience, IMO any class of error that can be eliminated, should be. So my modern approach is -Wall, -Werrors, -Wextra, and anything else that can be had to that effect, all the time.
Joker_vD 3y ago
> It's not more mental bandwidth for me Most people are not you. Which, I guess, also answers your original question of "Why many programmers [do the things not they way I would do]?". Incidentally, this is also the root of all the complexity in managing and coordinating people.

dale_glass 3y ago

> Pre-commit hook is automation. It formats the code and gives you linting notes the moment you write "git commit". So isn't that a tool that enforces something upon the programmer? > If I botch something, valgrind will tell me, even pinpointing it with line number. What is the benefit of needing valgrind? Isn't it even better to have the task automated away so that the problem doesn't even come up?

bayindirh 3y ago
> So isn't that a tool that enforces something upon the programmer? It's a tool I voluntarily add to my workflow, which works the way I want, when I want, according to project needs. It's not a limitation put upon me by the language/compiler/whatnot. > What is the benefit of needing valgrind? Isn't it even better to have the task automated away so that the problem doesn't even come up? In most cases, performance (think of HPC levels of performance). If I don't need that kind of performance, I can just use the stack or smart pointers. If we're talking about moving to other programming languages, I'd rather not.
- dale_glass 3y ago
  > It's a tool I voluntarily add to my workflow, which works the way I want, when I want, according to project needs. It's not a limitation put upon me by the language/compiler/whatnot. I spent a lot of time maintaining a lot of Perl code. While it was generally very well written, it also made me a big fan of strict, demanding compilers. Perl is quick to write, but can have very high debugging costs since it'll let you get away with a lot that it shouldn't like having a function called with arguments but that completely forgets to retrieve them. Based on my experience, IMO any class of error that can be eliminated, should be. So my modern approach is -Wall, -Werrors, -Wextra, and anything else that can be had to that effect, all the time.

Joker_vD 3y ago

> It's not more mental bandwidth for me Most people are not you. Which, I guess, also answers your original question of "Why many programmers [do the things not they way I would do]?". Incidentally, this is also the root of all the complexity in managing and coordinating people.