I don't think you're wrong exactly, but I just want to try and give you a different way of framing your disagreement.

A man walks to a house with a ladder. He explains that ladders are climbing devices. He tries to set it up against the house, killing plants that he sets it on. The ladder falls over.

One person watches this happen and correctly explains that the ladder is a climbing device and says many very true things about the intentions and proves the genuine thoughtfulness of the ladder users approach. He isn't wrong.

Another person looks at everything from a different perspective. They are a time traveler and they experience the world in reverse chronological order. They say the ladder isn't a climbing device - it is a thing which falls on ground. They say it is a flower killing device. They claim that when the person explains that the ladder was for climbing, they were wrong, because it isn't. They fundamentally disagree about what the ladder is, because they viewed the ladder from a different perspective. He isn't wrong.

They start arguing about what the ladder is. The first person is trying to argue that the ladder isn't a falling device, because it isn't defined to be so. The other person is arguing - this is very critical by the way - not that it is a falling device, but that the way it got used meant it was one and that this disagrees with the statements about what the ladders purpose was. Now, because they aren't noticing this distinction, they argue and they try to prove that the ladder isn't what the other person is claiming it is. Perhaps they think they are winning the argument by pointing out the contradiction, but pointing out the contradiction is agreement that the contradiction exists.

You are using a programmatic understanding of what is happening. You are having to proceed forward from statements in order to get meaning. But there are different paradigms in programming type resolution which might help you understand why you get such sharp disagreement. In programmatic terms you can actually have this backward flow too. b [unknown]; foo(int); foo(b) -> b [int] is implied. You can propagate the type backwards from the function call.

Critically, this is extremely common in math. Mathematics has identities. The relationships between operations flow along those identities. When you let the identities flow backwards, the ladder you two are discussing stops being a ladder. When they make the choice to use a known algorithm, getting the expected value for a subgame under imperfect information, we know the relationships which flow backward from a correct usage. We know what was 'supposed to' be there. They had an incorrect usage. Their ladder wasn't intended to be for falling. But we're experiencing the world in a backwards direction. So we don't know that yet, like you know it. We're treating it as it was used, not as it ought to have been used - flowing what it is backwards from what they mean in the equations, not forward from how they are defined.

So he started trying to explain his thinking to you by moving backward and you noticed that he was saying the ladder was a falling over device, when the ladder maker told you it was something else. And you are right. He isn't wrong so much as his understanding of what the terms are was decided by a different process. And he agrees that you are right that the terms are defined differently!

You aren't really disagreeing about as much as you think you are, because you and him both already agree that the ladder maker said the ladder was for climbing and he said the ladder was for falling over. When you find the contradictions, well, I'm not sure you are actually proving him wrong so much as you are agreeing with each other that a contradiction exists.