Posted: 2013-09-09
Category: PHP

Anyone who has mentioned PHP Fractal of Bad Design to me knows I don't give it much credit. It's a list of complaints about loose-typing in general, some "its not Python" rants, lots of complaints about bugs that have been fixed, suggestions PHP doesn't have features which it has had for years and a few examples of quirks that need to be worked on.

Pretending PHP is perfect would obviously be ridiculous - it has its problems - but a list of issues being compiled gives interested developers a great chance to fix things. One such resource is PHP Sadness brought to you by Eric Wastl, to document valid bugs and freaky shit that PHP does.

Whether it be the chicken or the egg, these items are one by one being scratched off as active core-contributors make RFCs and fight the good fight to get them merged. Think of this resource as a bug report system, but one that is entirely outside the control of people who might decide to just close it with a "wontfix" tag. If any of you guys have valid concerns with PHP that have been shot down or left inactive, you should consider sending them to Eric with full examples and use 3v4l.org to test the output of 80+ PHP versions.

Sadly it is not always easy to clear these items, or add new features in general. As somebody who has followed internals (and been hearing tales of woe from others) for a while, I've seen so many conversations with truly bizarre, irrelevant and trolly responses coming back from everyone all the way up to Rasmus himself. It was this sort of trolling and bullshit that lead to Anthony Ferrera's recent (and completely understandable) departure from the core.

An Example

Looking at the top section of PHP Sadness are:

Those are both essentially the same "sadness" being reported, that an unrecognisable token used to display instead of showing something useful. For those of you who don't know, in PHP T_PAAMAYIM_NEKUDOTAYIM is the token name for "::", the static separator. It's Hebrew for double colon.

Both of these have been "fixed" in PHP 5.4, but only partially. There is a little caveat in both:

PHP 5.4 still calls it T_PAAMAYIM_NEKUDOTAYIM, but includes '::' in the error message, making it only mildly less confusing

Everything in PHP is broken down from literal symbols into tokens, like T_IF, T_ELSE, T_STRING, T_SL and of course the crazy-looking T_PAAMAYIM_NEKUDOTAYIM. These are then handled by the parser, and if an unexpected order of things turns up you get an error message. That error message always used to be:

Parse error: syntax error, unexpected (T_PAAMAYIM_NEKUDOTAYIM)

Since PHP 5.4 the output is:

Parse error: syntax error, unexpected '::' (T_PAAMAYIM_NEKUDOTAYIM)

That is a little victory for sure, but as Eric points out it's pretty damn confusing to still see that token name in there.

Why is it not just:

Parse error: syntax error, unexpected '::'

Or better yet:

Parse error: syntax error, unexpected '::' double colon

I asked on IRC and got this answer:

ekneuss: philsturgeon, the token name was kept around because conservative people felt that removing it would be too much of a change, and might confuse users.

I understand that to get the "::" in the guys implementing this RFC had to keep displaying the token name to appease the conservatives on internals. That is a compromise and it is fair enough on their part, but as a PHP user (not a core contributor) I do not feel like it is of any relevance to me whatsoever.

In other words: I give zero fucks about the name of the token - especially if it has a non-standard name. I understand that core developers want that, but it could easily be an extra logging output item, or some sort of default-off dev switch in the parser, or something.

I was interested, so I started digging into this decision and I came across an absolute gem on the mailing list.

A Trolls Tale

A battle of epic proportions was held on PHP internals about this back in 2010, started off by ##php Freenode IRC operator Chad Minick, suggesting that T_PAAMAYIM_NEKUDOTAYIM should be renamed. I don't care much about having it renamed because the core of PHP can do what it likes. I simply care about the separation of internals and user display.

For the same reason the people using one of my web-apps don't need to know what I name my variables, I am equally uninterested what the parser decides to nickname a semi-colon or an angle bracket in the parser.

This conversation was a perfect example of internals trolls going full-blast, and is exactly the sort of situation that lead to Anthony's rage-quit. Let's have a look at the "highlights" of this conversation:

Chad opens with:


This has to be THE most asked question by new php developers when they come across it. Can we please change the token name to T_DOUBLE_COLON so I don't have to hear about it constantly?

Those that disagree don't do enough PHP support to know how often it is asked. it's worth it.


Probably not a great way to launch in, but he makes a valid point. His position as an operator on ##php means he would know what people are asking, and trying to resolve issues that bring up the most requests is a reasonable aim.

Daniel P. Brown is the first troll to take aim:

Someone disagreeing with your request to change something does not correlate to their doing "enough PHP support." There are many reasons to disagree with a change request, no matter how much any one person thinks of it as a necessity or an improvement.


His accuracy points must need leveling up, because that is not even vaguely what Chad said.

