Why PHP really won | Hacker News Reader

Why PHP really won

alan.dipert.org

77 pointswooby45 comments

"why would I use PHP for anything more than toy projects?"

Clearly PHP can, and is, being used for projects that go well beyond being toy projects. I doubt, for example, that anyone would call Flickr, Facebook, etc. 'toy projects.'

"But at my current job, I’m in charge of adding features and debugging a massive functionally-written PHP codebase. It is horrifying."

Ah...there it is. His real complaint is about maintaining bad code and not about a bad programming language. I would argue (and even wager) that equally difficult-to-maintain code could be written in Java, Prolog, C++, Lisp, Forth, and Logo (well, maybe not Logo).

I've written commercial applications in perhaps a dozen programming languages (including Prolog) and I've had love affairs with them all and yet I'm using PHP for my current project. But then again, I'm writing some great code and I love maintaining it! :-)

I interned at Facebook, and let me tell you, there weren't many people enthusiastic about being stuck in PHP.

A lot of modern sites are in PHP, because that's what the best choice was when they started (as far as they could tell), and now are stuck with that decision.

OK but look at this jobs trend line from indeed: http://www.indeed.com/jobtrends?q=PHP&l=

All those companies just got stuck and see no way out? I'm no devotee of PHP at all, but just getting stuck isn't something that works for long periods of time for so many new projects. These are websites, not core banking systems or OS kernels.

I think the real reason for PHP's success is that PHP doesn't force people to become software engineers when all they want to do is print some database records on a web page. And it doesn't force employers to hire expensive software engineers just to thrust software engineering complexity down their throat when they really don't need any of it.

Believe it or not, there is still a great number of websites that are not web apps and never become web apps. They just show you some pages of content with some dynamic parts on some of them.

There's no reason for MVC, no reason for object orientation, no reason for separation between designers and developers, no reason for ORM, no worries about transactions, no interaction with messaging systems or other integration stuff, no need for unit testing or mock objects, no need for 101 deployment scenarios, no need for REST APIs, no need for maintainability because there simply isn't that much code to maintain. But that's what 90% of RoR, Django, JEE documentation is about.

People complain about atrocious PHP code. That's because some websites "degenerate" into web apps over time. The majority of people who create them are not software engineers and have no interest in becoming software engineers.

And yes some of those "degenerate" websites are getting stuck with PHP. But I think you would be mistaken to assume that all or even most of them go down this route. Most websites just remain websites. Some do a rewrite. Others add more interaction or features by installing one of those clunky CMSs. And the CMSs are written in PHP to let the creators of websites (not web apps) customise the system using little pieces of PHP, again without any need for software engineering practices.

So if you need a taxi today, why would you hire an international logistics specialist? Is it because you might get stuck with Beijing taxi drivers shipping iron ore to your steel factory, or because you may never need iron ore deliveries? I think for most users of PHP it's the second. They never do complex web apps.

And all of that has nothing to do with whether or not PHP is suitable for creating complex web apps using software engineering principles.

Great post, though it is hard to follow in some places. For one, the parent's statement that "a lot of modern sites are in PHP, because that's what the best choice was when they started (as far as they could tell), and now are stuck with that decision," is logically sound, while your response that "there are more jobs for PHP developers than ever" isn't mutually exclusive to the parent's idea, so I don't see where he is wrong; as well, I think his post was limited to putting in context the opportunities for coding what we consider to be modern apps of today, back in 2003 and 2004.

I'm not saying the parent is entirely wrong. I just expressed my opinion that getting stuck is not the main reason for PHPs success, which is what I think the parent was implying.

All those companies just got stuck and see no way out?

Same was true of say Visual Basic for many years.

Look at this trend line from the same site: http://www.indeed.com/jobtrends?q=PHP%2C+ruby&l=&rel...

Are they just blaming the language for the code quality? If you are maintaining someone else's rapidly developed code, on a site with over 100 million users, then it's not exactly going to be easy is it?

