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?