James Butler takes his turn (after a bunch of people argue about the fact Chad didn't have his full name displaying on the first post properly) and uses the good old fashioned "if it aint broke don't fix it" attack:

Why should this be changed? Is it broken? Is it something that 1 second on google can't answer? If somebody is advanced enough to be using classes (I think about the only time you would use a double colon) then they should know what it means.


Even in 2010, referencing a static class is hardly considered "advanced" usage. Copy, paste, mistype, T_PAAMAYIM_NEKUDOTAYIM. And it is broken, if you have to Google a parser error because its written in Hebrew then the parser is fucking broken.

This is roughly where PHP's closest thing to a BDFL Rasmus Lerdorf beams into the conversation with a little history:

There are two reasons this term will stay. It is a tip of the hat to the amount of PHP work that came out of Israel, and it is a good reminder that there are a lot of other languages in the world. People whose first language is not English, myself included, are forced to work with unfamiliar terms every day. I wouldn't mind having a few more non-English identifiers in PHP actually.

Well, and a third reason, I like it.


There are three things wrong with this.

  1. I'm really glad to hear that international contributions are doing well. This is a great sign that our community is wide reaching, but we're not naming a fucking bridge here. A link in some credits or a README would do a wonderful job of thanking people for their contributions - like every other open-source project ever.
  2. The fact that many programmers are forced to learn English (or at least recognize English keywords) is a tricky subject, but lets stick to forcing one language down peoples throat and not randomly make different keywords in different languages for the sake of it.
  3. Plenty of people clearly don't like it, so how about a vote?

As I said above PHP's users do not give a shit about token names, so the fact that this bizarre message is being displayed to every single PHP user just because the founder of the language likes it is ridiculous.

Let's keep going.

Stan Vass appears out of nowhere in a flash as a thunderbolt claps around internals, temporarily stunning the trolls with a flash of fucking logic:

It's amazing to me this has become such a long discussion. The facts are simple:

1) People don't ask for the other parse errors even half as often as they as for T_PAAMAYIM_NEKUDOTAYIM 2) They do so because it looks like gibberish to them, so it looks unlikely
to be a common thing you can Google, nor it gives something recognizable to start with
3) Yes, to all who are not sure, more people know English than Hebrew.
4) Yes, we all acknowledge it's an easter egg joke that refers to the creators of PHP. But that particular joke has outworn its welcome in the community after repeatedly causing support issues.

T_DOUBLE_COLON already exists as a constant in userland, so the jump to it won't be an epic change. Let's do it as a proof that we're not a nerd gridlock bound to argue forever about even the most minor and obviously positive changes PHP can implement.


Boom. Mic-drop. PEACE!

Right? Nope.

Dennis Haarbrink has this to say:

Come on people, what exactly is the problem with a once-in-a-lifetime investment of 5 seconds of your time to google some stupid error message. Something you, as a developer, spend your life doing.

Please, stop complaining about a minor (yes, it is minor, use the fricking search engine!) annoyance and accept php's heritage.

And please understand, I do get where all the opponents are coming from, it is an unnecessary complicated error message (I agree that the language argument is a moot point, in the world of internet and programming in particular, English is the standard), but you google it once in your life and then you 'forget' about it. And if you can't remember the meaning of something like that, I hardly doubt you'd be a decent programmer anyway.


Really Dennis?

What is the problem with Googling a "stupid" error message? _The fact that I have to Google a stupid error message is the problem with having to Google a stupid error message! You even call it an "unnecessary complicated error message" in the same post.

Minor problems are still problems.

An excellent retort from Alexander Schrijver combines humor with "you're wrong" perfectly:

Its a minor change and an annoyance to a lot of people. Yes, by not changing this you'r annoying thousands of people.

This isn't an easteregg either. This is a "lesson" as someone explained. eastereggs aren't visible to normal users.

If you want teach people about Hebrew you obviously can do so. I don't see how that is the goal of a programming language, but that is an other issue. But don't come along and insult us with this bullshit.


Side Note: This line of conversation was mostly being slammed down with suggestions that the entire thing was "Cosmetic Nonsense", and instead folks were redirected to the Lemon parser, which has been marked as "In progress" for years. I asked around and it turns out it was abandoned, so I poked the author to change the status to Abandoned so folks know whats up in the future.

The whole idea that the ONLY way to resolve this is to go with a brand-new parser is potentially ridiculous. They were really suggesting there is NOTHING in the parser that could easily do a backwards look-up on the parser to say T_PAAMAYIM_NEKUDOTAYIM is "::", and output it as part of the error?

Andi Gutmans casts a pro-PAAMAYIM attack along with some elitist drivel:

The first google entry when you search for it gives you the answer. It is actually unbelievably easy to find the answer via search. If a new PHP developer can't find it then maybe they shouldn't be writing code.

This is a piece of history from the PHP 3 days and think it adds some character, a story (and history) to PHP. Don't think we should take this out after a good 12 years.

I would prefer this was not changed.

Oh good, it adds some character? That seems like a valid reason to keep speaking Hebrew to our international community for no reason, whilst keeping PHP the laughing stock of the entire same international community - except for some of PHP internals crew. Thanks for that Andi.

Even PHPUnit PHP-extraordinaire Sebastian Bergmann and phpDocumentor member (and Editor of PSR-5 which I'm currently listed as Co-ordinator for) Mike Van Riel support[ed] this argument.

It might be part of PHP's history, but this is one of this memories that would be nice to move away from, like how your granddad probably doesn't still wear that nose-ring and crazy tattoos he had when he was a rebellious punk teenager.

And if we need to keep the shitty tattoo, can we at least make sure it's not visible to everyone?

Chad is revived and comes back to fight on:

It's the same argument everyone else is giving, and really it all comes down to this.:

Nostalgia is valued over clarity and consistency.

Do you guys REALLY want to claim that?


That produces a lot more "it aint broke so…" responses so I wont bother to highlight all of them. It's said by 4 different people and I'm getting bored of copying and pasting, but James Butler returns with his second "if it aint broke". He needs that printed on a t-shirt or something:

If it ain't broken don't fix it.

Change for the sake of it is a bad thing. It does things like introduce bugs etc.

Q1) is it broken? Q2) if yes exactly what is broken Q3) does the proposes fix solve the root cause?

