I don't do much PHP anymore but I can see the appeal coming from a c/c++ perspective. When I was doing PHP I felt closer to the metal than I feel with Python now.

A lot of the PHP libraries looked like thin wrapper over well known c libraries. Instead of shoehorning everything to make it PHPonic, the function calls were similar to their c counterpart. You could sometimes even read the man pages for the c libraries if you needed extra details on how the internals worked.

There was a simplicity to this that was appealing to me. The lesser amount of magic and abstraction meant I could more easily visualize what was happening under the hood and find bugs quickly.

    "PHP Should Be Implementation Neutral, and Support All Paradigms Equally".

This is what I like about PHP. When you want a 4 page site, you can use procedural and functional programming. When you're working on an enterprise level CMS you can whip out the OO paradigm and you're set. PHP is a messy soup but it does web better than most other languages.

One nice side affect of this is that PHP can suit both novice and experienced programmers. Newbies don't have to learn OO before they write Hello World.

Yeah, and thanks to this, you end up with a "beast" like Magento, written by "experienced" programmers, and then you have novices tasked with writing themes and components for it, but it doesn't work that way because the "beast" is not "black boxed" well enough for the novices to ignore it. (I keep quoting "experienced" here because the example Magento is just "Java written in PHP" and I'd fire anyone turning up this type of code.)

Having had the unfortunate experience to work with Magento recently, I completely agree with your evaluation. My reoccurring thoughts were exactly "this is Java written in PHP!".

Then please spread the word and stop clients/managers from choosing it! Let's stop others from falling into the "look, it even has ebay integration!" trap!

Unless you can offer any real alternatives to Magento I have to call bullshit, yes the framework is far from perfect and PHP is not the prettiest language.

But calling Magento "Java written in PHP" without offering alternatives, specific criticism or any backing of the argument is just childish.

That's also a problem because anyone with a day experience in PHP can claim to be PHP developer, and often companies can't really tell the difference between an experienced and non-experienced programmer. If they can do PHP, they can build our website and we end up with horrible unmaintainable code. I think that's why PHP has such a bad reputation.

...naah, any kid can learn Brainfuck in a weekend ..."real" programmers don't even need a 100% Turing complete language to get the job done: choose Malbolge instead! (http://en.wikipedia.org/wiki/Malbolge)

maybe we should all switch to brainfuck for web development then so we can weed out the stupids [/sarcasm]

I get your point, but being easy to pick up AND easy to make dangerous mistakes is a bad combination. The goal isn't necessarily to "weed out the stupids", but rather to prevent bad practices from propagating. "Too easy", in my view, means having a rotary saw with no guard and a hair trigger.

PHP suit "experienced programmers"?

In a way this means nothing: experienced programmer can program in any language.

In another way it is wrong: experienced programmer know how so well that building a solid application on rotten grounds is a pain, and would prefer a more solid ground to build their application upon.

Do I need to list again all the mess in PHP?

No. No it doesn't. It does it easier. That's not the same thing.

When it comes to the web, lower barrier of entry is actually a value in itself.

PHP works fine as long as you're never exposed to a better way.

In a year or two start using rails. You'll come back to PHP and wonder why anyone would ever make a hammer with two claws.

You're confusing a language with a framework.

A more apt comparison is rails with symfony2 or zend framework2.

You're right. Still I can compare doing web development using ruby on rails with doing it in php without a framework.

I've done both, rails was much more pleasurable. See? I just compared the overall experience of a language with that of a framework.

You just did it again. Why would you compare Ruby on Rails with PHP?

Do you realize what you're saying?

edit: replied to you as if you were fleitz. Point stands as you basically parroted what he said.

Are the sort of people writing straight PHP the sort of people who would be using rails? Try a PHP framework like Laravel and then compare that to Rails.

I took a look at that, it appears that you unzip the framework and then start modifying it directly. After you "upload it to your webserver". Deployment? Source Control? No, not in PHP, you just modify shit right on the webserver.

I'm sure this process makes upgrading painless, just unzip the framework and... wait... all your changes just got overwritten.

This kind of crap is exactly why everyone with a clue laughs at PHP.

No. Everyone knows that you do not modify the framework files. Hell, everyone knew that you do not touch the framework system files years ago with older frameworks like CodeIgniter, so it makes me doubt that you have any experience with PHP frameworks at all.

You would upgrade your Laravel framework with composer, which runs on Git. And it'll most likely just work without any "Gem hell" that i've come to experience with some other languages.

Yet the framework docs say none of this. Look at rails, it tells you, put your gems in the gemfile.

Laravel says, hack shit directly on your webserver.

If you're supposed to use composer, why don't the docs say this? Instead the docs say, unzip and hack.

The docs don't say that you would update the framework via composer (though this may change when Laravel 4 is released) but they do say that you should just replace the "laravel" folder with a new version using whatever method suits you best, which can be even easier. It certainly seems easier than upgrading Rails, since then you can update your whole remote application code and framework in a single push.

The docs clearly explain that your bundles go to the "bundles" directory, controllers go to the "controllers" directory, views belong in "views" and so on. And your whole application resides in a directory called... "application". You'd actually have to be pretty advanced and amazingly stupid at the same time to make a functional app in the framework core folder and than destroy it by overwriting.

Rails docs don't tell me to unzip the framework and start hacking, but they do instruct me to run "gem install rails", wait a couple of hours till it's done, then run "rails new blog", "cd blog" and then start hacking. Neither set of docs tell me how to setup version control before i begin my work, and they shouldn't. That's not the job of the framework docs.

And of course you're gonna hack your application directly on the server, albeit a local one, as PHP applications are typically developed. This in no way prevents you from using version control and proper deployment techniques.

Nothing stops you from using source control with PHP. Nothing stops you from working locally and then pushing changes up to the server. You make no sense.

