views:

1747

answers:

11

I've read a few posts where people have stated (not suggested, not discussed, not offered) that PHP should not be used for large projects.

Being a primarily PHP developer, I ask two questions:

  1. What defines a "large project"?
  2. Why not? What are the pitfalls of using PHP

I run a small development team and I know from experience the quality construction, organization, documentation, commenting and encapsulation are our highest priority. We are able to develop great projects using our own framework and approach but still, I don't want to invest further if I'm wasting my time.

Thoughts?

A: 

Our company runs several large-ish web sites using PHP, and have had no problems that were related to the language.

JW
+15  A: 

A lot of people who say not use it are really saying don't use PHP 4. It comes down to this

you can write good code in any language

and

you can write bad code in any language

PHP can very often lend itself to becoming tangled spaghetti code libraries and make your 'application' really just a series of scripts (see Moodle for a good example of this...)

I think a lot of the 'Don't use PHP for large stuff' is coming from PHP being hacked up from it's original purpose: a templating language. Which I can understand, but there are lots of projects that prove you can do it (Drupal, mediawiki, facebook).

update: apparently facebook isn't php or isn't complex enough or something ;) So lets substitute flickr or digg or whatever.

jskulski
I've heard facebook aern't using PHP any longer. The .php links are now for legacy and are probably rewritten or parsed differently through the server. I can't remember where I read the article, but from what I can it was reputable.
alex
Facebook's frontend is written in php, if anything at all. I know that Myspace uses .NET but has ".cfm" links for legacy compatibility...
navitronic
Is .cfm cold fusion?
alex
Facebook is still written in PHP
Cal
Yes, CFM is associated mainly with Cold Fusion Markup.
drlouie - louierd
Matt Garrison
+4  A: 

I guess this discussion covers most of the bases:

http://stackoverflow.com/questions/309300/defend-php-convince-me-it-isnt-horrible

Vinko Vrsalovic
+12  A: 

Theres no reason you can't use PHP for large projects. After all, Facebook is built on PHP. There will be issues however but there are issues with any large project.

What makes PHP so pervasive is the low barrier to entry and cheap hosting. It runs as an Apache extension and you can pretty much just start coding. If you go to more enterprise platforms such as .Net or Java, they have a much higher barrier to entry but they also come with a lot of infrastructure to help you make applications that scale.

For example, the database abstraction in PHP is (imho) woeful. It's vendor specific. With MySQL, people tend to do things like:

function get_users($surname) {
  mysql_query("select * from users where surname = '$surname'");
  ...
}

which is bad for several reasons:

  • It makes poor use of the query cache;
  • It doesn't handle escaping of characters (which, of course, can be done with mysql_escape_string() but you'll be surprised how often people don't do this); and
  • It's fairly easy to code in such a way as to allow SQL injection attacks.

Personally I prefer mysqli for all the above reasons but it has it's own problems: namely that using LONGTEXT fields crashes mysql and has done since at least 2005 with still no fix (yes I and several others have raised a bug).

Compare this to Java (with which I'm more familiar) and JPA or Ibatis are vastly better ORM solutions with higher startup costs but they will help you on an enterprise scale.

So you're not prohibited from doing large projects on PHP. It's simply harder in that you have to do increasingly more work yourself to replicate what other platforms provide you.

That being said, PHP + memcached/APC + beanstalkd goes a long way.

Oh that's the other problem: PHP doesn't really support background processing or threading. You need something else for that (or standalone scripts). If you're using something else, why not use that for the Web stuff too (eg Java, Ruby, .Net, etc)?

cletus
Facebook is kind of a tortured example. Facebook isn't a complex business app. It is a fairly simple that is scaled very highly.
BobbyShaftoe
I would like to upvote this answer twice.
Knox
how exactly does that example query make poor use of the query cache?
ʞɔıu
PHP now has database agnostic libraries for connecting to a database. (PDO). PDO also supports prepare() and execute(), which handles escaping of input. Just because PHP allows for poor coding doesn't make it a bad language.
Ryan Doherty
@Ryan: Did anyone suggest PHP was a bad language here? Kneejerk reaction to some not-completely-positive PHP discussion perhaps? ;)
Gareth
That example has a problem you've overlooked: it doesn't abstract database access away from the function request: get_users() shouldn't even be assembling SQL, never mind submitting the query itself. So many people make this mistake it just isn't funny.
staticsan
+3  A: 

For me the worst PHP sin is coupling of presentation with business logic. It's not that you can't write it in a better way, but it doesn't encourage you to, and if anything it encourages you not to.

A large number of security vulnerabilities are associated with PHP sites, too. I can't prove it is disproportionate (after all a lot of sites are written in PHP), but I suspect it is. If I'm right, then since security vulnerabilities are a class of bug, I suspect PHP sites tend to be more buggy on the whole also.