I'm not sure changing the token name is the correct fix to people not knowing what the error means.


Let it be noted that at this point MULTIPLE people had suggested not actually renaming the token, but changing the error message.

Chad keeps on pushing through, like a snow-plow running on jet fuel

Q1) yes, it is broken, people have to Google or ask around for a very unclear error message when for the most parts errors are (and should be) self explanatory.

Q2) Two things are broken: Either the token is named badly, or the token names shouldn't show up in error messages at all and be replaced with something a bit more friendly.

Q3) those two fixes above would probably fix that, yes.

What is so hard to believe when people see UNEXPECTED T_DOUBLE_COLON on LINE 23 they are gonna look for a double colon on line 23? because they DO.


Right. If no change to the token is gonna happen, at least hide it. I read this as "lets do SOMETHING instead of just arguing!!". And yes, the fact that what should (and obviously could) be such a simple error message requires a google is an error in itself.

James Butler tries saying something different to his usual slogan but it doesn't really work out:

Are you supporting users who you provide a shared hosting embodiment too, and do you control binary installations on the enviroments? If so then possibly patching source for you installs maybe the easiest and quickest solution. If we knew the nature of your support requirements, then we could possibly suggest a better solution or be won round. (although internals isn't the place for that really)

This is not meant to bait but possibly an improvement in your support process or docs might yield a solution?


Really? If you don't want error messages in Hebrew you should patch PHP and install this custom version on your own server, and maintain it with updates, etc.

Fuck everything about that. I'm stunned.

A Hero Emerges

When all seems lost, a savior swoops down from the clouds riding atop a magical griffin. He is known to some as "Felipe Pena", and on his mighty sword was inscribed a phrase which was unreadable to the trolls. It was an unknown language, but after a quick Google search the trolls learned the message turned out to be Hebrew, and translated roughly to "Let's just fucking fix it instead of bitching about things for a solid month."

Instead of renaming the token, I prefer to associate a literal string to each token, to have a legible error message, without the T_ being shown.

For example, we could use in the Bison grammar file: %token T_PAAMAYIM_NEKUDOTAYIM "::"

So that the error message become:

$ sapi/cli/php -r '::' Parse error: syntax error, unexpected :: in Command line code on line 1

Instead of the known "unexpected T_PAAMAYIM_NEKUDOTAYIM" one.


Rasmus agrees:

Years and years ago that was the intent. I didn't think there was a clean way to do that in yacc though.


Stunned silence...

Ferenc Kovacs is so confused he has to ask if its really happening, then posts a summary - which identifies all of my feelings about this thread:

Thanks Felipe, you are my hero. Anybody else thinks that this thread is very similar to the last array dereferencing discussion? http://www.mail-archive.com/[email protected]/msg46789.html

Somebody brought up the idea, most of the veterans tried to dismiss without discussion, pointing out, that its an old topic, and nothing will change, status quo, others tried to bend the thread to the lemon patch. and Felipe solved the original problem that everybody thought impossible, or much harder, than it was actually.

so I think we should ask Felipe more about the unsolvable problems in PHP, and maybe we shouldn't stop discussions about old topics, because maybe the environment around the problems changed with time.


And now, PHP 5.4 has literal symbols in its error messages.

If anyone would like to read the whole thing you can see this madness in its entirety here.


This tale was brought to you to highlight some of the top-level pointless trolling that can be found perpetuated by SOME of the core developers of PHP, in a bid to help people understand why some things in PHP are the way they are. If anyone was confused about Anthony leaving, they shouldn't be anymore with shit like this going on. This was by no means an isolated incident.

Not everybody who disagreed with this suggestion was being an idiot, or a troll, but there were certainly a few contenders.

Return of the Trolls

Recently something pretty similar has been happening with Named Parameters, but Nikita is still doing his thing - and he's doing it well. RFC means request for comments, its a place for discussions to be had, merits to be discussed fairly and pros/cons to be listed and understood, not a place for Status Quo fans to gang up on purveyors of change and improvement for the sake of it.

Anthony: We feel for you buddy. Every PHP developer I've spoken to since your decision to go is sad to see you leave. Internals needs more like you, and less of the "if it aint broke" jerks. We don't need things to be recoded every week, but we certainly want a little more progress than maintaining bullshit Hebrew error messages because nostalgia is fun for a few core contributors.

The Bright Side

This is a good time to point out, I'm extremely grateful for the hard work of anyone contributing on PHP internals with useful features and constructive discussion. To name just a few (in no particular order): Sara Golemon, Nikita Poppov, Igor Wiedler, Xinchen Hui, Ralph Schindler, Zeev Suraski, Pierre Joye and Andrey Andreev, keep it up. We lost one, but we have plenty more.


Jesse Donat


You keep calling it Trolling, but I'm not sure you know what that word means.

Trolling is actively trying to make someone mad. Bringing up reasons why you would personally prefer something to stay the same is not trolling.



> In Internet slang, a troll (/ˈtroʊl/, /ˈtrɒl/) is a person who sows discord on the Internet by starting arguments or upsetting people, by posting inflammatory, extraneous, or off-topic messages in an online community (such as a forum, chat room, or blog), either accidentally or with the deliberate intent of provoking readers into an emotional response or of otherwise disrupting normal on-topic discussion.

Go and see how many times people tried to disrupt that conversation.

"Go work on the lemon parser" "Why don't we have this token name in Dutch" "I like having Hebrew in there because bla bla bla"

Thats not a useful conversation by any means and you know it. That is trolling, and it doesn't help a damn thing.



Nice meta-troll, Jesse. And by "nice" i mean it in the original Latin sense.

Sebastián Lalaurette


Oh yes, but none of the particular examples you gave really fit the definition you copied. I agree with Jesse, there is very little trolling here if any, and your attitude may well be considered a bit of trolling as well, with your utter dismissal of any possibility of having a mix of languages used in the names of fucking programming constants:

"Oh good, it adds some character? That seems like a valid reason to keep speaking Hebrew to our international community for no reason, whilst keeping PHP the laughing stock of the entire same international community - except for some of PHP internals crew. Thanks for that Andi."

So, having English names is "normal" and having Hebrew names is being the "laughing stock"? You need "a valid reason to keep speaking Hebrew to our international community" but you don't need any kind of reason, valid or invalid, to keep speaking English to them?

Here is a little trolling for you: FUCK YOU. Fuck you in the name of every non-English-speaking coder in the world. Fuck you in the name of everyone of us who had to learn English just to be able to code a program meant to be seen and used by people who don't speak the language.

I considered googling how "fuck you" translates to Hebrew, but fuck THAT, too.



Sebastián: Yeah most of that thread was off-topic and unconstructive, thats exactly what being a troll means. You've also taken a valid conversation and derailed it into being some sort of language elitism thing, so well done on being a troll yourself.

"So, having English names is "normal" and having Hebrew names is being the "laughing stock"?"


  1. Writing an entire language in English then randomly making one token Hebrew is odd.
  2. Refusing to remove that token or replace it with an English word for the sake of consistency with the entire rest of the language (for over a decade) is bizarre.
  3. Fighting anyone who tries to add literal strings next to the Hebrew word is fucking lunacy.

Why do you have to make it about English V The World? If PHP was written entirely in Spanish and one of the tokens was Swedish I'd expect you to be confused yourself.

Sebastián Lalaurette


  1. I'm not making it English vs. the World. You are. You begin saying: "I give zero fucks about the name of the token", and then proceed to question the need to speak Hebrew to people, so clearly you were lying and you give at least one fuck about it.

  2. The opinions you quoted in the post were not off-topic (for the most part) or unconstructive. They simply presented points of view different from yours, as Jesse said. Oh, but for you they are not different points of view, they are "fucking lunacy". Very nice, eh?

  3. I am not derailing a conversation here, because I am criticizing the exact point that you are making, which is not about the token itself but about the community. I am saying that you are very wrong in saying that these people are trolling, and that you are trolling yourself. This discussion is effectively about trolling, not about the name of a constant.

Yuriy Babenko


Sebastián, could you point out the person that held a gun to your head and forced you "to learn English just to be able to code a program?" Something tells me you made that choice yourself, and willingly. Your comment is ridiculous.

Mixing languages in an English project simply makes no sense. Do you attempt to throw random snippets of C into your PHP apps, too?



Sebastian: Did you read the part of the troll definition that said this: "either accidentally or with the deliberate intent of provoking readers into an emotional response or of otherwise disrupting normal on-topic discussion."?

You might think you're making a valid point, but you're far from it.

I do not care what the name of the token is (English or otherwise) and firmly believe that it (nor any other internal token name) should be displayed to users (English speaking or otherwise).

You act like having this one random Hebrew token name is a win for non-English speaking developers everywhere. What do the Hebrew speaking community benefit from occasionally seeing an error pop up in their language?

One Hebrew speaking Reddit user had this to say:


You're defending non-English speakers everywhere and speaking on their behalf to tell me to fuck myself - which if I WAS being a language elitist or xenophobe would be incredibly respectable - but I'm not, and you're not doing a very good job of anything other than trying to make a mountain out of a mole-hill.

A) Inconsistency is bullshit. B) Nobody needs to see token names. C) You're an idiot.

