Remote/Pair-Programming in-the-cloud

[Chris Angelico]

On Sat, Aug 3, 2019 at 6:34 AM Terry Reedy <tjreedy at udel.edu> wrote:
>
> On 8/2/2019 5:10 AM, DL Neil wrote:
> > Please recommend a Python-friendly, bandwidth-respectful, (but
> > effective) system for pair-programming; where the 'pair' are
> > geographically separate.
>
> 'geographically separate' could range from in the same room to a
> continent away, as long as two people have separate keyboards and screens.

Though there may be differences between LAN-optimized tools and
internet-optimized ones.

> > [I don't mind putting a bit of money into a good service, but $free for
> > preference and F/LOSS for principle]
>
> <List of apparently unsatisfactory alternatives snipped.>
>
> IDLE is Python-friendly, free, and FOSS.  I wonder how hard it would be
> to pair programming connectivity as an extension.  A couple of questions:
>
> 1. Do the systems you have considered operate as an editor + satellite
> terminal or as synchronized peer editors.
>
> 2. Do two systems connect directly peer-to-peer or through a server?
>

Not the OP, but weighing in from personal experience: I've often pair
programmed using just a video call service (with screen share). The
biggest downside is that it has to share the full image of the screen,
which means it has to aggressively compress the video in order to
handle home-grade internet connections. (OTOH, that does mean that
it's IDE-independent, and can showcase literally anything.) If IDLE
were to grow a peer-to-peer pair programming feature, I could imagine
it being a text-only connection with a single master and any number of
slaves, where the slaves are showing a replica of the master's screen.
IMO the slaves should not need any way to directly manipulate
anything, though it may be of value to be able to highlight a block of
text and have the master see that highlight (independently of the
master's own text selection). Having everyone able to edit
simultaneously creates technological problems, and then a social
problem (when you start trampling over each other's code by mistake),
and the solution to the social problem usually amounts to a semaphore
system "okay, you go ahead and take over"; baking that semaphore into
the technology (by having only a single master) would keep things way
simpler.

ChrisA