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! :-)

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.

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.

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.

Same was true of say Visual Basic for many years.

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.

    PHP is Easy

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.

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.

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.

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 :)

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.

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.]

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.

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

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.

Smarty: {$firstName}

vs

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

And, loops?

Your: {loop}

vs

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.

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.

I woun't.

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.

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?

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.

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.

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!

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?

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.

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

Really, it's the BASIC of scripting languages.

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.

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.

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

Good ole days.

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.