Sebastián Lalaurette


A pretty weak argument, don't you think, Yuriy? Nobody held a gun to your head so that you would know what TPAAMAYIMNEKUDOTAYIM means, and here you will find people complaining about it and saying it's crazy and stupid. Somehow one decision seems more ridiculous than the other. Why might it be?

Yuriy Babenko


Sebastián, I have to admit, I'm having trouble deciding whether you actually believe the stupidity you're writing, or are intentionally trying to get a rise out of everyone.

Chad Minick


Hey this is Chad that's mentioned in the article, I wanted to say that I hope articles like this bring about change in the community somehow. I have a long laundry list of ideas I'd like to bring to the langauge, and all the trolling in internals kind of turned me off to participating more.

Roman Marintsenko


You know, when I read your post and kept seeing the word "trolling", I was reluctant to agree. From my experience, trolls are usually doing their thing intentionally.

But when I see majority of retorts discussing the meaning of that word instead of, oh I dunno, adressing the issues raised, I now fully agree with your usage. Trolls. PHP Internals trolls.



Phil, you're right on that TPAAMAYIMNEKUDOTAYIM story. But I agree with Sebastián too. You define your opinion as the right one, while others are trolls for you.

Can't say if that helps in any way to change things on internals. People won't just stop complaining and say: "yep, you're right and I'm wrong."

