On Wed, Jun 4, 2014 at 3:10 PM, Burak Arslan <burak.ars...@arskom.com.tr> wrote: > Ah ok. Well, a couple of years of writing async code, my not-so-objective > opinion about it is that it forces you to split your code into functions, > just like Python forces you to indent your code properly. This in turn > generally helps the quality of the codebase.
That's entirely possible, but it depends hugely on your library/framework, then - see earlier comments in this thread about Node.js and the nightmare of callbacks. One thing I'm seeing, though, the more different styles of programming I work with, is that since it's possible to write good code in pretty much anything (even PHP, and my last boss used that as a counter-argument to "PHP sucks"), and since a good programmer will write good code in anything, neither of these is really a good argument in favour of (or against) a feature/library/framework/style. Python forces you to indent your code. Fine! But a good programmer will already indent, and a sloppy programmer isn't forced to be consistent. (At worst, you just add "if True:" every time you unexpectedly indent.) To judge the quality of a framework based on code style, you need to look at a *bad* programmer and what s/he produces. A bad programmer, with just GOTO and line numbers, will often produce convoluted code that's completely unreadable; a bad programmer with a good suite of structured control flow will more generally stumble to something that's at least mostly clear. So how does async vs threaded stack up there? A competent programmer won't have a problem with either model. A mediocre programmer probably will think about one thing at a time, and will then run into problems. Threading produces these problems in one set of ways, asyncio produces problems in another set of ways. Which one would you, as an expert, prefer to deal with in a junior programmer's code? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
