3 ms·

the entity needs to be able to solve your problem. People have fixed software bugs with zero knowledge of what the code is doing and no knowledge of the progra

the entity needs to be able to solve your problem. People have fixed software bugs with zero knowledge of what the code is doing and no knowledge of the programming language at hand, purely by statistical pattern matching. Solving the problem with no understanding of it beyond the idea that whatever it was, the right answer was probably something that kind of matched the kind of patterns found in things they'd seen before. So what does it mean, "to be able to solve your problem"?

qarl 21d ago
> People have fixed software bugs with zero knowledge of what the code is doing and no knowledge of the programming language at hand, purely by statistical pattern matching. Is that even true? Beyond an extremely simple example?
- EliRivers 16d ago
  Yes, it is. Beyond simple examples, I've fixed segfaults by identifying the assembly where it happens, tracing that back to the lump of source where it happens, guessed which piece is accessing memory and deducing from surrounding code how it was meant to be protected against. In that case, the pattern matching was against every segfault I've ever fixed, which is a lot, and traipsing through assembly, which is also a lot. Lots of experience in tracing back to source code. So did that. Matching patterns. Didn't understand the language, don't know what it's trying to do, but I know what memory access is (because I've seen the pattern "access memory" a lot in my life) and this piece of code must be matching that pattern; whatever this code is, it must be touching memory. Now scroll up and down to look for similar code in other places, that I also cannot read but I can see when things look the same; match the pattern of pieces that work with this piece that doesn't. Oh, this looks the same but it has this extra piece; part of the pattern matches, part does not. Matching patterns. What if I copy it, paste into the bad place, apply a single change to match the symbols I see in the bad place, and see what happens... fixed. It's not something I do every day and it's not nearly as good as actually understanding it, but the problem was solved and I did not know what the code was trying to do or how to read it. All the above aside, surely it must be possible, because we have machines that do exactly that. They're made of statistics and patterns and they're doing it. Right in front of us. There is nothing else in there and they're doing it right now.
qarl 20d ago
Yeah... I think you just made that up.
- EliRivers 16d ago
  Done it myself. The fact that you have a long history in the business makes me think we're either talking about wildly different things and this is a mismatch of language and context, or you're deliberately trolling me. It can take a good few years to get to the point that one no longer has to think and understand in a concrete language. There are whole sets of common mistakes that get made across languages and tools. I've fixed errors in Pascal, which I do not read, because the person writing it was clearly thinking in C and made a mistake in their C thinking which they then translated into Pascal. Luckily for me they used common C naming and layout for that piece so I matched the whole thing up to C patterns. Copy paste errors are easier ones to see; cases where replicated code is clearly meant to be different in a few keys places or values, and whoever did it just missed one. Array errors are common, no matter how the array notation works in language du jour. The list goes on. All that aside, we know it's possible because there are machines doing it right now. They are made of stats and patterns. There is nothing else in there.

qarl 21d ago

> People have fixed software bugs with zero knowledge of what the code is doing and no knowledge of the programming language at hand, purely by statistical pattern matching. Is that even true? Beyond an extremely simple example?

EliRivers 16d ago
Yes, it is. Beyond simple examples, I've fixed segfaults by identifying the assembly where it happens, tracing that back to the lump of source where it happens, guessed which piece is accessing memory and deducing from surrounding code how it was meant to be protected against. In that case, the pattern matching was against every segfault I've ever fixed, which is a lot, and traipsing through assembly, which is also a lot. Lots of experience in tracing back to source code. So did that. Matching patterns. Didn't understand the language, don't know what it's trying to do, but I know what memory access is (because I've seen the pattern "access memory" a lot in my life) and this piece of code must be matching that pattern; whatever this code is, it must be touching memory. Now scroll up and down to look for similar code in other places, that I also cannot read but I can see when things look the same; match the pattern of pieces that work with this piece that doesn't. Oh, this looks the same but it has this extra piece; part of the pattern matches, part does not. Matching patterns. What if I copy it, paste into the bad place, apply a single change to match the symbols I see in the bad place, and see what happens... fixed. It's not something I do every day and it's not nearly as good as actually understanding it, but the problem was solved and I did not know what the code was trying to do or how to read it. All the above aside, surely it must be possible, because we have machines that do exactly that. They're made of statistics and patterns and they're doing it. Right in front of us. There is nothing else in there and they're doing it right now.

qarl 20d ago

Yeah... I think you just made that up.

EliRivers 16d ago
Done it myself. The fact that you have a long history in the business makes me think we're either talking about wildly different things and this is a mismatch of language and context, or you're deliberately trolling me. It can take a good few years to get to the point that one no longer has to think and understand in a concrete language. There are whole sets of common mistakes that get made across languages and tools. I've fixed errors in Pascal, which I do not read, because the person writing it was clearly thinking in C and made a mistake in their C thinking which they then translated into Pascal. Luckily for me they used common C naming and layout for that piece so I matched the whole thing up to C patterns. Copy paste errors are easier ones to see; cases where replicated code is clearly meant to be different in a few keys places or values, and whoever did it just missed one. Array errors are common, no matter how the array notation works in language du jour. The list goes on. All that aside, we know it's possible because there are machines doing it right now. They are made of stats and patterns. There is nothing else in there.