Joost Van Veen


The first commenter, Jesse Donat, actually provides a great example of the inproductive responses Phil is talking about. Jesse seems to think that a technical debate over the meaning of the word "trolling" is actually a valid contribution to a discussion about usability of a programming language. I sincerely hope his comment is tongue-in-cheeck.

As for outputting TPAAMAYIMNEKUDOTAYIM as an error message: I would never employ a developer to work for any of my clients, if he actually thinks displaying an error message like "Unexpected TPAAMAYIMNEKUDOTAYIM" is a good idea. I dread to think what error messages he would come up with for a user interface. Maybe something like "Value for field ILAGAYANGIYONGPANGALANSAKANYAO_MAMATAY is required".

Joost Van Veen


The first commenter, Jesse Donat, actually provides a great example of the inproductive responses Phil is talking about. Jesse seems to think that a technical debate over the meaning of the word "trolling" is actually a valid contribution to a discussion about usability of a programming language. I sincerely hope his comment is tongue-in-cheeck.

As for outputting TPAAMAYIMNEKUDOTAYIM as an error message: I would never employ a developer to work for any of my clients, if he actually thinks displaying an error message like "Unexpected TPAAMAYIMNEKUDOTAYIM" is a good idea. I dread to think what error messages he would come up with for a user interface. Maybe something like "Value for field ILAGAYANGIYONGPANGALANSAKANYAO_MAMATAY is required".



Shows the moronic nature of PHP very well.

Alexander Makarov


I think it's not trolling but a regular thing that happens to any project with history. Once the project is released, it forms a group of oldies who originally created it.

This group is trying hard not to change anything cause it could break stuff they invested lots of time into, knowing caveats etc.

Moreover, oldies remember lots of legacy stuff such as 10 years old compiler errors and it becomes an obstacle for taking new ideas in and changing existing functionality because these 10 years ago it wasn't possible or was too tricky.

Because of these oldies are the most respectful people in community (noone saying otherwise), new people are often blindly following the direction they're pointing becoming fanboys.

For any project with history it's very important to attract totally stubborn thinkers who can say and insist that things are wrong and while respecting oldies do not blindly take their opinions. A good strategy for these people is to ignore all the bullshit arguments imagining they are soulless terminator-robots taking only objective arguments and ignoring personal offence that often comes from fanboys.



Holy crap, Phil!

How many keyboards do you go through in a week??

"I considered googling how "fuck you" translates to Hebrew, but fuck THAT, too." Ha-ha - Love it! Thank YOU for making me smile. :)

Sadly, I think something was lost in translation, which is a issue I see occuring regularly on the Internet. All I see here are several cases of misunderstanding, which have just spiralled out of control.

Granted, Phil does like to rant rather passionately, but it's his process. Phil's point was that it's an inconsistency in the language that could be easily fixed to make the error more helpful, and people are making up silly excuses not to make the change, and I have to agree. I think it's no different from having inconsistent function names, isset() and is_null() for example.

This is NOT, and NEVER WAS about "which language is best", or suggesting that "English is better than all other languages", it was about CONSISTENCY.

When Phil said he gives "zero fucks" about the tokens, his point was that these tokens are internal to PHP, and we simply don't need to see them on the frontend at all, and this makes complete sense. All we're worried about is our own code, and the API that PHP provides for us. We don't care how PHP is implemented. It just so happened that the internal token names were named clearly enough for us to understand what they meant - apart from one...

Hopefully that clears that up.



Maksim: "You define your opinion as the right one, while others are trolls for you."

Disagreeing with me doesn't make somebody a troll. Taking a conversation and derailing it with bullshit and off-topic conversation makes them a troll. Talking about the maning of the word troll is also hilariously trolly behvior, as it's derailing from the point: that conversations in internals are never linear and are full of shit.

An example I posted on Anthony Ferreras blog is this:

Hey what do you think of this hammer? I want a spanner. I prefer to call it a wrench! What is a hammer. How do we even know this hammer is useful? What should we call this hammer? Do hammers work well with cheese? I don't know anything about hammers, but the spanner should be blue. I dont like blue. STRAWMAN!!!

I'll call them trolls, even if I am indifferent about hammers, spanners or wrenches.

There is a massive difference between voicing an opinion and being a troll. Do you see the difference/

Alexander: That is an interesting point of view, thanks for commenting. I understand that we need some of the hardened veterans to keep PHP a mature language, keep BC important, who know why nd how old things are and don't want to change things that arent broken, etc and I tried to give that line of thinking a hat-tip with this sentence:

"We don't need things to be recoded every week, but we certainly want a little more progress than maintaining bullshit Hebrew error messages because nostalgia is fun for a few core contributors."

