Cory Benfield - Building Protocol Libraries The Right Way - PyCon 2016

In some cases it is very practical, even in other (non functional) programming languages. For example, link (and its accompanying talk ▶ this video ) give some really great brainfood about the way currently all kinds of network protocols are implemented, and the benefits of separating the protocol (Logic) from the actual implementation (IO). You might also want to query Google or DDG for "Free monads" if you want to implement a similar layered approach in a functional language such as Scala or Haskell.

Cory Benfield's PyCon talk last week, "Building Protocol Libraries the Right Way" ( ▶ this video ), makes the argument that a large number of problems can be traced to not cleanly separating responsibilities of actually physically doing I/O and making semantic sense of the bytes. His primary worry was about reimplementing things like HTTP many times, once for each I/O framework (why do Twisted, Tornado, and asyncio all have their own HTTP implementation?). But it seems the same problem can be seen here: every single part of the code thinks it knows how to actually retrieve data from the network, so it interacts with the network on its own, causing nested polling and similar awkwardness. If every part of the event-processing code thinks it knows how to do network I/O, you have many more opportunities for getting network I/O wrong. If xterm were designed so that e.g. xevents() had only the responsibility of fetching bytes from the X socket and do_xevents() and everything else had only the responsibility of handling bytes from an buffer, there would be no temptation to poll in two different functions. Only one function would even know that the byte source is a socket; the rest just know about the buffer.

The above sans-io page links to this PyCon 2016 talk: Cory Benfield - Building Protocol Libraries The Right Way ▶ this video