…what is simplicity? Simplicity is the shortest path to a solution. Say somebody does a proof for a mathematical problem in 20 pages. You study those 20 pages, and finally you say, “Oh, I get it.” You get a reward as the result of understanding that proof, because the proof was a solution to an interesting problem, not just a difficulty. Later, somebody else comes up with a 10-page proof for the same problem. Maybe the new proof uses a branch of mathematics that you might have to study to master, but once you master that branch of mathematics you can use it. And a 20-page proof becomes a 10-page proof. You’d have to say it’s simpler, because it’s a shorter path. Maybe it’s longer if you have to do a digression to actually learn a new branch of mathematics, but let’s assume that over time we realize that this branch is important to know in general, so we all become familiar with it.

What we’re really trying to do in software is find a way to make it easy to get value from having solutions to problems. How do we do that? When we work the program, we put in what we think is the shortest path to a solution. When we discover that the problem is different than we thought, we rewrite. And then we rewrite again. We work the program. That process is just like doing the proofs over and over. Sooner or later we discover that instead of doing something in 30 lines of code, we can do it in 15 lines, because now we have another capability that fits in. It really is just the right capability, so the work done there we don’t have to do here. We’ll just invoke that capability from here. That makes our solution easier to follow. Plus the effort you expend today to understand the code will make you a more powerful programmer tomorrow. So that simplification is very valuable.

If you write a lot of programs, and you’re used to squeezing them all the time, you find that it’s easy to write a program that’s simple. A lot of it is having a clear sense of what you want to say?writing the proof by choosing what to prove, and being clear about that. In programming, a lot of simplicity comes from knowing what matters and what doesn’t matter. A lot of times a program is made complicated because it’s attending to details that aren’t needed, or could have been avoided, or could have been relegated to something else.

Someone says, “You should always check your arguments to see if they’re in range.” Someone else says, “Half the statements in this program are checking arguments that are intrinsically in range.” Have they made the program better or worse? No, I think they’ve made it worse. I’m not a fan of checking arguments. On the other hand, there ought to be a fail fast. If you make a mistake, the program ought to stop. So there is an art to knowing where things should be checked and making sure that the program fails fast if you make a mistake. That kind of choosing is part of the art of simplification.

…Coding up the simplest thing that could possibly work is really about this: If you can’t keep five things in your head at one time and make a decision, try keeping three things in your head. Try keeping just one thing in your head, and see if you can make a decision. Then you can think of the next thing. And amazingly, when you write some of this dumb, straight-ahead code, it often turns out that it was all that was required. It works great. When a second programmer comes back later and reads the code she might say, “The people who wrote this are morons. They just wrote a simple linear search here. This thing’s ordered, so they could have done a binary search. They could have used a hash table here. Why are they doing a linear search?” Well, because a linear search worked. And when the other programmer looked at the linear search, she understood it in a minute.

Ward Cunningham, in an interview at Artima

The news that Friendster migrated to PHP from JSP for scalability reasons has triggered much needed discussion in the Java community.

Chris Shiflett at O’Reilly had this to say (source rc3.org):

…how does scalability apply to the Web? First, you should ask yourself whether the Web’s fundamental architecture is scalable. The answer is yes. Some people will describe HTTP’s statelessness in a derogatory manner. The more enlightened people, however, understand that this is one of the key characteristics that make HTTP such a scalable protocol. What makes it scalable? With every HTTP transaction being completely independent, the amount of resources necessary grows linearly with the amount of requests received. In a system that does not scale (where “does not scale” means that it scales poorly), the amount of resources necessary would increase at a higher rate than the number of requests. While HTTP has its flaws (the proper spelling of referrer being one), there’s no arguing that it scales, and this is one of the things that made the Web’s early explosive growth less painful than it would have otherwise been.

The present discussion is about developing Web applications that scale well, and whether particular languages, technologies, and platforms are more appropriate than others. My opinion is that some things scale more naturally than others, and Rasmus’s explanation above touches on this. PHP, when compiled as an Apache module (mod_php), fits nicely into the basic Web paradigm. In fact, it might be easier to imagine PHP as a new skill that Apache can learn. HTTP requests are still handled by Apache, and unless your programming logic specifically requires interaction with another source (database, filesystem, network), your application will scale as well as Apache (with a decrease in performance based upon the complexity of your programming logic). This is why PHP naturally scales. The caveat I mention is why your PHP application may not scale.

A common (and somewhat trite) argument being tossed around is that scalability has nothing to do with the programming language. While it is true that language syntax is irrelevant, the environments in which languages typically operate can vary drastically, and this makes a big difference. PHP is much different than ColdFusion or JSP. In terms of scalability, PHP has an advantage, but it loses a few features that some developers miss (which is why there are efforts to create application servers for PHP). The PHP versus JSP argument should focus on environment, otherwise the point gets lost.

I actually disagree with George’s statement, “PHP doesn’t magically scale ‘naturally'”. Of course, I understand and agree with the spirit of what he’s trying to say, which is that using PHP isn’t going to make your applications magically scale well, but I do believe that PHP has a natural advantage, as I just described. Rasmus seems to agree with me, and George might also agree, despite his statement.

I think PHP scales well because Apache scales well because the Web scales well. PHP doesn’t try to reinvent the wheel; it simply tries to fit into the existing paradigm, and this is the beauty of it.

When he quotes Rasmus Lerdorf I think he gets to the heart of the matter:

A typical Java application will make use of the fact that it is running under a JVM in which you can store session and state data very easily and you can effectively write a web application very much the same way you would write a desktop application. This is very convenient, but it doesn’t scale. To scale this you then have to add other mechanisms to do intra-JVM message passing which adds another level of complexity and performance issues. There are of course ways to avoid this, but the typical first Java implementation of something will fall into this trap.

PHP has no scalability issues of this nature. Each request is completely sandboxed from every other request and there is nothing in the language that leads people towards writing applications that don’t scale.

It’s been my experience that because of Java’s abundance of riches when it comes to application design, many using it concentrate too much on tuning the Java code on the application tier, instead concentrating on all other areas of opportunity.

Because PHP does not offer so many different options to cache or pass data within applications written with it, there is far less chance for a developer or project manager to think the scalability problem can be solved entirely there. It forces you to look at the other sub-systems in across your architecture and make sure you have the resources to do so.

I have a perfect example from work experience that I?ll share with you sometime.