Look at Rasmus in this conversation for example. Right at the start he gives 3 reasons for never changing this, then after pages of bickering he just says "Oh yeah thats what we were gonna do" when a solution is given. If he were to have said "Lets try and find a way to show the literal too, thats always been the plan and I guess we forgot" then that conversation would have been about 6 posts long.

Everyone who dived in to try and shut Chad down for wanting to change it (or hide it, because they ignored the fact he said hiding would be fine which is ignorant and trolly in itself) was not just blocking change for good reasons, but using a negativr attitude to essentially bully Chad out of the conversation.

Daz: Right on. I think people assume im sat here throwing coffee at my screen while I write this stuff. And yeah, it almost seems like Sebastián just read a few words from various different paragraphs and decided to construct something offensive out of it.

Andrey Andreev


I wouldn't call it trolling either, but that's far from the main point of this article and it's sad that almost all of the comments are about what trolling means and not the real problem.

The real problem is that php-internals and everything around it is a <b>very hostile</b> environment. You have to literally fight the system in order to make something positive with it.

Phil has actually credited me as somebody contributing to the internals (thank you), but he deserves far more credit for all of his work in the PHP community. My only contribution (or at least the significant part of it) consists of just 8 lines of code that are so self-explanatory, I almost feel like an idiot I had to go though all of the bureaucracy surrounding a bugfix.

I was asked questions that were already answered, I was told to not fix what's not broken and I had to write <b>pages</b> of text on GitHub, wiki.php.net and php-internals at the same time. Thank God they liked the idea and were just following their processes instead of trying to derail it. It's just counter-productive for any improvement that you'd like to help with.

As for English vs. other languages, get over it people - it's just the way it is. It's the same problem with time zones and metric systems, we all hate the differences and yet we haven't done a thing to solve those problems. Having a default language in programming is actually a progress towards something. If you ask me, English should be the only language some day, for everything. Not because it's my native language (it's not), not because I like it (I used to hate it in school), not because it's written or spoken by the largest number of people (AFAIK, it's not even in top 10), but simply because it's become a norm and a must-have skill already. Deal with it.


Márcio Almada


I hope this exposure brings some change to community. Thanks for this post!



The point of trolling is spending time on something that is obviously not worth yours in order to incite an argument that never needed to be. The point of constructive criticism in software design is to save other people's time where yours was lost. If an annoyance causes you to expend time and emotional effort working around it, you may wish to see it fixed so that others may benefit. This is as much an altruistic intent as it is aesthetic.

If the abnormality did not waste your time, then whether or not it remains should be immaterial to you. The fact that people not involved with development would even bother spend their time vocalizing their disagreement is therefore confounding. That the detractors changed their tune once a simple fix was proposed reveals the banality of their efforts.

This story isn't about the token at all, really.

James Hansen



My wife calls me a troll cause I live under the bridge, but not like the ones that are talked about here. haha!

Forgive my language, do not sweat the fuckin small stuff.



Internals should move to forum, too many people posting to internals and no ability to restrict access to those, who abuse it :(

David Rolston


While I have to agree that intelligently stating one's preference, albeit not necessarily an effective argument, does not make said argument "trolling". I have been a member of any number of infamous web forums, where trolling was perfected long before there was a term for the behavior.

There has long been a prejudice in the web development community against PHP developers. As referenced, the ..badfractal article is an example of that prejudice... "if you use PHP, or even dare I say it, 'like' the language, you must be an inferior developer. Part of the problem has always been that it is darn easy for non-developers to get something accomplished with PHP, even if their code is embarrassing and chock full of logic errors, holes and security problems. For this reason, I believe that the expert practitioners in the community cling to PHP's arcana as a way of seperating themselves from the great masses of amateurs that make the language so popular. When there's such a low bar to entry, it's understandable that there's a reluctance to cater to laziness and willful ignorance. I have seen people practice this approach on a near daily basis via my participation at one of PHP's longest and most established help forums, going on 12 years now, and it only took a few years before I was tired of throwing fish to hungry cretins, when it is so easy to differentiate them from the people you know from experience, are their to learn to fish. I think this was the point Gutmans was making.

With that said, the complaints about the internals list and getting involved in general with the PHP core has existed for a long time. Many things have changed and evolved, and in the era of github, I believe that PHP will need to evolve as well.

This article does point out that common sense and persistence is sometimes required to get the ball rolling, and I'm happy to see that there is new blood continuing to enter into the discussion. Many of the people involved in the creation and maturation of PHP are entering middle age now, and it gets harder and harder to keep yourself open to new ideas, or to question your beliefs. More than anything what this article proves, is that while it may be slow going at times, the PHP core developers are reasonable pragmatic people, who have always place a prioritization of productivity and extension of the platform above that of idealistic pursuits. For this, they have mostly been derided by the communities which at the same time envy PHP's success. So they have some foibles? It doesn't make them trolls -- just human beings.



David: Thanks for that, you make a lot of great points. I have to stress (again) that "intelligently stating one's preference" or being "reasonable pragmatic people" does not a troll make you. Absolutely not, that would be wonderful - but it's rarely the case. Your sentiment is appreciated, but it does not line up with the content of this discussion at all:

  1. Shouting "if it aint broke" over and over again without listening is not pragmatic or intelligent.

  2. Using "I like it" or "because nostalgia" as an argument for keeping something inconsistent is not pragmatic or intelligent.

  3. Considering it a problem that users have to Google search a token written in Hebrew to find a parser error is not an "idealistic pursuit".

  4. Refusing to hide something that no user ever needs to see is not helpful to anyone.

  5. There are people in internals who ARE productive, and who ARE putting useful extensions above "idealistic pursuits", but they were not the people trying to slam this thread from the start.

I understand priorities and focus but if this is a trivial fix which can be easily achieved (as it was proved to be) why fight it so hard? Why did everyone try to derail the conversation instead of providing a valid reason against it (which nobody EVER did)? The implementation didn't take long once somebody had an approach, so why not try to find an approach instead of trolling so hard?

Greg Militello


Personally I don't really regard either side as trolling. They both in fact have points, even if one side has fewer bonuses. The real key in my mind is to take the pro's and con's, and allow people to weight them on their own and come to an educated and informed decision. Also, there are multiple suggestions, and all of these should be made independent:

Suggestions I've seen: 1.) Rename TPAAMAYIMNEKUDOTAYIM to TDOUBLECOLON; EG: "Unexpected TDOUBLECOLON on line 123"

Pros: a.) Internal code consistency.
b.) If changed no magical yacc implementations need to be made so that users can make sense of an internal code symbol. (However, this implementation would be useful on so many levels, and for other reasons). c.) Make the proper grammar people happy, even the Hebrew speaking grammar people. d.) ? Add your points here

