3 ms·

The diff algorithms seem like a hacky collection of heuristics; the type that's begging to be replaced by a machine learning system. Something that understands

The diff algorithms seem like a hacky collection of heuristics; the type that's begging to be replaced by a machine learning system. Something that understands the content could do much better than either of these algorithms. I'm not sure what the training data would look like though.

voqv 7y ago
Even if a state of the art machine learning system is going to work 99.999% of the time - with millions of diffs run daily - that's still too many failures. So basically with diff we had 1 problem, with ML-diff we'll have two.
- modeless 7y ago
  Just because a system uses ML doesn't mean it has to be less reliable, especially when it replaces a heuristic that's already unreliable. The correctness of the patch can be easily verified, and the reasonableness of the patch can also be ensured with some heuristics that would be much easier to make than a whole diff algorithm. There seems to be a serious bias against ML in systems programming that is unwarranted. There are plenty of problems using bad heuristics today that could be improved with ML in a way that doesn't reduce reliability. Scheduling, compiler optimization, stuff like that.
Hendrikto 7y ago
Some "smart" AI trying to guess my intentions and reason about the code is the last thing I want. This will inevitably go wrong, and I will be left with a nonsensical patch, which may not be immediately obvious, because the AI though that it figured out what I wanted. I‘d much rather encounter an error and solve it myself. Linus got it right: Keep the diffing very simple and obvious, then refer to a human if there is ambiguity.
- modeless 7y ago
  > I will be left with a nonsensical patch This is the current state of things, though. Heuristic diff algorithms generate nonsensical patches all the time. They may be technically correct but completely obscure the meaning of the diff. The simplicity of the diff algorithm does not help me understand a bad diff. And these diff algorithms are already not that simple. A machine learning approach could still guarantee technical correctness of the diff, but give patches that make sense more often.

voqv 7y ago

Even if a state of the art machine learning system is going to work 99.999% of the time - with millions of diffs run daily - that's still too many failures. So basically with diff we had 1 problem, with ML-diff we'll have two.

modeless 7y ago
Just because a system uses ML doesn't mean it has to be less reliable, especially when it replaces a heuristic that's already unreliable. The correctness of the patch can be easily verified, and the reasonableness of the patch can also be ensured with some heuristics that would be much easier to make than a whole diff algorithm. There seems to be a serious bias against ML in systems programming that is unwarranted. There are plenty of problems using bad heuristics today that could be improved with ML in a way that doesn't reduce reliability. Scheduling, compiler optimization, stuff like that.

Hendrikto 7y ago

Some "smart" AI trying to guess my intentions and reason about the code is the last thing I want. This will inevitably go wrong, and I will be left with a nonsensical patch, which may not be immediately obvious, because the AI though that it figured out what I wanted. I‘d much rather encounter an error and solve it myself. Linus got it right: Keep the diffing very simple and obvious, then refer to a human if there is ambiguity.

modeless 7y ago
> I will be left with a nonsensical patch This is the current state of things, though. Heuristic diff algorithms generate nonsensical patches all the time. They may be technically correct but completely obscure the meaning of the diff. The simplicity of the diff algorithm does not help me understand a bad diff. And these diff algorithms are already not that simple. A machine learning approach could still guarantee technical correctness of the diff, but give patches that make sense more often.