[xd]

soc88, dude, can you stop with your personal anti-PHP agenda. You are bringing NOTHING to the table.

> - Why is the documentation in such a bad shape?

The documentation is up-to-date AND in good shape.

> - Why aren't there any established processes in place to prevent repeating mistakes (see above)?

What kind of processes? The documentation clearly lays out pitfalls and problems to watch out for.

> - Why are large parts of the implementation barely maintainable?

What parts?

> - Why is the ecosystem still in such a bad shape?

What part of the ecosystem? It seems fine to me.

> - Why is the core team spreading bad practices instead of good practices?

Seriously, give me some examples of these bad practices, please.

> - Why is the language so unbelievable slow?

In comparison to what? For the class it is in, it is very fast.

> - Why is the runtime and the garbage collector of such bad quality that it is completely impossible to run sufficiently complex applications over a larger period of time?

Erm, I've run long running processes for years. There was once a problem with circular references but this has long since been resolved.

Also, you showed your lack of understanding of PHP in a previous response (http://news.ycombinator.com/item?id=4198984) to mine where you where unable to distinguish between the Apache and Cli PHP SAPIs.

[ldng]

> - Why is the language so unbelievable slow?

In comparison to what? For the class it is in, it is very fast.

PHP is what I would an intertwined language as quite often people don't separate PHP the language, PHP the included battery (aka the standard library), PHP the easy deployed script and PHP the web tool at core.

It's both a curse and a blessing IMHO. It easy to ignore the differences but hard to learn about them later and the official doc not really teach about it doesn't help. I am not say the doc is bad, just trading off clearly for easiness. It probably helped PHP grow so popular.

As for the quote, PHP the language _is_ slow but the mitigated by a fast standard library (mainly C function wrappers). That said, PHP 5.4 is faster than ever.

[mgkimsal]

> - Why are large parts of the implementation barely maintainable?

What parts?

------------

Possibly the part that essentially required \ as a namespace separator. This was because ZE2 simply couldn't be coaxed to deal with a different separator, and no one has yet spearheaded a ZE3 to take the lessons learned over the last decade and revamp the internals to allow for more modularized growth/modifications.

Most other languages have had underlying VM changes which allow for better language enhancements. Every PHP language change in the last 12 years has had to work within the confines of the existing VM, and I've not seen any substantial changes to it in 12 years.

[xd]

Thanks for your reply. I remember the ordeal on the internals list .. but what does that have to do with maintainability?

[mgkimsal]

It may be splitting hairs, but I don't see anyone able to step up and address the mods necessary to ZE2 to support any new features, ever. We're basically stuck with ZE2, and we (as a community) make the best of it. ZE isn't 'maintained' actively, it just exists, and I haven't heard of any plans for an overhaul or new version. Compare that progress to the JVM and .NET CLR over the last 12 years.