If they had developed it slowly in Java, say, over 10 years then the programmers might be happier but the site would have been too late to the market and lost.

You're right. By "current job," I meant the job I was supposed to be doing as I wrote that post. I was pissed off when I connected finger to key.

And there are more than a few discrepancies in what I wrote. The "community" I bill as PHP's greatest asset also ironically produced the fellow whose code I'm maintaining. And, me. So it goes.

The underlying reason for my frustration, and the reason I wrote what I did, go far beyond the scope of PHP.

It's OK to complain about language features that make it harder to maintain code. Most Programs I know would rather maintain old Pascal code than any other language, but they hate writing in it. PHP is the other end of the spectrum where it's easy to write and extend, but quickly hit's a wall where it's extremely difficult to maintain. You also have "full spectrum" languages like LISP where fixing minor bugs can be reasonably simple or mind bogglingly complex depending on who codded it an how it was maintained.

Average quality of Python and PHP code differs drastically, so there must be something about the language.

This article includes the same false assumption of just about every other article on PHP:

    PHP is Easy

I'm not sure how anyone can claim that a language which only exposes the underlying C API of all the included libraries could be considered easy. Does no one stop to think that the reason 99% of PHP code is bad is because the language is actually hard? It's the C of scripting languages; it doesn't include a lot of fancy constructs or high-level abstractions. And, like C, that's what makes it powerful.

I think confusion exists because PHP is extremely accessible. It's intimately connected with the web environment (more so, and less securely, in the past) making it quick to get started. But that has never made it easy.

> I'm not sure how anyone can claim that ... could be considered easy.

PHP is Easy, and it's easier than Perl, I'd be surprised if you argue with me on that. PHP has very little to trip you up mentally (or at least that was definitely the case when it started winning). No closures, "arrays" are just hashes etc.

PHP is not hard. Actually the hardest thing about PHP could well be its dynamic variable names, like $$foo.

Neither is PHP powerful, it is extremely un-expressive when compared with just about any other modern programming language.

With PHP you _just_ use the clean wrappers on the C API, and that is also easy to do, no knowledge of C required at all. It's so easy you can pretty much write PHP apps without knowing that "4" is any different from 4.

I don't know if I've convinced you, but honestly, I would have a hard time making a language that was any easier.

PHP is a simple language, but that doesn't make it easy. PHP does give you enough rope to hang yourself, and unlike most other languages with a similar property (like C, C++, and Perl) PHP gets too much blame for that.

I think Python is a far easier language. No $'s, much greater consistency, more available abstractions.

You can pretty much handle most of the common complaints of PHP and build very large complex code bases, however, you have to put in the work. Other languages have that work already included.

Ah, well this is where we differ, I'd say PHP is easy, not simple, and that Python is simple not easy.

My reason for feeling that way hinges upon Python having more available abstractions.

Scheme is an exagerated example of this. Continuations are a very simple idea, you can describe call/cc to someone without much hassle. But the implications of call/cc can be very difficult to grasp.

The closure is a lesser example of a simple, pure abstraction which allows complex code through this devious form of simplicity.

So that is (pretty much) why it is very easy to reach expert level in PHP but very very hard in Scheme.

At the end of the day, what's easier to learn: closures, or the fact that a callback (in PHP) is supplied by giving its name as a string?

Its easier to not learn something than it is to learn it :)

I think I can explain the problem. I taught PHP for a semester at the college level to Web designers. I had 3 months (1 class a week) to get them from no programming experience at all to having a small web application (a contact list). Mostly they all managed to accomplish the task but obviously there's only time to cover the minimum functionality necessary. In that sense, PHP is easy.

Now, here's the problem, absolutely nothing they learned is useful for building a reasonable-sized long-lasting web application. They didn't use any classes. They didn't use a template engine. They didn't use a database abstraction. They learned PHP but they didn't learn to use PHP to build real applications. So all that easiness of PHP is all wrong. If you want to do it right, it's not easy.

