Comment by randomdrake | Hacker News Reader

Comment by randomdrake | Hacker News Reader

I find it surprising that no one has mentioned, what I consider to be, the best source of information and help with the PHP language out there.

The ##php IRC channel on freenode (1) is an absolutely incredible resource. I've idled in there for many years now and the amount of good, relevant, and accurate information that can be obtained in there is incredible. Whether you have been programming for 5 days or 5 years, simply hanging out in the channel for a couple of days can offer insights and tricks that you may have never known about.

Over time, the folks there have compiled an absolutely excellent Wiki (2) for developers; old and new. In addition, there is a wonderful list of general do's and don'ts for PHP application development. (3)

Time and time again, we get folks in there who are using outdated technologies (hello mysql_* functions) or just awful tutorials or resources and they get turned around in no time.

Disclaimer: as the author states, there are many self-described experts in PHP and they do, occasionally offer bad advice. However, it is rare for the bad advice to go unchecked in this IRC channel so I can still recommend it without worry.

[1] - http://freenode.net/

[2] - http://wiki.hashphp.org/Main_Page

[3] - http://hashphp.org/

Freenode's IRC channels tend to be very good. ##c also has great resources on the C languages, for instance.

This may be deeply stupid, but I'm new to IRC, and I'm getting a message on Freenode saying "Cannot join #php (Channel is invite only)". Am I missing something? Or is it possible to just watch the discussion without participating and that doesn't require an invite?

Freenode uses ##<channel> to refer to "non-primary" channels. Regardless of what that means (I don't really know), the channel you're looking for is ##php.

I believe the room name is actually #php (hash php) so you would join ##php.

http://hashphp.org/: What should I know about building a website? is an amazing resource. Thanks a lot.

That's a very good point. I keep forgetting about hashphp... Perhaps that model is better (a semi-curated list of tutorials off site)...

> there are many self-described experts in PHP

I think this is the real problem of PHP.

It attracts people too stupid to realize that their own level of knowledge should make them avoid teaching others.

As soon as someone points out an issue they almost immediately switch to "LALALALALA I CAN'T HEAR YOU!!!".

I guess people are the real problem of PHP. But then again: people are the real problem of everything.

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

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

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

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.

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

Reply on news.ycombinator.com