News for hackers. Stuff that matters.
Re:If it aint broke don't fix it. A PHP (horror) story by fsk on Monday May 04, 2015 @09:58AM (#9486142)
What's the #1 Google result for T_PAAMAYIM_NEKUDOTAYIM? It didn't bother me the first time I saw it. What's the problem?
Re:If it aint broke don't fix it. A PHP (horror) story by ziotom78 on Monday May 04, 2015 @11:00AM (#9486543)
I think the point was that any parser should always produce clear messages. What it should not do is to print some nerdy text and require the user to have an internet connection and Google just to understand what the compiler was expecting.
Re:If it aint broke don't fix it. A PHP (horror) story by thaumaturgy on Monday May 04, 2015 @01:57PM (#9487814)
> any parser should always produce clear messages.

Or any program.

When wearing my sysadmin hat, about 75% of my time is spent chasing down the causes of vague or unhelpful error messages, and 25% is spent actually improving the server environment.

Re:If it aint broke don't fix it. A PHP (horror) story by gct on Monday May 04, 2015 @12:29PM (#9487168)
Referring users to a third party to understand your error messages is an asshole thing to do. It's just another flavor of the typical "you're doing it wrong" shit we always get from PHP.
Re:If it aint broke don't fix it. A PHP (horror) story by cbaleanu on Monday May 04, 2015 @05:12PM (#9489235)
My thoughts exactly. First time I saw that lame error message I thought it was an April Fools joke.
Re:If it aint broke don't fix it. A PHP (horror) story by cfinke on Monday May 04, 2015 @11:01AM (#9486552)
> What's the #1 Google result for T_PAAMAYIM_NEKUDOTAYIM?

This blog post is.

> What's the problem?

Some of us encountered it back before Google returned helpful results about it.