Closer To The Ideal

Last summer I started to learn the Symfony web framework. At that time, it defaulted to using Propel as its ORM. Propel, in turn, relied on Creole for database abstraction. The developers of Creole have decided to abandon their project, and move on to Python. I found this interesting:

I have recently spoke with Hans (the creator of Creole) and we are in agreement that Creole is a dead project. I believe the current code base, including the beta that never got pushed to production, is pretty stable. However, I have chose to move to Python, mostly because of a frustration with PHP leadership and what appears to me to be a lack of focus and the difficulties I have encountered with the way PHP leadership handles bug reports. There are definitely a lot of drawbacks to Python web development, namely the fact that there are so many choices and that you have to work on a much lower level to get things to work (oh, and the docs are really bad when compared to PHP). But the benefits so far have far outweighed the drawbacks and I much prefer the perspective of the Python leadership and community.

Hans Lellelid, the main developer of Creole, wrote a further note:

Yeah, a language is just a language. But I will say that when things like inconsistent error handling bite enough times, you do start wondering if all languages are really created equal.

I don’t think a language should be driven by democracy; I think that has fared very badly for PHP. Things keep getting tacked on without any real fixes to the underlying architecture; result is a product that has lots & lots of “seams” revealing fundamental disconnects between the paradigms that are being used to develop the code and the underlying structures.

This contrast between PHP userland (where we get exceptions, file streams, objects) and the engine core seems like it’s paralleled by the difference between the user community and the internals developers. The developers added these features that users clamor for and vote on, but they clearly either don’t understand the features in the first place (or how they will impact other parts of the language) or never really intend to use the features themselves. If the measure of this success is simply how many servers are running PHP, I’m sure this strategy is working fine. If the measure is how many PHP open-source projects are thinking about software architecture, innovative web-based server paradigms, and enterprise-scale design, then I don’t think it’s been so successful.

On more of a rant/stream-of-thought note, I wonder if PHP is ready for the next generation of web applications. It worked great for creating HTML templates, but are people building new applications today really using PHP to generate HTML? Maybe they are, but everything seems to be moving to a model where the backend is just a services layer. PHP doesn’t offer any advantages over other languages when it comes to a simple web services layer; heck, Java even starts to look easy if all I’m doing is writing a JSON-RPC server that talks to a database. The multiple-page model for serving requests no longer makes sense; instead you have some sort of front controller — so now you’re using a framework. And all of these languages have frameworks, but languages like Java and Python not only have web frameworks but have framework API standards. They’ve been thinking about this for a lot longer, and it shows. So I think that PHP as a solution needs to evolve at the engine level (with things like namespaces + built-in phar, etc.) AND it needs to evolve at the community level (with new standards and framework specifications). I’m not sure either type of evolution is really compatible with PHP’s democracy-driven development model.

Ruby, Python, Perl, PHP, JSP, etc. For web development, the languages themselves have certain strengths, but they also, eventually, acquire software projects that make them famous. Ruby, of course, has Rails, and through that, all the software of 37 Signals, and also Twitter. PHP, in the early days, was known for projects such as Phorum. Python is known for Zope and the Universal Feed Parser.

I’ve worked with Ruby a little and PHP a lot but I’ve never worked with Python. If I ever learn it, it will be so I can use Venus. Venus uses the Universal Feed Parser to pull in a variety of feeds, and it has a template engine that allows the input to be output in any format: HTML, RSS, Atom, etc.

Sam Ruby explains the role that the Universal Feed Parser plays:

It handles multiple feed formats, date formats, and ill formed feeds. Just one concrete example to illustrate the point: the author name can be obtained from one of eight different places in your feed; and the Universal Feed Parser even handles cases where people simply put names in place of email addresses or tack on names as comments after an email address.

It partially cleans the HTML. It uses SGMLLIB to clean up the tokens, then it removes unsafe constructs (like plaintext), and resolves relative URIs.