the secret of PHP

So, another “PHP sucks” post, this time from Jeff Atwood. He actually ends up even kind of praising PHP, surprised by its success. I have a couple of thoughts on that topic too.

First, people really need to stop reading something on PHP written somewhere in 2005 (probably about experiences that happened in 2001) and apply it to PHP as it is now, without even checking around for current trends. It’s as if people would dig up books from middle ages saying that there are only seven metals in existence or debating about phlogiston, and would use it speaking about the modern chemistry. Come on!

Then the next thing apparently wrong with PHP is too many functions. Right. Since when? Since when having a lot of functions is a problem? Does it hurt anybody? Does it make writing PHP code harder? Does it make programmer less successful in achieving his goals?
About keywords I could kind of understand – OK, a lot to remember (though I didn’t see anybody really having trouble to remember such complicated keywords as “while”, “if”, “class” or “public”) and it takes out some good English words that could be used as function/method names to confuse the enemy (who wouldn’t want to have function named endforeach() or static(), not to mention function()? too bad those are not available!). But complaining there’s too many actual functions that allow you to do real useful stuff? That is the thing that is bothering people? That is what scares people away from using the language “for years”?

The next beef with PHP is that people write sucky code on it. No, really, they do? Must be something really wrong with this language. It’s not like people write mind-bogglingly sucky code on every other “good” language on the planet. But I get it. The intent was – PHP makes easy to write sucky code. Yes, this is true. As true as “Porsche 997 makes it easy to drive at 100mph into a brick wall”.  PHP makes it easy to write various kinds of code – and if 90% of code written is sucky, then 90% of PHP code would be sucky. But my experience says quality of the production code almost never has much to do with the language, but only with the culture – organizational and personal, and with choosing right ways to do the job. The rest is just bad statistics in play. Like “I know 7-year-old writing websites, and his PHP code sucks”. I bet his Haskell code rules though 😉

That’s not to say PHP couldn’t use improvement. It could. And it does, actually – and there’s enough room for improvement still, in many areas. But it probably would never satisfy purists. It’s practical. Maybe it doesn’t allow you to write whole programs in one line of uncomprehensible character soup or play with high-level math theory concepts, but it allows people to write web applications. So they do – so where’s the surprise when one morning somebody wakes up and discovers there’s a ton of web applications around and they are written in PHP? 🙂

P.S. I wish for every 50 “PHP sucks” blogs people would write one good RFC.

