Elaboration on Switching to Python in 2.0

Some of you have expressed disappointment regarding our decision to switch to Python for 2.0. I was going to reply in a comment, but before I knew it I was writing paragraphs, so I decided to make a separate post.

I'll start by briefing you know our situation. We have to rewrite Lucid from the ground up with two or three developers at hand. We would love to support both PHP and Python, but we don't have enough resources at the moment, so we had to pick one or the other. We didn't have too good of an experience with PHP, and Python would let us do a lot more, so we went with Python.

The reason why we went with Python was mostly because the huge assortment of modules would let us do virtually anything with ease. We could edit word documents, connect to IM protocols, etc. Doing this in PHP would require a daemon running in either PHP (which has an awful garbage collector, and would use lots of memory), or another language like Python. Since we would likely opt for the latter, why not just do the whole thing in Python, since you would need it installed anyway? We also find that Python is much easier to do object oriented code in, and is easier to debug.

That said, a PHP version isn't out of the question. During the PHP vs Python decision process, we considered writing a simple PHP backend that would at least run Lucid on a PHP host. If someone wanted to work on a PHP version, we would be more then happy to work closely with them on it. The only downside is that not all the apps would work on the PHP version, but the package installer would warn the user if this was the case.

We tried using Zend for 2.0 in the past, since Zend has some nice Dojo integration, but we felt that it wasn't flexible enough for our needs. Plus, the idea of writing an application framework on top of an application framework seems a bit over-the-top in my opinion. Despite this, Zend does have some nice modules that we could take advantage of. We actually use Zend's JSON class in 1.0, so we could do something similar in 2.0.

That said, the PHP version would need to be simple, and easy to maintain. Like I mentioned earlier, we want to focus on Python, and we don't want differences between the PHP backends and the Python backends to drag the development team down.

So, we're going with Python because it's a better choice for what we want to do. A stripped down PHP version is possible, but not for the initial 2.0 release. I completely understand why someone would like a PHP version, which is why I would be willing to support a basic PHP backend, but we can't really do this at the moment.

How does that sound? We would love to make everyone happy, but we need to make decisions like this unfortunately. If you have any suggestions, or an even better idea, feel free to drop a comment.

Posted by Will Riley on February 4, 2010