On 1 July 2015 at 06:56, Nick Coghlan <ncoghlan@gmail.com> wrote:
For folks that primarily deal with algorithmic problems where inputs are converted to outputs, the event driven model addresses a kind of problem that *they don't have*, so it can seem entirely pointless. However, there really are significant categories of problems (such as network service development) where the event driven model is a genuinely superior design tool. Like array oriented programming (and even object-oriented and functional programming), the benefits can unfortunately be hard to explain to folks that haven't personally experienced the problems these tools address, so folks end up having to take it on faith that we're applying the "Complex is better than complicated" line from the Zen of Python when introducing new modelling techniques into the core language.
Hmm, I see what you're getting at here, but my "event driven model" background is with GUI event loops, not with event driven IO. The async/await approach still gives me problems, because I can't map the details of the approach onto the problem domain I'm familiar with. What I can't quite work out is whether that's simply because asyncio is fundamentally designed around the IO problem (the module name suggests that might be the case, but a lot of the module content around tasks, etc, doesn't seem to be), and so doesn't offer any sort of mental model for understanding how GUI event loop code based on async/await would work, or if it's because the async/await design genuinely doesn't map well onto GUI event loop problems. I've been poking in the background at trying to decouple the "IO" aspects of asyncio from the "general" ones, but honestly, I'm not getting very far yet. I think what I need to do is to work out how to write a GUI event loop that drives async/await style coroutines, and see if that helps me understand the model better. But there aren't many examples of event loops around to work from (the asyncio one is pretty complex, and it's hard to know how much of that complexity is needed, and how much is because it was developed before async/await were available). So while I agree that if you don't need an event driven model, it can seem like pointless complexity, I *also* think that the pure callback approach to event driven code is what feels "obvious" to most people. It's maybe not the easiest model to code with, but it is the easiest one to think about - and mentally making the link between callbacks and async/await isn't straightforward. So even though people can understand event-driven problems, they can't, without experience, see how async/await *addresses* that problem. Paul