(I don't think that pointing at a few large sites and saying they managed to do it in PHP is any argument against this, by the way. It's a bit like saying that cigarettes don't cause cancer because your next door neighbour smoked and lived to be 100.)

frankodwyer
Smoking and living isn't a matter of choice, it's a matter of circumstance. Building a successful site in PHP is a demonstrated matter of choice that can lead to better industry practices when shared at sites like www.highscalability.com
jerebear
+26  A: 

I really hate it when people say flat out that PHP is a terrible language because you can write code which mixes presentation with logic, or that it lets you allow SQL injection. That's nothing at all to do with the language, that's the developer.

PHP has proved itself to be highly scalable: Wikipedia is one of the largest and most popular sites on the Internet and it runs PHP. Enough said?

There are a lot of tools/libraries out there that give you a framework to work in, making it less likely that someone will write poor, less-maintainable code: see CakePHP, Symfony, PDO, Smarty, etc etc etc.

It has received a bad rap because it's a language which has very low barriers to entry: it's free, you can get very cheap PHP hosting, the documentation is the best there is, there's plenty of tutorials online, plus it makes a lot of things very easy (eg: open a URL and get the contents of the file: file('http://www.google.com');). This means that a lot of newbies picked it up and made a lot of very dodgy sites with it, but that's going to happen with whatever language you choose as your first.

Work with a solid ORM framework (there's about 30 questions on SO about which is best), and it will treat you good.

nickf
Agreed. PHP is a very easy language to learn, and is much more flexible than say, Java. This, unfortunately, has the effect of allowing inexperienced coders (I conciously did not use the word "programmers") to write scripts that manage to run, but are extremely buggy. This is what gives PHP it's (undeserved) bad reputation -- a bunch of amateur coders who write crappy code.
jrtayloriv
+1  A: 

Check out this similar question - http://stackoverflow.com/questions/130869/can-php-handle-enterprise-level-sites-as-well-as-java

Recapping - Facebook, Wikipedia, Yahoo.com, Digg, Flickr and many other giant sites are running on PHP. If you ever come close to making something of that caliber, you can still rest assured you can get there with PHP.

How maintainable, extendable, reliable, secure and performant your applications will be is entirely up to you and is language-agnostic. In favor of PHP though, it has very convenient tools for building web applications.

Eran Galperin
I think you're mixing scalability versus enterprise class design. Facebook et al are not very complex sites. Sure, they do scale out very well, and that is impressive in some sense. You can also scale out static pages fine but what about designing complex software sstems. Is PHP the best choice?
BobbyShaftoe
First of all, facebook has very complex innards. When you consider all the relationships between information pieces and integration with the public API - and how it works on the scale it does, I would consider it very complex. Second, nobody said anything about enterprise -
Eran Galperin
the title is about large PHP projects, and facebook is certainly one. You need to know your target audience - PHP wasn't meant for building hospital monitoring software, but constructing web applications.
Eran Galperin
+2  A: 

For me, and talking about large or even huge projects, it (primarily) boils down to one word: Dependencies.

The problem with a scripting language is like in every thing in the world: The greatest advantage is the greatest disadvantage at the same time.

The greatest advantage is to code free and fast. Just write a script and it will server it's purpose. No verbosity needed, simply code.

The greatest disadvantage is, in a way, to check if this script is not disturbing other scripts. Or better: Change an old script others are relying on. Are you sure that all dependencies do work out as you desired?

This is not true for "normal" web page generation, whatever normal means here. But we have a product relying on some 500k lines of source code, with customizations for clients consisting of an additional 100k lines of code, too. And I am deadly glad that a compiler checks all dependencies and warns/errors me in case I did something wrong (like, speaking lowest level here, misstyping a variable or method call).

I think this and the fact that other languages provide more simple-to-use "enterprisy" features by their nature (i.e. application servers for "bank usages") boils it down why many do not see PHP in large (or better: huge) projects.

Georgi
A: 

These are all good answers.

I was a newbie. I've only been coding for 5 years but I directly support and manage 85 small to large websites and I'll tell you what, the potential to get sued by having a website down for a day will contribute a lot to your desire to learn how to and make better code.

It's nice to hear established developers share their thoughts on this matter. I don't think PHP is the best, but it seems my investment in "best practices" is well served.

Thanks everyone!

jerebear
A: 

There's something about the construction of the PHP language that is not good enough for me. For example, the name of the functions. It is a non best practice use a several ways to name a function in one language. The mixture between underscores (function_name), words stick together (functionname), etc.I mean, this is really a mess. There are too many functions that are very similar or do the same things, but their names are so confusing. This is not characteristic of a good programming language.

In large deployments, the language must be enough easy and specific to write. Something that PHP omits like the declaration of variable types, become very difficult to understand and deal with later.

Other point is the constant addition of features and canceling of some other. It supposes that the addition of OOP in PHP 5 gonna make the things easier for programmers, but what about the considerations of back compatibility?

The principal reason that this programming language is like it is, is due to its origins: Personal Home Page. It was not designed for large deployments.

I know that there are great efforts to make this language an enterprise-weight language, and personally, I'm waiting for a good enough open source server-side programming language; but until this day comes, it's gonna run a lot of water under the bridge.