In my limited experience, the 'pairness' part of pair programming , is best done in silence. The discussion / planning happens up front, the keyboard person does the implementation and the second person doesn't 'backseat drive', but thinks about test cases (writes it down), thinks about weaknesses (writes it down) and writes documentation while the code is written.

All of these are reviewed before commit.

The 'interrupting' while coding is the shitty part (I agree with you), not having someone working with you.

You might be working on much smaller and well constrained problems, pair programming works well when the problem is unconstrained with many complex and interconnected layees