Thinking in Twisted

I've been emailing with a fellow developer and friend about learning to write applications and parts of applications using the Twisted networking framework. Even though Twisted is written in Python, conceptually -- and from an abstract point of view -- it is like a language of its own, with a foundation, syntax, and grammar that is Python.

My friend was trying to make use of basic Twisted stuff like deferreds, combine that with other parts of Twisted, but traverse the problem-solving process from an essentially ground-up, Python approach. I had tried to provide the shift in perspective needed in order to write Twisted apps with much less effort than he was exerting, but I fear that I failed.

Then, this morning, I thought of the perfect analogy. Actually, it's more than an ananlog -- it is the thing itself. Since really starting to learn Twisted, my programming has changed. Well, that and since absorbing such books as Patterns of Enterprise Application Architecture and Refactoring to Patterns. The deal with writing applications in Twisted is that you're no longer programming in the same language (Python); you're learning a new language. A more abstract one.

When we learn to think in Twisted and write applications in Twisted, our solutions will be elegant and compact. Before that starts to happen, we try to use our "old" ways of Python programming mixed in with the new one we are learning... and that, of course, defeats the purpose of the new "language."

The tricky thing about Twisted is that its patterns are an integral part of its "language" (perhaps it would be better to stop using quotes, and just call it a meta-language...). This is not true of most other languages -- though I would venture to say it is true of good frameworks in general. You don't need to know the patterns to use the grammar/syntax/control structures of most languages. Patterns in a language are usually optional.

With Twisted, if you aren't using the patterns, you aren't really using Twisted.

I am midway through this learning process. Therefore, I can't point to the solutions for many Twisted problems immediately or directly. I have, however, learned to see most of the critical components of a Twisted implementation. I still miss a few, though, and I have to keep reviewing code until I catch them all. Seeing these components clearly is what leads to the solution. As the time between "component vision" and "solution" gets shorter and shorter, we come closer and closer to thinking in Twisted.