Extensible you say?

> There are tens, if not hundreds of PHP extensions.

Call me when you've got *tens of thousands* of extensions, all free to access and trivial to install from a single (one, not lots) command in a single repository, each with as many unit tests as the developers felt necessary to include (that's lots, not none) and tested on a daily basis on every conceivable platform, with tester reports available for all to see and a built-in bug tracker.

The majority of the reasons people don't like PHP, I have found, are:

- Despite there being such a wealthy cache of extensions, the community is not prepared to support them (I regularly get told this when I join ##php on freenode, for example)
- Since namespacing has only just turned up in PHP 5.3, all the extensions still have to be uber careful not to tread on one another's toes, which explains why there are so few such things.
- It's 2011 and PHP is only just catching up on concepts such as first-class functions, which still don't properly exist because the scoping model is whack.
- There are hundreds of global functions in PHP, and myriad long function names that do things that other languages do with concise syntax. We're sick of remembering the exact names and incantations of these functions, and throwing namespaces in at the last minute hasn't actually helped.
- The whole language is inconsistent. It separates concepts that could be logically conflated (namespaces and classes, for example, are just scopes and could both be resolved with ::) and conflates concepts that should be separate (how many weird side-effects are caused by conflating arrays and dictionaries?)
- Scope should be easy. Things disappear when you hit a }. That's how scoping works. PHP has some weird bogus scoping that means functions' bodies can't automatically see items outside it, and variables introduced in what many people would consider a new block remain extant outside of that block.
- The reason, by the way, that we declare variables is so that you don't accidentally re-use them later.
- People haven't forgotten the security flaws in previous versions of PHP, and especially Zend's attitude towards getting them fixed, which I recall was arrogantly aloof.
- The language pretends to be, but isn't, dynamic. How do we play around with namespaces, call stacks, lexical pads? I have seen no way of doing it.
- Despite objections it is a web language. You have to be very careful from the outset if you want to write an MVC app that can be used both from the website and from the command-line. Otherwise, things like the $_SERVER variable suddenly don't exist and you find you have to rewrite the whole thing. PHP was designed for the web and this has not been adequately designed back out again for it to be anything but.
- Unicode you say?

These are the things that come to mind. PHP is, generally, a messy language with pretensions that because you can hide all the messy bits away behind new-fangled namespaces (which have been with us since at least 1979) and closures (a term first coined in 1964) it can somehow be thought of as clean and well-written.

I work with PHP. It is not my favourite language. But it is easy. It is child's play. Until I find I have to - or want to - do something clever with the language (which is currently defined as something I could do in a preferred language, but PHP won't do) I can do PHP with my eyes shut. But I still don't like it, because it seems immature, and 5 years behind everyone else.

The reason people use PHP is the same as the reason people use Apache. There's a package for it, and when you install it, it works.

Aloha!

The point about extensions needing one install interface is a good one. I would like to see an interface that takes PHP code and makes it a native extension, as opposed to using something like HipHop PHP to convert it to a flavor of C then modifying and building off that to create the extension code (requiring that you know how to interface with PHP), then installing it. Maybe this is already out there???

Yes, it took PHP a while to support closures, but it does NOW. How it NOW sucks because of the past, is unclear to me. What sucks is the slow update of servers that use PHP 5.3. I pay premium for a 5.3 server, but it's a good server. Closures have been in PHP a few years. My biggest project relies on closures to keep a "clean code set", but there are ways to work around them.

The scoping issue threw me off when I first started using this language, and I grew up writing pure Assembly Language in the 1980s; this is my first high level language (besides BASIC, and that has only global scope). At first the scope of functions - especially nested functions, seemed insane to me, but after developing my first site, it became clear to me that due to the nature of how PHP was designed to work from the beginning, as bits of code dispersed in an HTML page, the scoping solution was the best overall. Hard to explain simply here.