Wow, you're the type of developer who would leave an absolute mess in his wake.

Everything you said I rail against daily. Stop bringing your bad habits into PHP, we have enough of them already.

You really have to be kidding...

The problem with php is that is scales terribly with the size of the codebase. Try to move away from the comfort zone of the language and the size of the project and it changes a lot.

The opposite, actually. PHP's shared-nothing architecture makes scaling a breeze. Just add more hardware.

I believe you misread parent. The size of the codebase has little to do with the resources needed by the software.

If this is the case, then maybe PHP's role is a rapid prototyping language which is replaced when the codebase gets to a certain size.

Generally that size is not more than about 5 files.

Yeah good one. Wordpress is a great example of a huge failure written in PHP over 5 files, right?

The codebase of Wordpress is an utterly terrible, offensive, kludgy, hacked-together mess of spaghetti code. The last time I looked at the internals it still lacked a coherent MVC structure. There are big, good things built with PHP, written the right way with solid software engineering principles, but Wordpress is not one of them.

Yeah, it's very evident in the fact that no one uses it, too. PHP sucks.

If number of users was equivalent to quality you would be correct. But it isn't. Under your argument, Wal-Mart is a purveyor of family heirlooms.

The number of users is not equivalent to quality. It's an indication of quality.

As for quality...

No, Wal-Mart isn't a purveyor of items with the qualities of being expensive, extremely limited, and old.

Quality is a subjective word, defined by different aspects. Just as I can, with justification, define Apple as a purveyor of low-quality hardware, I can say equally it sells high-quality software.

As you say, quality is defined by a number of factors. I'd say that a good, high-level general purpose programming language should be:

- coherent

- non-verbose

- provide solid high-level abstractions

- safe

- have a solid standard library

- optionally, easy to get started with

Of all these qualities, PHP is geared toward "ease of access" with a sprinkling of non-verbosity, and fails mostly or totally in the other categories. Just like the popularity of the Millenium trilogy does not mean Stieg Larsson can write, the popularity of PHP is more an indication of its low barrier to entry (especially combined with widespread hosting support) than anything else.

> Just like the popularity of the Millenium trilogy does not mean Stieg Larsson can write

Technically, it does. =)

I'm surprised you wouldn't consider the license a language is released under as one of the factors. Or maybe you do, and you forgot to list it. And therein lies the issue: the number of people are indicative of certain qualities, qualities you might not consider important, or might not weigh as highly as other people.

I love erlang, but I'd be hard pressed to use erlang for as many projects as I would like. Not because of failings of the language itself, but because certain qualities it does not possess (ubiquity for one, which affects so many other areas).

It's not even an indication of quality, it's an indication that many people use it.

I guess you can quibble about definitions all day if you like, and you can take "family heirlooms" literally instead of metaphorically as it was intended, but that won't make Wal-Mart a seller of quality items nor will it make PHP a well-designed language under any sort of definition that is relevant to reality.

And, honestly, if the only thing we're going to argue about is whether or not quantity equals/implies quality and the definition of "quality", the argument against PHP has already won.

Yes, it is a "good one." Wordpress' source looks like spaghetti with shit sauce. The fact that it runs is a testament to something, but not the readability, maintainability, or usability of the code base. Those people wouldn't know a well-designed API if, well, fill in the rest here.

Good point. Must be why no one uses it.

Whatever else you are, you're not too stupid to see what's wrong with this argument. So the fact that you're forwarding it anyway means you can't make a real point, or you are trolling.

Or facebook.

http://blog.facebook.com/blog.php?post=2356432130

Facebook _doesn't_ run PHP. A large portion of it is coded in PHP, but it runs C++ through HipHop[1]. Facebook may as well be written in anything that compiles down to C++.

1: http://en.wikipedia.org/wiki/HipHop_for_PHP

Actually, the difference between compiled C++ code, and the newest version of PHP with APC/Xcache is not that drastic, but facebook needs to squeeze out every bit of performance so they can to cut down on the number of servers.

For what it's worth, PHP 5.4(without APC) performed better than both Python and Ruby on that language shootout page: http://benchmarksgame.alioth.debian.org/u64/which-programs-a...

By that standard, anything may as well be written in a language that eventually results in machine code being executed.

Actually, facebook is moving to a JIT model and getting better performance out of it than the crosscompiled code.

http://arstechnica.com/business/2011/12/facebook-looks-to-fi...

If you have experience in c++, I have used Wt [0] previously for webdev and found it pretty straightforward (it's like Qt for the web) and extremely performant. Dual license GPL/commerical.

[0]: http://www.webtoolkit.eu/wt#/features

> everything just worked.

That's the scariest thing about the language. The php will run whatever you write in the script; assuming things, hiding errors, etc..

It sounds like you've never properly programmed in php a day in your life. Stop spouting nonsense. If you're going to develop in php, you do so in strict mode with all errors turned on. Doing otherwise makes you part of the problem.

I'll accept this argument when PHP starts shipping with sane defaults. It's only quite recently that register globals got turned off in the default config.

Global registers were deprecated in 5.3.0, and completely removed in 5.4.0

http://php.net/manual/en/security.globals.php

5.3.0 is 2 and a half years old.

and many shared hosting providers are still on 5.2, and many crappy old scripts require register_globals on.

And that's PHP's fault? It won't affect you if you start writing a PHP 5.3 (or even 5.4) app today.

Yes, it is PHP's fault. It's endemic to the general attitude of the PHP team.

"Now just marginally less braindead than every other language" isn't exactly a selling point.

Sure, it used to be worse, but I see zero commitment from PHP to actually make real steps to fixing the situation. A real first step would be to start working on a 6.x release that actually removes the gazillion deprecated-but-still-present-and-thus-used things in the language.