>It attracts people too stupid to realize that their own level of knowledge should make them avoid teaching others.
There are many very, very smart people that try to teach others as a form of their own expression and learning. People coming from other programming languages that are extremely talented in that language, often take on this role as they are confident in their abilities. That doesn't make them stupid, nor should it disqualify them from attempting to teach or help others.
> As soon as someone points out an issue they almost immediately switch to "LALALALALA I CAN'T HEAR YOU!!!".
I don't think that's a fair assessment at all. In my experience dealing with precisely that situation, I find that most are actually very willing to accept and admit to their fault. Even in the chat room, over the many years I've been there, there are far more people willing to accept their incorrectness over people who take offense.
> People coming from other programming languages that are extremely talented in that language
PHP wouldn't be this worse if this was what would actually be happening, because these people would assess the situation and take away the control from the PHP team, due to its inability to do its job.
More realistically, people see PHP and run away screaming. The only people using PHP are those unable to see how unbelievably bad the language and its libraries are designed and implemented.
> I find that most are actually very willing to accept and admit to their fault.
- So why is the standard library in such a bad shape?
- Why is the documentation in such a bad shape?
- Why aren't there any established processes in place to prevent repeating mistakes (see above)?
- Why are large parts of the implementation barely maintainable?
- Why is the ecosystem still in such a bad shape?
- Why is the core team spreading bad practices instead of good practices?
- Why is the language so unbelievable slow?
- 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?
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.
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.
> - 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.
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.
There are many very, very smart people that try to teach others as a form of their own expression and learning. People coming from other programming languages that are extremely talented in that language, often take on this role as they are confident in their abilities. That doesn't make them stupid, nor should it disqualify them from attempting to teach or help others.
> As soon as someone points out an issue they almost immediately switch to "LALALALALA I CAN'T HEAR YOU!!!".
I don't think that's a fair assessment at all. In my experience dealing with precisely that situation, I find that most are actually very willing to accept and admit to their fault. Even in the chat room, over the many years I've been there, there are far more people willing to accept their incorrectness over people who take offense.