Adam Bard has written up a post that takes the same small application (a "Nurblizer") and writes it as a web application in four different languages - PHP, Python, Ruby and Clojure. His point is less about which is "best" but more to show the differences between them.

Here's a toy program I wrote implemented in PHP, Python, Ruby, and Clojure. I hope it's helpful for someone who knows at least one of those and wants to learn another.
The program is called "Nurblizer", and it does one thing: Accept free-form text, and attempt to replace all words but the nouns in said text with the word "nurble". It's up and running at http://nurblizer.herokuapp.com

He includes the source for each language's version using Sinatra for Ruby and Flask for Python but for PHP and Clojure it's just straight code. For each he briefly explains what its doing and a bit about how it relates to the examples from the other languages. He also points out a Hacker News discussion that's popped up about the examples.

In this latest post to his site Chris Hartjes shares some of his thoughts about the recently approved PSR-3 standard (for logging) and some of the reception that the other PSRs (PSR-0, 1 & 2) have gotten from the PHP community.

For those who pay attention to the workings of the PHP community you might have heard about the "PHP Standards Recommendations" that have been coming out of the PHP Framwork Interop Group. [...] More recently this group has been working on a standard for logging interfaces called PSR-3. I spoke about this on Twitter, and I will repeat it here: I think PHP programmers should get behind PSR-0 and efforts like PSR-3. I feel that PSR-1 and PSR-2 are solutions looking for a problem and seem, to me anyway, to me out of place with the solutions offered by PSR-0 and PSR-3.

He likens the PHP PSRs to the Python enhancement proposals (PEPs) and, more specifically, to the PEP-8 - their own version of "coding standards" that was highly championed by Guido van Rossum and put into wide practice.

Any programming language community that does not work as hard as possible to make it easier to integrate other's libraries of code together [by standardizing their formatting] is asking for irrelevancy.

Multiple inheritance isn't allowed in PHP. [It's not] possible with PHP (in Java is not possible either), but today we can do something similar (is not the exactly the same) with Traits. Let me explain that: Instead of classes we can create Traits.

He includes a code example showing the creation of two traits, "Base1" and "Base2", that are implemented (via "use") and the calls to methods on each. He also points out the error condition and message that can come up when there's a conflict in the method names between two or more traits. This is relatively easy to solve with the mapping ability of the "use" statement (code example included for that too).

The latest episode of the /Dev/Hell podcast has been released - "Episode 20: Chris Hartjes's Kitchen Nightmare" as hosted by Chris Hartjes and Ed Finkler.

This week we talk about how Chris sucks at cooking food, which segues nicely into a discussion of the True North PHP conference that he's co-organizing in Toronto in November. Thankfully he will not be catering the event himself. We also talk about Ed's move from doing PHP to Python for day-to-day work, and the plusses and minuses he's encountered during the transition.

PHPClasses.org has posted the latest episode of their "Lately in PHP" podcast series - Episode #27, "Running PHP code with JavaScript and Python VM".

PHP applications popularity is so high that developers which prefer using other languages are trying to compile PHP code in languages like JavaScript and Python using new virtual machine projects. [...] They also cover the latest PHP releases and the new features planned for PHP 5.5, as well the new PHP elephant plush toys that were produced by the PHPClasses site to give away to the best contributors of the site.

On PHPMaster.com today they've posted a new tutorial that helps you get started adding queuing to your application with PHP and RabbitMQ.

RabbitMQ is open-source message brokering software written in Erlang. The MQ in its name refers to a standard known as Advanced Message Queuing Protocol. For our purposes, and most others, it acts as a middleman between producer (sending) and consumer (receiving) programs - it simply accepts and forwards messages. [...] Both producers and consumers can be written in any language that has an available RabbitMQ or AMQP client library. In this article, I'll demo a producer program written in PHP and a consuming program in Python.

He walks you through the installation for both RabbitMQ itself and the PHP (php-amqlib) and Python (pika) tools to use for the interfaces. There's some details on how the queuing system works and the code for the sample clients is included as well as commands to use the two clients to send/receive messages.

The /Dev/Hell podcast has released their latest episode co-hosted by PHP community members Chris Hartjes and Ed Finkler - "Episode 12: Irish Eyes Are Always Smiling".

Through a haze of jägerbombs and extreme fatigue, we were able to shovel out another pile of podcast for your listening enjoyment. Chris says it's episode 11 when it's actually episode 12, but hey!

They talk about the Apple vs. Android functionality gap, Rackspace's recent issues and the definition of "guiding principles in an open source project". They also mention another PHP community member Brian Deshong who has volunteered to help out with an iPad app for the show.

In my previous post Modern framework comparison I presented performance tests, which compared Ruby On Rails, Django and Symfony2. After recieving a feedback in comments I decided to run this benchmark one more time on my own laptop (instead of on my hosting). The reason was simple: enviroment was outdated.

There were some overall performance increases were seen, but some statistics were higher - the "time per request" for all of them grew, some by quite a bit. He presents these benchmarks with a caveat, though:

You should never choose framework based on benchmarks. Those shows them from one point of view, but there are plenty of other aspects, such as support, community, maturity, number of ready to use components.

On the Udemy blog there's a new post with a large infographic showing "who reigns supreme" comparing Ruby, Python and PHP (don't worry, this isn't flamebait...it's actual good stats comparing the state of these three languages).

Just as the Japanese, Spanish and French languages are uniquely different, programming languages also have their variations, some more popular and easier to use than others. With the recent introduction of some new ones, there is a 'war' of modern day languages. What's easier and faster to use is not always the best option.