18 thoughts on “the secret of PHP

  1. Pingback: PHP sucks? not really! | the fancy part of the web - tolleiv.de

  2. I totally agree. I’m an old fart that probably forgot more language than most programmers ever learn. I was looking for a good language for Linux bash shell programming around 2001. I picked PHP because it looked easy to learn and it was new, and I like new things. I still have not written a web app, but a hell of a lot of bash programs. And yes I still have to use manual, I do not even want to learn functions syntax. But I do read the manual a lot less, than the time I spend looking for methods writing Java code, or any other OO language (including PHP-OO for that matter).
    A friend of my son wrote a PHP web app without any programing experience at all, the code is probably not ‘spitzen-klasse’. He is now helping me writing a web app mainly in javaScript, that code is very good. Does that mean JavaScript is better? Or is it experience? Why do kids today tend to use PHP for their first projects? It’s easy to produce something with PHP. Does that make PHP bad?
    PHP is not perfect, there will probably never be a perfect language. But PHP is a great language and evolving beautifully. Yesterday I got closures, something I missed. Now I’m waiting for the perl6 construct ‘junctions’. Junctions are very practical, something that will fit in PHP like ‘pitt in Greta’ (fits well).
    I’m off to learn Erlang, not because PHP is bad, but you should never stop learn, and you can do things with Erlang you can not do with PHP. Does that make PHP bad? I do not think so, I will use PHP for many years to come.

  3. Hi. I do like the discussion about this everlasting topic. For sure … sometimes it’s quite funny how taliban people think and fight for their favorite languages, platforms, styles (…) but at the end of the day discussions, even if they are somehow unobjective, improve the world…

    however…

    I want to add one point. a point which is important for me as a teamleader and project manager in software development: PHP, in my eyes, becomes more unuseful the larger the project (not measured in lines of code but in aspects an application or enterprise modell has) and the amount of people working together in a team on that project. php does not support effective teamwork…. interface design without defined return and parameter types makes it hard to reuse and extend things such as it is possible in… say… java. the boundaries of java itself and the boundaries of interfaces and the usage of modules in java reduce the risk to fail and thus the time trying to integrate with other parts of an application.
    other missing features of php are effective namespaces and packaging (deployment) of applications. one example: you are working on an enterprise project which works with direct database interaction using some kind of DBConnection Class. Good enough – PHP is a nice language to abstracterize things that way. But over time the database model becomes more complex and demands a business layer which maps the database structure to an object oriented model. here comes the problem. in other languages you easily would develop this layer independently from the rest of the application in a single project. as soon as the model works in some test applications the subteam would deploy the model package (in java as a jar file) (including sokme configuration files) and providing it under a specific version to the subteam which develops the rest of the application. they would now implement some integration and mapping facilities against the interface of the included model package. The other team (the model team) could begin to improve or broaden the model in parallel without touching any other part of the application. they dont even have the possibility to touch and modify other parts since their project is independent from the rest. however, as soon as they could publish a newer and better version of the model project they will buzz the dev team and they will include the newer version to the classpath. thats it.

    in php such things are possible, of course, but you must force yourself to do so. you must force yourself not to choose the line of the least resistence. forcing yourself is easy. forcing 20 developers in a team is almost unpossible. that is my biggest problem with php.

  4. Andrei, namespaces are going to be in 5.3. As for type safety, PHP indeed doesn’t have it. That’s part of it being a dynamic language. If you want type safe one, there’s plenty of those beside PHP 🙂 That’s as much a “drawback” as saying your computer doesn’t mow your lawn 🙂 It’s just not supposed to do that. The language can’t be everything.

    Restricting types of data and declaring the variables – it’s really not that obvious this is of any help style-wise. People on Java or C# manage to write horrible code without any serious effort 🙂 I think the idea that if you use language that makes you to declare variables then it makes your style better is a mistake. It may save you from some errors, but definitely not from all of them.

  5. I think the truth is somewhere in between. PHP does have its drawbacks :

    – no namespaces
    – no type safety (no, I don’t consider it a “powerful feature”)
    – divide by zero does not stop the execution!?
    – etc.

    However its simplicity and low entry barrier along with the “coolness” of open-source boosted it into the pole-position, IMHO.

    Some of its liberties (such as not having to declare a variable before you use, not having to restrict a type of data to hold in a variable and so on) may encourage people to write bad code however.

  6. The “function names are inconsistent” argument is true, to some extent, but not to the degree it once was. There is a convention for function/class/method naming and such; it just wasn’t really developed until PHP 4. Pretty much anything added since 2001 or so follows a fairly reasonable and predictable pattern. If you find something with a wacky name or parameter order, 90% chance it dates from PHP 3 or earlier. (That is, a decade ago.) Modern PHP is quite consistent; unfortunately renaming functions has a little tendency to break existing code, which is something the PHP dev team tries rather hard to not do.

    So you can either have backward compatibility or you can have perfectly consistent names even for ancient-but-daily-useful functionality. Pick one. 🙂 PHP has opted for the former.

  7. Pingback: techfounder » PHP Versus The World

  8. Pingback: Jeremy’s Blog » Eye of the Beholder

  9. Right on the money. I am so tired of that “low barrier of entry” crap. That’s the whole point! Should we ask people to pass a basic programming proficiency test to be eligible to use PHP? Maybe charge for PHP licenses? No, I know, make the language much more difficult to use so only highly skilled programmers could use it. Yep, raising the entry barrier is such a splendid idea!

    PHP got this bad rep because of open-source nature and web-oriented design. I mean, web developers are lower-level software developers right? It’s so fun classifying people this way or the other.

    The truth is that talented PHP developers are somewhat hard to find right now, which I’m a little happy for since it raises my value on the market as I’m finding out recently 🙂

    Long live PHP!

  10. Pingback: The Open Source swear jar « Iqag Notes

  11. gasper_k, I am of course biased, who isn’t? 🙂 Everybody who is a person has its own opinion and thus is biased.

    As for inconsistent naming – yes, that is an annoyance, but given good IDE quite a minor one, IMHO. And not that one could remember all Java classes, etc. – I don’t believe in any sufficiently powerful environment you can remember all the stuff without ever looking it up. Actually, you’re not supposed to – who has brain space for that trash? That’s what the manuals and IDEs are for! 🙂
    But applying it to PHP to single it out is just not fair – all modern languages have powerful libraries, PHP might bundle its one a bit more tightly, but that’s it.

    As for many ways to do the same thing – most developed languages have tons of ways to do the same thing. I just read some blog comparing PHP to Perl, where in one paragraph the blogger complains about PHP having two functions for doing some thing, and in the next one praises Perl for having two ways for doing another thing.
    But if you talk about real humans using real powerful languages, there inevitably would be personal styles and doing the same in 5 different ways – because people have their styles. Only way to prevent them is to force them using not style they like but somebody else’s choice – I don’t see how that could be good.

  12. Pingback: Jeff Atwood’s Blog: PHP Sucks, But It Doesn’t Matter | Development Blog With Code Updates : Developercast.com

  13. Pingback: PHP Coding School » Blog Archive » php code [2008-05-22 08:27:11]

  14. True. So true. For a bakerman, working with bricks sucks. For a builder, working with dough sucks. If people don’t like working with PHP, let them do something else.

    I don’t get it, that after years and ages and centuries the whole definition of ‘religion’ seems to have shifted. Vim against Emacs, Linux against Windows, PHP against Ruby / ASP.NET / Java. Java against C++. C# against Java. Procedural, functional against OOP. MVC against pragmatic programming. Agile development against whatever….

    In the medieval times, they slaughtered eachother over being heathens or not, called the inquisition. Thank heavens we don’t kill each other over Emacs or Windows. But the mentality stays the same. We don’t like others to have light in their eyes. Grow up!

    It is OK to leave room for discussion, but it’s something else to call eachother names. Because after all, that’s the only thing that really sucks.

    – Unomi –

  15. you’re a bit biased, but I agree with you. It’s not the tool’s fault for people making bad products. The “problem” is that PHP has a low barrier to entry, and a lot can be done quickly, including bad and insecure code.

    But having many functions actually is a bad thing. Not catastrophically bad, but bad nonetheless. The first reason is that in PHP there is no standard for function naming and parameter order. So there isn’t just function names to remember, but the whole function declaration. I’ve been programming in PHP for 8 years now, and I still have to use the manual on daily basis, just for the parameters order and to place underscores where needed (strlen vs. str_replace). Both problems are reduced significantly with code-assisting editors, but it could be better.

    The second problem with lots of functions is that for every little thing you want to do, there are several “supported” ways to do it. This leads to a million of different styles and preferences, which results in lower code clarity and understandability (is that even a word?), when the code is shared (ie within a team or open source). Give the same 5-line-solution problem to any two different programers and they would produce a different result. This is hardly a positive thing, don’t you think?

    best regards

Comments are closed.