Cons: a.) Bugs. I am sure there is some obscure embedded reference buried in the internals, or some dependency that will just break. PHP is huge. Even minor changes can have impact. b.) We lose some form of "connection" to the past in PHP to its Israeli roots. (Yes; I know you'll cite the reddit post, I found that interesting. My point is to outline as best as possible). c.) ? Add your points here

2.) Stop displaying internal symbols to end users; EG: "Unexpected (::) double colon on line 123"

Pros: a.) We could have errors that are even less cryptic across the board. Symbols could be translated to human readable strings. This has other advantages, and could expand further into say translating symbol strings into other languages. But I this is unrelated, and extremely tangental. b.) No user needs to see 'T_*' when they could see the string contained by *. Or even a literal representation. c.) Some form of "connection" to the past in PHP to its Israeli roots is retained. d.) ? Add your points here

Cons: a.) Bugs. Any change can have bugs. b.) ? Add your points here

3.) Insert your cool idea here. But do so from as objective of a perspective as you can maintain while the internals monkeys are throwing poop at you. Continue to update your list as good/valid suggestions come in. Win.

Now, my personal feeling is that BOTH suggestion 1 and 2 should be done (Maybe not my exact implementation ideas, but you get the idea). Not one or the other. Granted I don't work in PHP internals, and given the atmosphere there I will likely never volunteer to do something like that.

Given that Rasmus is against #1, #2 seems far more viable. I find when people outline both sides, maintain a valid list of suggestions as to pros/cons, the obvious changes just become obvious. Haters will always appear and mock your ideas, but then I find it's better just to do the job and get on with it.



Greg: That is a great summary. This is how you post an objective look into pros and cons. This is NOT what happening on the thread, and hence me calling them trolls. As I've said, screaming "if it aint broke" over and over again is not constructive, its childish.

Your pros and cons are pretty much all valid and its likely this is the thinking that gave us the compromise solution we have now. But really this conversation hasn't been about being upset with the compromise, its about being upset with the process that lead to the solution.

You cannot possibly look at the thread and tell me that was a group of people objectively stating their opinions in a useful way? That they listened to each others points, and replied based on that?

The very fact that people ignored the fact that "hiding tokens" was an acceptable alternative to "renaming them" meant most folks were just not paying attention to anything being said.

So all that is left is two sides, one with a LOT of pros and the other with very few points at all, the main of which is "all change leads to bugs". Two things to say about that:

A) I wonder how much breaks based on the output of a syntax error. I'd really like to assume no code is parsing these syntax errors for functionality...

B) "All change leads to bugs" is the sister of "if it aint broke dont fix it". The argument put forward stating that "Having to google stuff because its written in Hebrew means it IS broken" happened over, and over, and over. That is ignorance, and ignorance is a major part of troll activity.

I stand by calling many of these internals posts trolltastic. They really were.



Guys, did you loose a bet that forces you to put "fuck" in every sentence ?

Independently of the "Best language tu use in programming" rant, PHP is written in english. You don't want to use english ? Don't use PHP (We French people have created Windev and WLanguage that can be written in french. Problem solved).

The thing is, the guys that created the PHP we know today (namely, Rasmus and Andi, both in favor of keeping the hebrew version) chose to write the language in english.

So Phil is right, using hebrew in the language you decided to write in english is a non sense.

Regardez, si je tape un bout de mon commentaire en Français, est-il cohérent ?

