Programming is math with more steps. The world’s best mathematician published a paper called Math 2.0 where he states that AI models are better at solving math problems than humans, however they suck at explaining how they got there, so that’s where he states humans should focus on… the path, not the destination.
I think the same applies to programming. But what do I know, I’m neither.
I’d say “explaining how they got there” is math. Formal science in general is like, explain a problem so well that your worst enemy can’t help but agree with you. In programming, you have two such worst enemies: first the computer, and then the maintainer. Problem solving isn’t easy, but once you explain your problem well, you already have a big part of the solution. The definitions and the tests. Your solution can’t be reliable enough for others to build on top of it unless you have a good explanation - every part of the solution has to be useful on its own. In the statement that someone or something is better at solving problems but is bad at explaining the solutions, I see something deeply unscientific.
If somebody sends a working patch but the explanation is insufficient for the maintainers to understand it, it’s simply a bad patch, and the process of working with its programmer to build common knowledge about the problem and have the programmer refactor the patch until both they and every maintainer (including future generations of maintainers) understand enough of it, is how projects stay alive. I’m not convinced using LLMs as a lossy and noisy substitute for both the refactoring tools and the knowledge-building process is a good idea.
Programming is math with more steps. The world’s best mathematician published a paper called Math 2.0 where he states that AI models are better at solving math problems than humans, however they suck at explaining how they got there, so that’s where he states humans should focus on… the path, not the destination.
I think the same applies to programming. But what do I know, I’m neither.
CPUs do math. 99% of programming has nothing to do with math.
I’d say “explaining how they got there” is math. Formal science in general is like, explain a problem so well that your worst enemy can’t help but agree with you. In programming, you have two such worst enemies: first the computer, and then the maintainer. Problem solving isn’t easy, but once you explain your problem well, you already have a big part of the solution. The definitions and the tests. Your solution can’t be reliable enough for others to build on top of it unless you have a good explanation - every part of the solution has to be useful on its own. In the statement that someone or something is better at solving problems but is bad at explaining the solutions, I see something deeply unscientific.
If somebody sends a working patch but the explanation is insufficient for the maintainers to understand it, it’s simply a bad patch, and the process of working with its programmer to build common knowledge about the problem and have the programmer refactor the patch until both they and every maintainer (including future generations of maintainers) understand enough of it, is how projects stay alive. I’m not convinced using LLMs as a lossy and noisy substitute for both the refactoring tools and the knowledge-building process is a good idea.