Two Roads Diverged in Yellow Wood

Nikon D90, 20.0-35.0 mm f/3.5-4.5
0.008 sec (1/125) @ f/5.6, iso200, 20 mm (30 mm)
© by Eric Vondy on flickr

I come to bury PHP, not to praise it?

(I received an answer request from someone on Quora for this question. At the time of my writing, there were only two answers, both that boiled down to “use Python.” While I feel I was asked to balance out that with some PHP cheerleading, I can’t bring myself to do that. Nor, can I hop on the bandwagon.)

Between PHP and Python which is better for a startup?

My answer reads like a Zen koan: it depends on the nature of the problem; it doesn’t really matter. It becomes the nature for future problems; that makes it matter.

All problems at this level are problems of architecture, not language choice. Cal Henderson, the programmer behind flickr and the CTO of Slack, was fond of saying, “All languages scale, not all architectures do.” Scalability is one problem that your startup might face, and you solve it, not with language choice, but with the solutions you choose within the language you chose.

The fundamental concept drawn from The Timeless Way of Building, the book that first brought forth the concept of a design pattern, is that the best architectural solutions can come only when one considers the environment the problem is in. Language choice is part of that solution, which you choose itself helps create the environment for future choices, so the “best choice” depends on the nature of your problem and the resources at your disposal, and it comes with “consequences.”

Let me give you two hypotheticals:

What if your startup isn’t based on programming at all and the only internet-problem you face is building a landing page for your company. In that case, your problem might be best solved by running a WordPress instance through a service network, managed , or yourself. WordPress happens to be written in the PHP language, but that fact is nearly irrelevant to your business since no (or very little) programming would be involved. This is a very common use case as evidenced by WordPress’s dominance over the CMS market (58.9% market share) and the internet in general (26.9% of all websites).

Let’s say your business uniqueness is the web, and your small engineering team wants to use a single language (excepting the need for Javascript) running and maintaining the network themselves on the cloud. PHP only solves one problem well (making a website), so its a near non-starter here as it demands heterogeneity in languages and tools. The inability of being able to segment your team into DevOps and web development would push your business toward Ruby or Python. Faced with the options in the question, the answer is clearly Python.

However, having chosen, the language choice becomes an environment that affects future decisions:

PHP developers are more ubiquitous and cheaper, even seven years ago there were five million of them in the world. It is easier to hire them, though to hire quality ones will require more vetting. On the other hand, Python works better in large teams because the language design makes it more readable to non-programmers or to programmers jumping to an unfamiliar part of the codebase.

You can do a lot more in Python which means it can act as a lingua franca where diverse parts of your business can inspect and understand almost every part of your software stack (again, front-end and mobile development being excepted). On the other hand, PHPs limitation is a strength, it avoids “not-invented-here” by forcing your engineers to look for applications, tools, and solutions written in other languages and simply binding to it.

This focus is a huge reason for PHP’s success, and why you can’t talk about PHP programming without discussing “LAMP” or some similar specification of the entire stack. To take another poster’s recommendation of “Python [having] the win for the most parts” due to its superiority in asynchronous programming: in the PHP world you would simply defer these problems to a queuing system, database, data structure, messaging system, or write a custom solution in a more amenable language like Erlang, Javascript, or, yes, even Python.

Which then is better (even in this example)? I can’t answer that. I can say only with certainty your choice will affect future decisions through the strengths and weaknesses of the language, the people you hire based on it, and the choices they make going forward. Each of these open up new opportunities and forecloses on others. In pattern design language, we call these “consequences”.

That may seem like a big deal, especially when you consider language switching costs can be immense and, in a few cases, company-ending. But those cases were because poor architectural decisions were compounded by a mistaken belief that it was language choice, not bad architectural decisions, that led to their problems. In the end, it doesn’t really matter. Business decisions and market forces will have a far larger impact on a startup’s success or failure than one small architectural choice made early.

Instead it’s best to simply make a choice, and then just be wise to the strengths and limitations of the choice going forward.

Published by


light writing, word loving, ❤ coding

Leave a Reply

Your email address will not be published. Required fields are marked *