And this very discussion show again how the Internals team is disconnected from the user base :

  • The support team reports a usability issue that seems to affect many users
  • The Internals team says Fuck (That's cool, I could place it too) to the support team for historical reasons, frustrating real people who give time to PHP.

If I wanted to kill the PHP Community, I would not have a different behavior.



Nice article. You just killed any intention of me ever trying to be a php contributor. I read the internals and agree that Antonio was doing good work and had some really good RFCs.

After all this (and the stuff I read on the internals) I am just surprised he didn't leave sooner.

Ben Harold


This type of exchange is incredibly discouraging to anybody who is contemplating joining internals. Oh well, I'll just mark it as "wontfix" and continue on with my day.

Greg Militello


Phil, Admittedly most of my cons I mentioned are pretty bogus. Bugs? Sure they are a potential con for everything. Even for bug fixes. I just wanted something on the list so people got my point. :P

As for what's not happening in that thread, I would argue that php-internals as a mailing list fosters this sort of behavior via chaos. What you have is a group of people without very much guidance making poorly worded or poorly thought out suggestions, and a bunch of people who do not take the time to look at those critically (in some cases, probably justifiably). [This is of course a vast dramatization, not ALL internals traffic is chaos, just the vast majority I have ever experienced.]

When you look at the RFC process on the other hand you have a very structured system of requirements needed for a proposal. However in a lot of cases this is far beyond what a lot of people on php-internals are capable/willing to write themselves. The process (while still flawed imo) has organization breeding usually thought-provoking discussions.

TL/DR: Chaos breeds things like php-internals (generally unwelcoming, and usually full of banter). Organization/structure breeds discussion, thought provoking argument, goals, and deliverable products. Both processes bring trolls out from under their bridges, it is up to the masses to fight them off with proverbial pitch and fire.



That you keep using this amateur crapfest for actual production stuff is some sort of a professional crime. I feel shame for you.

Karl Monaghan


I still remember the incoherent rage I had when I finally figured out what that error message meant. It would have been about 2001 or 2002 and things weren't quite as easy to find as they are now. I still refer to it as "that fucking stupid error message". I'm glad it's been made clearer - I could have fixed my error without searching the first time if it was '::'.

Jeffrey Way


Moomin - you seem like a pretty fun guy.



That's indeed a nice trolling, to make such a windy rant out of nowhere.

It's first time I see a person who did stuck with this token, but instead of 5 seconds of googleing spend a good hour writing an article.

Why not to take it easy, as just an Easter egg, a joke, a funny trifle? There are real problems, man, to waste your zeal.



Sadly, when one rages while making a point there's a lot of people that will focus on the rage instead of the discussion. I'm sorry but that's the language one employs when there's an absolute lack of logic in the points being made and the absence of the slightest chance of changing ones point of view. You don't join an argument just to spit your point and circle around it without listening to the others, that's just lack of intention to build something with it.

Elliot Finkelstein


Even as a newbie PHP programmer, before learned much about OOP or PHP, floundering around having no clue how to debug or deal with any of these cryptic messages... I ran across an error message that hit me like a tone of bricks.

Parse error: syntax error, unexpected (TPAAMAYIMNEKUDOTAYIM)

Finally!! An error message I can understand. Not knowing much about PHP, but fluent in Hebrew... Wow! This I could understand.

Imagine my surprise when after 12 years of professionally programming in COBOL, I went to Israel to do some work. I opened a COBOL program and found that only the COBOL verbs were in English. Everything else was written in phonetic Hebrew. If I survived that, you can stop bitch'n about this.

What kind of nerd geeks are you? For god's sake, go get a life!

Michael Calkins


Makes me a little sad inside for the PHP project despite it's immense impact on the internet. This is where a leader needs to step in an lay down a decision. Probably why Laravel has done so well.



I am taking a php course now and I can relate. I would expect more logic to it let's just say.



Col.shrapnel: It's a shame that you completely misunderstood the entire purpose of this story. Did you skip the introduction and summary, because they were quite large and fairly obvious.

Telemako: I was not joining an argument, I was saying "hahaha, look at this fucking mess." There is no two sides to this, there were a bunch of people having a ridiculous conversation and I pointed at it with running commentary.



Read the article and get this feeling that I just want to change completely from PHP (I don't like it anyway, but I know it well). The internals are far worse than I thought. Then see these comments and think what in the fuck. Why do PHP devs go full retard? This whole article about internals with direct links to actual issues and problems. And what do you discuss? The fucking definition of trolling.

The sooner PHP dies the better. It can't be saved. I actually get embarrassed saying I work with it. After reading these comments I am even more embarrassed.

Aaron Hamid


I had to find this post to discover why the Lemon parser initiative got marked "abandoned". The RFC https://wiki.php.net/rfc/lemon states "The rewrite is finished". If that is true, that it is completed AND abandoned, that seems like a sad self-inflicted tragedy. A lot of that work was done by Felipe Pena by the way. https://github.com/php/php-src/compare/experimental;lemon Two years later another RFC pops up for refactoring the parser to reify an AST https://wiki.php.net/rfc/astbasedparsingcompilationprocess. I imagine the Lemon work would have been a big step in that direction already, if it didn't solve the problem outright. As an outsider to the PHP community these internal improvements seem like no-brainer, but I also find extremely dismissive discussion on the internals list (ASTs are "academic"...huh...?). Yes, replacing the parser is probably one of the more fundamental refactories, but I can only imagine it's pretty discouraging if people are volunteering to fix obvious broken windows only to die on their swords over and over.

Posting comments after three months has been disabled.