"So all that easiness of PHP is all wrong. If you want to do it right, it's not easy."

However, much of the time getting people to do it at all is harder than getting them to do it right after they're doing something. PHP makes it easy to start doing something and see results, and that immediate reward prompts those who wouldn't otherwise get that far. A coupla weeks ago, tptacek made this point, and I think it applies here:

http://news.ycombinator.com/item?id=418157

[Edit: to be clear, tptacek may not have specifically been talking about PHP, but about the fact that writing lots of code is an indicator of total usefulness even if the code is currently bad or inappropriate.]

> They didn't use a template engine.

PHP is a templating engine. Writing a templating language for PHP, like Smarty, is like writing a second templating language running on the first templating language.

PHP is a crappy template engine. Inlining code into an HTML document requires a lot of discipline, a lot of code to write, and is error prone. Why not let software handle that task for you? You want to create more work for yourself?

Don't want to inline code? Well don't inline code. No second templating engine can reduce complexting any more than using PHP directly as a templating language. PHP was built as a templating engine from day 1.

There is a reason why php scripts start with <? --- ?>

"No second templating engine can reduce complexting"

Oh yeah, compare:

<?php echo htmlentities($firstName, ENT_COMPAT, "UTF-8"); ?>

with:

{$firstName}

Isn't that reduced complexity? And that's not even getting into other constructs. In my template language (based on smarty), a single {loop} tag expands to 10 lines of PHP code.

Would you also claim that no programming language can ever reduce complexity over assembly language? Probably not. This is just the same thing. Compiling a higher level language into a lower level language.

Well, here is what I would write:

Smarty: {$firstName}

PHP: <?=h($firstName)?>

And, loops?

Your: {loop}

PHP's loop: <?while(loop()){?>

Of course you have to define function h() and loop() somewhere. Just don't do it in your template file and you are fine. Hardly saving you even one line of code. We are down to counting how many charecters each need.

I woun't.

"PHP: <?=h($firstName)?>"

Bzzzt wrong. And this is why having a template engine might be a good thing. <?= isn't 'safe' because it can be disabled in the php.ini file (and is disabled by default). If only you had a template language that keeps you having to know that! Also, the default is that your html escapes -- you can't forget to wrap your variable in the h() function. So it's already less error prone. And this is still just a simple example.

"PHP's loop: <?while(loop()){?>"

It's at least <?php while(list($key, $item) = loop($iterator)){?> to be correct and useful. And the template engine can inline the code (rather than call a loop() function) for better performance.

All those correctly expanded PHP tags intermixed in the HTML makes the template harder to follow. You might want to type twice as much identical code for each output variable, but I don't want to do that. It is an advantage that it's cleaner and clearer.

<?= isn't 'safe'

This is a web app for God's sake. You have full control on what your php.ini have. Which one is more complex? Install a templating language? or ensure your short-tags=On (or whatever that is) in your php.ini. And if you are talking about hosted service, short tags are by default kept "On" on most hosted services, if not all.