The fact that YOU think that brackets {} create scope because they do in some other language or that they shouldn't when attached to a function, is irrelevant for what this language was intended to do BEST - interface with HTML. Try writing if F#. I picked up a book on that because it does not even use brackets to define scope - scope is defined by indenting program lines! (My idea of a good idea) Imagine if I criticized Mexico for not pronouncing the Spanish word pollo the same as the English word polo, or for pronouncing it like "poyyo" instead of "poyjo" (as my ears hear it anyway) like they do in Columbia. Your criticism is like the steriotyped American traveling abroad complaining that other people don't speak English - "they SHOULD! It's the universal language!" (Yes I AM American - born and raised) The language is the language spoken in the local dialect. Read "The Language Instinct".

Many of your other points are well taken, but they are also well known. Yes, the lack of a central "theme" guiding the development of functions and modules, and the way they are named and how they accept variables, etc. etc. etc. is a problem not likely to be completely overcome (see Manuel's reply to another comment). But I personally feel that detracts little from the overall usability and none of the REAL power of the language. I keep a link to the PHP doc pages in my speed dial, and tsWebEditor (a free and powerful editor for virtually any language - tswebeditor.tigris.org) provides pop-up hints to every PHP function that lists their variable's order. I WORK with HTML on a daily basis, but I still keep a mini reference book to refer to on my desk, and that's a simple "language" to master, yet I frequently (once a month or two) forget required attributes or even tag names (was it lable? no no ahh it's legend!) without this book. I could not program PHP with its thousand functions without the PHP website and/or the editor's hints in the first place. The "needle-haystack / haystack-needle" problem means little to me. I name my variables semantically, so when reading the program after it's written it is easy to understand. And remembering "exact names" of functions would not be easier for me if they had similar formats, but maybe my mind works differently from yours, and that is neither of our faults, and a reason to say your points have validity.

I haven't even used namespaces yet, but I WOULD want a different resolution operator (is it?, I don't remember) from that used with classes, the ::
This way I can tell what I'm referring to. A namespace full of classes and functions and variables, or a class full of methods and members.

