This was a complaint about a general trend, not about specific words. Clearly exarkun gave you the impression that it is "bad", whether he specifically said so or not.
Could you clarify what you think the problem here actually is?
I concede I was leaving some stuff out, so that wasn't the clearest description.
In the past six months or so I've been going to lots of events where I talk to people about Twisted, and why they might or might want to use it.
I've participated in this discussion several times:
Hypothetical Amalgam of Median Interlocutors Speaking Here: "I'm using Tulip because I really like its style of coroutines."
Glyph: "That's interesting. Did you know that Twisted has an equivalent style of coroutines, called inlineCallbacks, that's been around for years?"
HAMISH: "I saw that, and I asked about that a while ago and I heard it was bad. It haven't heard that Tulip has the same problems, though."
Glyph: "Really? What problems does inlineCallbacks have that Tulip's coroutines don't?"
HAMISH: "When I asked about it everybody told me I have to use Deferreds instead, but Deferreds are really confusing and they make your code look all gross, so I didn't want to do that. With Tulip I don't have to!"
Of course the problems that we describe with inlineCallbacks are the exact same problems that you will have with Tulip-style coroutines, and in fact in one of the conversations that was averaged out to produce the above composite, my interlocutor specifically mentioned that they'd already had the kind of bug that explicit-yield coroutines can sometimes encourage (thoughtlessly putting in too many 'yield's and not considering their consequences) and were wondering how Twisted dealt with that sort of thing.
I don't object to people using Tulip, or for that matter any of Twisted's event-driven competitors - I'm much happier if they're writing event-driven code of any stripe than just spawning a thread and writing until they block - but it does bother me if they select a different project to use or contribute to because of a perceived issue created only by our collective habit of being tersely self-critical.
When anyone directly involved with producing a thing describes that thing as "good", new observers tend to take it with a grain of salt. "Of course they think X is good, they work on X." When someone involved with a project describes it as "bad", though, even if it's a convenient shorthand for many people in the conversation for a well-understood set of complex issues, those new observers tend to think, "Wow, if even they describe X as bad, it must be really bad, they work on X!".
What I am asking everyone reading here to do is just avoid calling stuff "bad" or "gross" or "complicated". Even a stock stand-in phrase that more or less just means "bad" would be better. Even an unexplained "inappropriate for my use-case", for example, least implies that the user might want to consider the system under discussion's appropriateness for their particular use-case.
We're all intimately familiar with everything that's terrible about all of our code, and we aren't shy about sharing. I just would like it if we could really lead with the details and refrain from value judgements :).
In this case, it seems like that's exactly what happened. I led with detail. The value judgement of PB being "bad" (which is a gross over- simplification, but a convenient shorthand) came afterwards.
You can see how I might have interpreted this to mean that you just said you think PB is bad :-).