<?php while(list($key, $item) = loop($iterator)){?>

No, I can write any of the following if I want the variables localy.

<?while($r=loop($rs)){?> <---- this is the version I use most frequently.

<?foreach($rs as $key=>$item){?>

or even

<?while(extract(loop($rs))){?>

Now compare all these with any other language beside PHP. Java, C# or Python.

response.write "<html><head><title>" + myTitle + "</title>";

response.write "<body bgcolor=\"white\">";

while(loop inside iterator){ response.write "<tr><td" + print_var; }

Imagine typing your full page like this! You need to enclose each of your line inside a quote and also escape all quotation marks inside it. Here code and design are mixed in real sense. These are the languages that really need a templating engine.

And the template engine can inline the code (rather than call a loop() function) for better performance.

Here is an idea, better performace is gained by not loading the templating engine at all. Whatever number of chars typing saved is more complicated by loading and initializing the whole templating engine. Even that is not enough, which is why Smarty has {if}, {else}, {switch} statements. So long for seperating code and design.

You might want to type twice as much identical code for each output variable

I am not typing identical code even once.

If only you had a template language that keeps you having to know that!

We can continue discussion without making attacks? No?

"You have full control on what your php.ini have."

If you're writing, for example, an open source application or an application that is hosted by your customers (I have worked on both) you can't assume you have any control over the php.ini. The recommended php.ini file has short_open_tag disabled and having short_open_tag enabled makes it more difficult to use PHP to template XML files. It's not deprecated yet, but I wouldn't count on it sticking around forever.

All my PHP software works irregardless of the php.ini settings and works across all platforms. If that's not a concern of yours, that's fine. We just have different requirements.

"<?while($r=loop($rs)){?>"

You're making the assumption that my template constructs are just simple 1-to-1 mappings to PHP statements but that's not the case. My {loop} tag gives access the previous entry, whether or not the row is odd or even, whether or not it's the first and last entry, etc. It's a very powerful tag for the kind of common tasks that come up in a web application. But that's just one example, there's also tags for caching template blocks as well as tags for interactive controls. The level of complexity that's hidden behind a few simple tags is enormous -- which is entirely the point. I have lots of code which uses PHP itself for templates so I'm aware of the difference. I didn't start using templates, I started the other way and worked towards using templates because they make the job easier and quicker.

"Here is an idea, better performace is gained by not loading the templating engine at all."

For a compiling template engine, there's the initial cost of compiling the template when it's been changed but then there is very little additional cost. It generates a regular PHP file that's run just any other. Once the app has been running for a few minutes the template engine doesn't need to be loaded at all.

"We can continue discussion without making attacks?"

That wasn't an attack. I was making a point -- the template engine insulates you from all kinds of problems. If you forget to wrap some variable in your h() function, you might never even notice. However you've just opened yourself up to a cross-site scripting attack. And even if you never make mistakes ever, you might not be the only one working on it.

Hiding complexity is not the same as reducing it.

There is no reducing it. There is controlling who deals with it. Hiding gobs of details behind a single {loop} construct was probably a huge hassle. For the designers and non-coders touching the templates though, the complexity is gone. It isn't really, of course. It was only transferred from them to the programmer. But from their point of view, it is.

"It's the C of scripting"

No. C is a very elegant, if somewhat minimalistic, language. PHP is a kludge made of all sort of functions cluttering the only namespace there is. While K&R clearly understood the value of separating language from library, PHP deliberately ignores this lesson. I heard the most recent version (or the next, maybe) will support namespaces. It started as a quick-and-dirty solution for writing dynamic pages and, sadly, it shows.

I somewhat fail to see the power of a language as something derived from lack of fancy constructs or high-level abstractions. And, BTW, C has a lot of fancy constructs and high-level abstractions: you just have to point the right libraries to the compiler/linker.

I am sorry to tell you, but the main reasons PHP is so popular are the low cost of labor and the lack of interest by a large group of self-appointed programmers in learning anything, as you say, fancy.

"PHP is a kludge made of all sort of functions cluttering the only namespace there is"

Yeah, how many namespaces does C have again? If you were to write a web application in C with all the same open source C libraries as are available for PHP, your only namespace in C would look almost identical.

"While K&R clearly understood the value of separating language from library, PHP deliberately ignores this lesson"

Ironically, this is exactly what made PHP successful. Everything is included in the box. It wouldn't have been half as successful without including every useful library they could find.

"C has a lot of fancy constructs and high-level abstractions: you just have to point the right libraries to the compiler/linker."

You're not going to get closures, classes, meta programming, etc, etc, from libraries in C. And guess what, PHP has libraries too!

"Ironically, this is exactly what made PHP successful. Everything is included in the box. It wouldn't have been half as successful without including every useful library they could find."

I am all in for including interesting stuff, but not at the expense of forcing everything in at once and thus cluttering the only namespace people have to work. While C has only one namespace, you only include the libraries you need.

"You're not going to get closures, classes, meta programming, etc, etc, from libraries in C. And guess what, PHP has libraries too!"

While C has no syntactic support for closures and classes, C programmers learn how to build them from scratch (or use some other person's library to support that - after all, C++ stated as a preprocessor that generated C code). Are you sure you are familiar with C?

Compared to many of the alternatives at the time, php was easy. Until you are trying to make a large application that needs lots of abstraction and careful architecture, it stays easy. It is very easy to get something to work quickly in php, it's just hard to maintain a large project in it.

And it is much more accessible than almost anything else when it comes to web programming. Compared to rails even, php is a snap to set up and use. Rails has the disadvantage of being a framework, which means more learning up front. Php has the disadvantage of being (until v5) almost impossible to organize coherently, and so becomes hard to upgrade later.

Php is easy; until you've gone too far to turn back. :(

That's why it's dangerous.

You can build projects that large and easy to maintain in PHP, but you won't find many examples of that in the community. You can organize your PHP5 code just like almost any project in Python, Java, or .NET. But you do have to write a lot of code that isn't necessary in those other languages because they already have it included (and it's the standard way to do it).

I find most PHP code in the wild totally appalling. It's easy to blame the tool.

I understand what you are saying but I think most of the articles that say PHP is easy, they mean easy to set up and get started. I guess the right term would be as you said PHP is accessible.

This article says "I think PHP is a great language for anyone to learn how to program with." So he clearly thinks PHP is easy rather than just merely accessible and I couldn't disagree with him more.

You're making the assumption that C is hard. C was the second language I learned (after QBasic), and it was easy enough to make working rinky-dink applications even as an ignorant preteen.

"It's the C of scripting languages"

Really, it's the BASIC of scripting languages.

"Did PHP really win?"

Yes, for now. It is probably the most widely used language for web apps right now.

Anyone who calls PHP a toy language is not skilled enough to write anything better than a toy in PHP. It is not really a criticism, just an observation. Until you become skilled enough in any language you are pretty much doing fancy versions of Hello World. With many languages the skill of the programmer matters more. For example, I am still struggling to understand why I would ever use functional language for anything but that is a) because I haven't needed it yet and b) I haven't taken the time to acquire the knowledge and skill needed to write anything more functional than toys.

Perl: the language of "geniuses and academics"... Was it ever actually perceived as such? Or was the author simply intimidated by other, more academic languages as well? I'm pretty sure Perl doesn't do tail-call optimization like the article implies.

My impression of Perl was always as a practical, "get-'er-done" language, much like PHP -- and prone to the same legibility/maintainability problems if care was not taken.

Mmm... Matt's Script Archive.

Good ole days.

I'm still waiting for a post to get frontpaged titled "Why PHP didn't win"

I really do not understand people reacting violently on how "PHP sucks/horrifying". PHP is just a tool that people use. Blame the programmer not the tool. I have had encounters with horrifying code with a lot of times BUT most of my complaints were on bad design and how programmers badly handled their code.

"Being mindful of best practices in software development fundamentals can be more effective than adopting every latest technology." - Bill Karwin

Did PHP really win? I haven't used it in about 4 years.

this is accurate. this is how i felt. php was a statement, and asp and coldfusion at the time perhaps were right there, too, but each had their tie-ins and paradigms, and php seemed to be positioned in opposition to that. and i agree anymore it would be best if it is in java or python or something if at all possible, way more maintainable.

I'd submit that PHP is for this generation of programmers what BASIC was to a lot of the older generation (including me).

I started on BASIC on a Trash-80. Actually you can probably substitute some of the terms in this blog post for my journey from BASIC to now.

If you want easy, quick and accessible all rolled into one, try WebDNA. Nah, on the other hand I think you 'real' programmers would not be interested in using such a simple tool.

Reply on news.ycombinator.com