"Needing" to declare variables to avoid using them later is saying that the programmer (or system development coordinator) is too slack to keep track of things. (the same goes with placing a closing bracket on it's own line - just place it two spaces out at the end of the last line in a code block, just make SURE to INDENT, as this is what truly makes the code easy to read and keep track of - why I like F#) Try programming in pure assembly language for a while, and strengthen your programming organization skills.

And playing around with the dynamic aspects of the language? Again, use the language as it was designed to be used. There is more than one way to skin a cat, and more than one way to write a program's logic to accomplish a task. Some are easier to read by humans, some are easier to update and expand, some are faster to run, some take less memory. Which of the these can you not accomplish by not having a "dynamic language" as YOU define it?

Security flaws are found everywhere. But I can't comment on "Zend" fixing them. But do they "own" the language? Or is it managed by a community?

Unicode? Doesn't PHP have functions to handle 2-byte character strings? And my current project uses unicode characters sent from the user's browser - the infinity character, unicode &#8734. I never refer to this as an entity or character code in my source code. I embed the character right into the HTML without using an "entity" ( &#8734 ), and read it's value sent through the $_POST variable as the infinity character embedded right into a PHP string. tsWebEditor allows me to enter this character right into the source-code text, and I save it as UTF-8. PHP reads it fine. I don't use the two byte functions.

I use PHP because I was able to walk right into it, and it is developed FOR web pages, and that's what I used it initially for. PEAL I've "heard" is a nice language, but as it was not designed to interface with the web, it must do those things in a "convoluted way". I picked up a book on Java, but didn't make it far enough to even write a "hello world". So much to learn just to wrote a few lines! When time permits........ And yes, it's easy to install locally, with Apache. That makes it somehow less worthy? More Cheesy? Less mature? Just another reason to like PHP. PEAL is on my public server, the place I started off with before I found the XAMPP package, but I still chose PHP as the language of choice, and I'm glad.

As I said, YES it is a "web language" designed from the get-go to work with HTML pages. That can make it a BETTER desktop language. Huh? By installing a local server (try the XAMPP package) or as Manual has noted in a previous post, PHP will be its "own server" in the future. Then you need not worry about your problems with $_SERVER variables being lost, and the GUI you develop in the oh so familiar and cross platform language of HTML works on your Windows, Linux, Unix or Mac Desktop, as well as your public web server.
Or just use a text-editor with global search and replace (around since at least the 1970s - before I started) and change your $_SERVER variables in all your files (tsWebEditor can do this to all files in a directory without you needing to open them) to something like $_GLOBAL['server__']. Then at the script's onset, check for the existence of $_SERVER and if it exists, assign it to $server__; else open a given file on the local hard drive that contains the serialized version of $server__ from last time, and read it. Don't forget to set up a function to be run automatically at the termination of the PHP script (I forget right now how to do this, I've only read about it) that saves the variable $server__. Just a bit of code added to the beginning, not a complete rewrite, or even tedious editing. A bug or two may pop up, but you can track down a couple and fix them without complete rewrite of the logic.

I'm currently writing a desktop application in PHP-HTML-JavaScript that develops knock-your-socks off graphics (beyond Open Office Draw, Corel Draw, and I think Adobe Illustrator), possible because of the GD extension native to most PHP packages. Learning to work with .png file formats would be a whole new project I doubt I would tackle head on without dire need, just due to lack of interest if nothing else. Somehow I doubt that Java or C# will give me the tools to work natively with .png alpha transparencies, but I admit I don't know those languages.
(look for my Rainbow.php class to be added to this site soon... :)
The beauty of it is, I can share the source code "as is" with anyone, or put it on my public server and share it's functionality.
And as you say, PHP is very easy to read and write. That makes it even more shareable. Because a language doesn't do what you what it to do the way you want it to do is again, YOUR opinion, and in my opinion, whining. EVERY problem is solvable with assembly language, and it has NONE of the language constructs that you complain about that make programming "easier". In reality, high level languages makes the TASK of PROGRAMMING "faster", --not-- easier. Projects like "High Level Assembly" (HLA) can add speed to your task of writing the script, and without the "limitations" imposed by other languages, your script can do anything in any way, including creating it's own "objects" of any type you could possibly imagine: and the #1 axiom of writing a good program is creating data structures that makes the program work as smoothly as possible, not the other way around (though sometimes you're stuck with bad formats or two optional formats that each works well with one idea, and bad with another). But don't whine about scope! We don't need no stinkin' scope!!! In my opinion, we should ALL be writing code in Assembly Language using HLA, and the library of Open Source functions (for GUIs and whatever else) should be vast, and links into OS processes and services should be fully documented to all users. Ah, heaven, I'm in heaven...

This article was not really about saying that PHP is perfect and does not need improvements, but rather to clarify some misunderstandings that make people believe wrong things about PHP.

Still, I did not have any difficulty to install caching extensions without further community help. I use eAccelerator, and it is completely straightforward to install. It is just a matter of doing configure; make; make install. More details can be read in the INSTALL file, at least for Linux or other Unix-like systems.

Still if this is too hard for you, I am sure you can always pay somebody more qualified to do it for you.

As for your other complaints, they seemed forced excuses to rant against PHP. It would probably would help you if you lower your gun and be willing to learn the things that work differently in PHP from whatever is your favorite language.

Alastair is bragging too much. What creature a language has made them. Bad attitude, irrational.

Actually there is already a PHP compiler - PHC - that compiles PHP code into extensions. It still relies on the Zend Engine, but it seems to be what you want:

phpcompiler.org/

It was mentioned in the PHP compiler performance article:

phpclasses.org/blog/post/117-PHP-co ...

You da man, Mr. Lemos, you - da - man!

Thanks!!!