Brown: color is weird [video] - <AUTHOR> https://www.youtube.com/watch?v=wh4aWZRtTwU <comment><USER2> I really enjoy this guys videos. The refreshing level of details. Great, geeky, humor.

I especially enjoyed his "rants" about the design of a old toaster, and traffic lights, of all things.

<comment><USER3> The one on traffic lights is way more interesting than it sounds! Everybody should check it out. There's also a really interesting point he makes at the end that applies to something a lot of people on HN might relate with [https://www.youtube.com/watch?v=GiYO1TObNz8](https://www.youtube.com/watch?v=GiYO1TObNz8)

The toaster one is alright, it kinda bothered me when he said there was "literally NO reason" to design something the way it was (I think it had to do with the position of the coils) - obviously there is, it's probably just not a reason he'd like (cost, ease of manufacturing, etc). It makes me wonder if there was other info he skipped on because it "wasn't important" or "stupid". That's a pretty minor point though, overall his videos are very good.

<comment><USER4> He seems like a young technical Andy Rooney!

</comment></comment></comment><comment><USER5> Every "but wait!" Argument I tried to come up with, he answered seconds later. Very well paced and about as full of bad dad-scientist jokes you could make it.

<comment><USER6> He's one of my favourite YouTube channels and I found out about him a mere weeks ago. Binged all his content. He has wonderful playlists on VHS and the format wars, color TV, analog everything etc. I recommend you look at his other videos and click on whatever titillates your interest.

<comment><USER7> I recommend you look at his Patreon page. His quality, depth of research, and overall uniqueness made supporting a no brainer for me.

</comment></comment></comment><comment> ainar-g If you've liked this video, you may also enjoy Alec's series on _LaserDisc_ [1] (no, it's not about CD) and RCA's _Capacitance Electronic Disc_ or _CED_ [2].

[1] [https://www.youtube.com/playlist?list=PLv0jwu7G_DFUoByWSHHoS...](https://www.youtube.com/playlist?list=PLv0jwu7G_DFUoByWSHHoSTlUIxY7VkJLi)

[2] [https://www.youtube.com/playlist?list=PLv0jwu7G_DFVP0SGNlBiB...](https://www.youtube.com/playlist?list=PLv0jwu7G_DFVP0SGNlBiBtFVkV5LZ7SOU)

<comment><USER8> The CED saga reminds me of the Hitchhiker's Guide to the Galaxy, as in a "trilogy in five parts". Nevertheless, I love this guy and really enjoyed listening to the story of the CED.

<comment><USER9> CEDs were great. We had two generations of those players growing up. The best part was that you eventually got to know exactly where the cut points were in movies. Because that was when you had to go up to the TV to flip the disc.

I'll have to listen to his story on them. Probably a very different view from me as a kid just using them to watch movies pre-VCR.

<comment><USER10> There are a _lot_ of HN appropriate lessons in his CED series. Especially the one about being on time to market: if the CED hit the market before the VCR or laserdisc did, it might have survived, or even possibly kept RCA alive. Or the stuff about using tried and true methods instead of the fancy new tech of the day.

My parents recently moved into a smaller home, and ... deacquired a bunch of their furniture by way of my house. In the shuffle I ended up with a bunch of my parents' old records. Being susceptible to impulse buys, I bought a record player. I actually really enjoy the experience of playing records. There's something about the physicality of it. I can't just press a button on my phone and ignore it. I have to choose what to listen to next. I have to physically flip the record twenty minutes in. It's not purely a background thing, it's a physical process and experience. Music has gone from something I ignore to something I participate in.

I'm not actually sure that's in any way relevant to the conversation at hand, but when I started ranting, I felt it was.

<comment> ainar-g Focus is a commodity. Sometimes, people just need rituals. I think, people are slowly starting to realise this.

</comment></comment></comment></comment></comment><comment><USER11> Also watch this please if you ever do plots using colormaps: [https://youtu.be/xAoljeRJ3lU](https://youtu.be/xAoljeRJ3lU)

About the perceptual uniform, colorblind friendly colormaps in matplotlib since 1.5. Now also adapted by most other plotting tools.

<comment><USER12> If we're on the "watch this YouTube video if you work with colours" train, here's a great explanation of why gradients usually have a dark band in the middle, on the MinutePhysics channel:

[https://youtu.be/LKnqECcg6Gw](https://youtu.be/LKnqECcg6Gw)

In short: the RBG values in an image are not actually the intensity of light, but some nonlinear function of intensity. To do a weighted average of two colours you need to first undo that nonlinearity, then do the averaging, then reapply the function. Most software doesn't do that so the colours end up wrong. This also applies to resizing images.

<comment><USER13> Pretty much the first thing you learn in game development (OK not the first thing), is the difference between linear-RGB and sRGB and the need to do lighting calculations in linear space in your shaders. It's crazy that professional graphics software doesn't get this right.

<comment><USER14> > It's crazy that professional graphics software doesn't get this right.

"Professional graphics software" does what it's supposed to be and sRGB is an inferior standard in most use-cases of that software. Its gamut is simply not large enough, but it's a nice smallest-possible commond ground.

<comment><USER15> This isn't a gamut problem, it's a bad coding problem.

"Professional graphics software" (i.e. Photoshop) absolutely does the wrong thing for color blending with the default settings. It's not a problem of being limited to the sRGB color space, it's about the math in use being outright wrong for use on that color space. You need to go into the settings and tick some checkbox to have some hope of it doing the right thing ("Blend RGB colors using gamma"), and even then I bet it only applies to some operations like blending itself, not scaling and other filters.

This is because all non-linear image encoding modes, like sRGB or straight gamma, should be viewed as _compression_. You don't perform mathematical operations on _compressed_ data. It's like trying to mix together two MP3 files by literally taking the bytes and averaging them out. That's madness and does not work. You need to go into a linear format, like raw PCM, to be able to do that (with the right word size). Same with images: you need to convert from sRGB to linear light to be able to do math on them. But 95% of software, including "pro" software, doesn't do this, it just blindly does math on compressed (gamma encoded) data, and the result is ugly (we're just used to it).

Of couse, with Photoshop you can set your image mode to linear light and _then_ things work fine... but that's not because linear light is required to make this stuff work, it's because Photoshop is _broken_ when not using linear light and doesn't compensate for the encoding.

Meanwhile GIMP, a few versions ago, fixed this whole mess and actually applies blending and filtering in linear light (regardless of what mode your image is using in memory), making its blending and filtering much more pleasant and correct than Photoshop's. So yeah, it may not support CMYK or other "pro" features... but for a good chunk of basic editing in RGB space, you're actually going to get more correct and visually appealing results if you use GIMP than Photoshop.

</comment></comment></comment></comment></comment><comment><USER16> One thing he missed in the video is the fact that red and green cone cells make up 95% of the cones in human eyes, hence our extreme sensitivity to colors that fall between the two. Dark orange looks brown because we have so much resolution in that space to work with, whereas dark green is just dark green, or dark blue is just dark blue.

<comment> martin-adams In the video he said that we recognise it as brown because we learned the name for it and thus recognise it independently. Is that idea compatible with us having more red and green cone cells than blue - i.e. having more resolution to recognise brown?

<comment><USER17> Also a matter of context. Brown is orange and grey can be red.

[https://www.youtube.com/watch?v=MJBfn07gZ30](https://www.youtube.com/watch?v=MJBfn07gZ30)

Here's a part of a documentary talking about the cultural aspect of how we perceive colours and the power of naming a color (with the Himba people)

[https://www.dailymotion.com/video/xl7eh1](https://www.dailymotion.com/video/xl7eh1)

</comment></comment></comment><comment><USER18> I watched this with my SO last night. We have a very small cross section of shared media interests (notable ones being star trek and grand designs). One of the few youtube videos I've put on that she got excited about was Tech Connections video on rice cookers. I mean, I know I really like his stuff. Even though I'm deep in the weeds with most of his topics and already know it, I still find pleasure in hearing advanced topics explained from base concepts with such clarity. He knows his business and it shows.

</comment><comment><USER19> Am I the only one who already thought brown just _was_ dark orange? Like, if you google 'dark orange', you get shown a bunch of brown swatches as the top results. Isn't that... just what brown has always been?

<comment><USER20> But there are light browns that are not orange, e.g. [https://en.wikipedia.org/wiki/Khaki](https://en.wikipedia.org/wiki/Khaki)

<comment><USER21> It is because brown really isn't _just_ dark orange. There are oranges that are both dark and not brown - these usually are on the redder side of orange, like dark orange clouds in the sky at sunset.

Brown is, in general, a muted orange. Take the red and yellow, add a hint of green (or purple, honestly) - and you have browns.

</comment></comment></comment><comment><USER22> Maybe weird but not unique: every non-saturated color is like this. Try to set your RGB lighting strip to gray. Or watch the veins pop out of your LD's forehead when someone asks for gray lighting on stage.

<comment><USER23> Pass out grey translucent glasses with a little bit of diffusion to everybody in the audience.

<comment><USER24> Now I'm wondering if there are programmable lenses to provide basic, real-life filters at concerts and other events.

</comment></comment></comment><comment><USER25> Is our color perception influenced by our culture's language? [https://en.wikipedia.org/wiki/Linguistic_relativity_and_the_...](https://en.wikipedia.org/wiki/Linguistic_relativity_and_the_color_naming_debate)

<comment><USER26> I don't know, but the words we use for it are certainly influenced by our culture!

Here's a paper with nice graphs, drawing where different languages put the boundaries between words -- they divide up the hue-saturation space into a varying number of blobs:

[https://www.pnas.org/content/115/31/7937](https://www.pnas.org/content/115/31/7937)

(The data isn't theirs, it was painstakingly colected by going and asking lots of people "what colour is this pantone?". The paper does some fancy stuff on top of that. But it has nice graphs.)

</comment></comment><comment><USER27> Technology Connections is so great. Never dissapoints.

</comment><comment><USER28> This is great. I wish I had seen it before I did the unit on color with the kids in my after school club, although they did have their minds blown slightly when I made the screen on my cell phone all yellow and then put it under a microscope so they could see that there were only red and green pixels illuminated - no yellow light coming off that screen at all, it was all in their heads.

</comment><comment><USER29> Grey is also weird for the same reason. The moon appears white at night, but its albedo (% reflected light) is actually 0.12 which is comparable to that of asphalt.

<comment><USER30> Black or white-ish asphalt?

<comment><USER29> Not black asphalt. Well, depending on the context it will appear black. :^)

[https://i.imgur.com/dGDaVLz.jpg](https://i.imgur.com/dGDaVLz.jpg)

[https://nasaviz.gsfc.nasa.gov/vis/a010000/a011900/a011924/c-...](https://nasaviz.gsfc.nasa.gov/vis/a010000/a011900/a011924/c-1280.jpg)

</comment></comment></comment><comment><USER31> I always wonder if there will be displays in the future that combine emission and absorption at the same time.

Like a combination of OLED and E Ink.

This will also give you the possibility to turn your TV into a painting (without using power) when you are done watching.

<comment><USER32> Some displays already have the two modes―alas don't remember what they're called, it's some variation of color eink. You get color indoors, or only black-on-white in sunlight.

Some ebook devices also have 'backlight'―usually diffused light from the sides so it doesn't shine directly in the eyes. I think this is the crux of your idea, because currently even if you use lcd/oled with backlight, no-power eink will be severely washed out in comparison. And if eink gets good color and contrast in the future, it will then fulfill the two-mode technology.

<comment><USER33> I think you're talking about the displays that the original OLPC used: [http://wiki.laptop.org/go/Display](http://wiki.laptop.org/go/Display)

<comment><USER32> Yeah, apparently the Pixel Qi company is a spin-off from OLPC, and that's the name I've heard in the context of color eink tech (took me a while to remember it). Defunct since 2015, however.

The page on the wiki.laptop.org isn't too clear on the technology—presumably it's more complex than just LCD and eink slapped together. The Wikipedia page on the XO laptop seems to have some detail: [https://en.wikipedia.org/wiki/OLPC_XO#Display](https://en.wikipedia.org/wiki/OLPC_XO#Display)

</comment></comment></comment></comment><comment><USER32> Obviously I now need to repeat the dark room trick but with cut-out pictures of chocolate, coffee, nuts, dirt and bears.

</comment><comment><USER34> Big fan of this channel. He's got a great series on the RCA CED.

</comment><comment><USER35> I can kind of make sense of why humans(animals?) evolved to see brightness in relative terms. The same object will have different amount of light reflecting off it based on the time of day so you don't want your brain to register those as different scenes.

Hue also makes sense. It's the distribution of wavelengths being reflected.

But what does saturation correspond to? When do things become saturated/desaturated in the natural world?

<comment><USER36> Ripeness?

<comment><USER37> Sunbleached? Roughened surface?

</comment></comment></comment><comment><USER38> Color is hard to talk about correctly. If you're reading this, video creator, since you asked at the end, this was very well done. Really, really good. Thanks for distinguishing magenta. Thanks for discussing both the additive and subtractive color models. Thanks for going over a few mathematical ways to describe color (RGB, HSB, etc). Thanks for mentioning photoreceptors and the visual cortex, how colors appear differently in different environments, and how color is an _event_. Thanks for mixing paints!

I would include this as part of an introduction to color theory.

If you were to make a V2, I'd suggest discussing gray, since I'm sure you'd find a way to make gray interesting (I mean it _is_ though) :)

</comment><comment><USER39> So basically there's no such thing as orange. It's just brown

<comment><USER40> Bright brown.

</comment></comment><comment><USER41> As someone who suffers form a colour vision abnormality these things make me happy; if the world is so messed up for normal people then who cares that it's slightly more queer for me.

</comment><comment><USER42> Classical works use colour in ways that are confusing to read. You either have to accept that it is describing a fantasy, or that the author's concept of colours is different than ours.

I had wondered if there was any example from own language of this, in order to get the benefit of that perspective. This seems to be it.

Perhaps we had a name for brown before orange. Whereas other colours tend to be named for the saturated version.

Has cultivation changed citrus colours, as with carrots?

</comment><comment><USER43> So after all that (it was fantastic) I just want to confirm my understanding: "brown" is literally just "dark orange", correct?

</comment><comment><USER44> So, brown is only a cultural construct - actually it's just a dark orange. The Video is amazing. I wish to read more scientific research on this subject.

</comment><comment><USER45> Technology Connections is one of my favorite channels! It's one of the few whose videos I consistently watch immediately after release.

</comment><comment><USER46> I honestly couldn't see the orange when the square is surrounded by black. It was still brown for me.

<comment><USER27> Were you in a bright room? That would have given you context, which is what he warned against.

<comment><USER46> Yea, that might be the case

</comment></comment></comment><comment><USER47> This was the last topic on which I expected to completely watch the video. Fantastic presentation.

</comment><comment><USER48> While I was in school, a professor was grilling me on color, and said, okay smarty pants, if you think you know what brown is, show me a brown laser.

We happened to be in the lab, so I pointed to a brown spot on the wall, made by a very powerful laser. After that, we referred to it as the brown laser.

<comment><USER49> You can't have a magenta laser either (since magenta can't be represented by a single wavelength). Or a black laser. Or for that matter, a C sharp laser. That doesn't mean those concept are particularly hard to wrap one's head around.

<comment><USER50> Nowhere in that anecdote does anyone assert that brown does not exist. "If you think that you know what brown is" is not talking about existence.

<comment><USER49> It seems a bit of a pedantic distinction, but ok. I edited the comment. I don't think it changes the spirit of the comment, though.

I've seen many people try to argue that magenta doesn't exist, or isn't a color, etc., simply because it doesn't correlate to a single wavelength.

Regardless, what is he trying to say, then? That brown can't be understood because there is no such thing as a brown laser? My point remains.

<comment><USER48> I was just recalling an amusing anecdote. The brown color produced by the laser was because it burned the wall. It's too late for me to edit the post for clarity.

<comment><USER49> Yes and it is an amusing anecdote. I commented because I've seen so many people who think that "color" must have a one-to-one relationship with wavelength of light, and it seemed your professor was doing that as well.

<comment><USER48> Actually, he was trying to get me past thinking that way. It all got started when I was trying to figure out RGB colors for some computer display.

<comment><USER49> Fair enough. I wasn't trying to take away from your anecdote or slight the professor, just add some commentary on that way of thinking about colors.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER51> We do have other labels for colors nowadays though (ex. Olive, Khaki, Navy)

</comment><comment><USER52> Why is yellow ignored as a primary color green pushed as a primary color?

<comment> a-nikolaev Red, blue, and yellow are subtractive primary colors. E.g. if an object absorbs(subtracts) red light, then under white light it looks green (blue+yellow remained). This is how colors work in painting.

On the other hand, your monitor does not absorb colors, but emits it. If you shine red and green light on a white surface (or on your eye directly), you will see green. This is called additive color. RGB (red, green, blue) are primary additive colors.

[https://drawpaintacademy.com/subtractive-additive- color/](https://drawpaintacademy.com/subtractive-additive-color/)

<comment><USER49> Magenta yellow and cyan are subtractive primaries. Cyan might pass for blue, but magenta really isn't red.

And really you could say red green and blue are subtractive primaries (as well as additive), but we use cyan ink because it subtracts red light. (etc)

<comment> a-nikolaev Yeah, technically yes, but the poster above refers to the primary colors used in arts, which are red, blue, and yellow. They do represent subtractive colors magenta, cyan, yellow.

<comment><USER49> I'd say red yellow and blue is used in elementary school art class, and not much more. And even then, kids almost always have more colors to work with than three.

The subtractive color model isn't really good for paints anyway, it is best with translucent inks/dyes, where the white from the paper comes through.

</comment></comment></comment></comment></comment><comment><USER53> To be fair, the title is "Brown; color is weird"

</comment><comment><USER54> tl;dv: "Brown is just orange, but darker."

<comment><USER55> "tl;dv" is so new/unused there's no results on Google (or Urban Dictionary for that matter). How is that possible? o_O

<comment><USER56> The more common usage would be "tl;dw"

<comment><USER54> Yes, I tried to adapt the shortcut with "viewed" but didn't think of "watched" (not native speaker of English).

<comment><USER57> dw was already used for "don't worry", so its a shame shame that tldw caught on instead of tldv

<comment><USER58> when would you use _too long dont worry_?

<comment><USER44> tl;idc is the real thing you have to use

</comment></comment></comment></comment></comment></comment></comment><comment><USER59> I used to like this guy, and his factual information is usually interesting, but he sometimes expresses opinions that downright infuriate me, to the point I had to stop listening.

<comment><USER60> Care to give examples?

</comment></comment><comment><USER61> Everytime he said "context", he should have said "contrast".

He also didn't mention that grey is dark white, by the same phenomenon.

And of course red is dark pink, for rooster teeth fans.

<comment><USER62> Well, Contrast is usually in parlance as extremes. I think he means in context of what else is in the image, not just contrast. For example, you can have a "dark green" and "dark orange" used in a graphic of a tree on a black background, and you would perceive it as brown due to the context of the "tree-ness" on your screen.

</comment></comment><comment><USER63> Color is cool. Let's add another dimension to this video.

It's one way of conveying information the brain can interpret in a flexible way.

But the brain is also good at depth perception. Let's combine these :

For example in the app I released yesterday StlToRelief : [https://news.ycombinator.com/item?id=22319140](https://news.ycombinator.com/item?id=22319140)

I use a color gradient to increase the perception of depth. It makes a thin bas-relief standout.

With color-mixing 3d-printing this is an effect we can now exploit.

There is a closely related phenomena that we have when doing war paints for camouflage. Area (i.e. peaks like the nose) that would naturally catch the light appear brighter so you have to paint them dark while hollow area that naturally appear dark must be painted white. The resulting painting make a face look flat which stand out less.</comment>


Redditor invests $30,000 life savings in bitcoin a month ago when it was $25 - <AUTHOR> http://www.reddit.com/r/Bitcoin/comments/18f3pd/i_have_my_entire_retirement_and_savings_invested/c8ehaox

<comment><USER2> I have a sneaking suspicion that if the internet had existed in the 1630's you could have written/read the same article just replacing Bitcoin with Tulip. I hope this person gas better luck than those folks had.

<http://en.wikipedia.org/wiki/Tulip_bubble></comment>


Show HN: Snips – A simple free snippets manager - <AUTHOR> https://github.com/ethanpil/snips <comment><AUTHOR> Just a small utility that I wrote for myself. Would love feedback, and perhaps someone else will find it useful.

Why? I made this because:

* I want to use the same snippet list across all my editors and IDE software * I want an easy and intuitive way to manage my snippets * I dont want my snippets in a proprietary format * Other third party snippet tools were too bulky and resource intensive * It was fun</comment>


PHP is dead…Viva le PHP - <AUTHOR> https://hackernoon.com/php-is-dead-viva-le-php-f5dc5eb5c9c4 <comment><USER2> > "nearly 80% of the internet is running on PHP as of 2018."

I've heard claims like this for years. They almost never explain their methodology for calculating market share among the entire web. The site linked actually shows its methodology and it proves that the author is using the statistic incorrectly.

Under methodolgies:

> _We investigate technologies of websites, not of individual web pages. If we > find a technology on any of the pages, it is considered to be used by the > website._

This does not prove that 80% of the web is powered by PHP, but rather 80% of websites studied had PHP running in some capacity, under the same domain.

It would be wildly inaccurate to assess from that, that

> _" nearly 80% of the internet is running on PHP as of 2018."_ as claimed.

Google.com may have a wordpress blog for press releases running somewhere under their domain... that hardly means google is powered by wordpress.

Also, for example it would be totally wrong to say Facebook is powered solely by PHP.

</comment><comment><USER2> Also, and I say this as someone who has years of experience programming in multiple languages including PHP--It's a logical fallacy to say just because most people do something it is the correct course of action to take. This is a logical fallacy known as _argumentum ad antiquitatem_ or an "appeal to common practice".

PHP is probably fine for many of the things the author mentioned particularly brochure, content-based, sites, blogs, portfolios etc... (although increasingly using static based sites hosted from s3 or other static host seems to make more sense, in terms of cost and performance.)

Then there is a whole host of other problem domains where PHP does not make sense as a technology choice, Data Science, Graphics, Comms/Messaging, Systems programming. Let's choose the right tool for the job. What's the old adage about "when all you have is a hammer you treat every job as a nail."</comment>


U.S. And U.K. Warn of Cybersecurity Threat from Russia - <AUTHOR> https://www.nytimes.com/2018/04/16/world/europe/us-uk-russia-cybersecurity-threat.html <comment><USER2> I must say that by now, it is hard to tell what is the truth.

<comment><USER3> > by now

I don't think much has changed, it's just that we see a lot more diversity than 30 years ago. Having grown up in East Germany, if I hadn't lived close enough to the Western border I could only have viewed East German TV and read East German newspapers. In the US you were (for the most part) not exposed to anything from Russia, and vice versa. Now more people get to see that the world is quite a bit more colorful, for both better and worse.

I don't think it matters all that much, because apart from passive news consumption, what would you actually _do_ (that is impacted by the information)?

<comment><USER4> Note that nobody in West Germany used to watch East German TV during that time.

Meaning: it's not all propaganda, with each side being equally bad and the truth to be found by triangulation.

</comment></comment></comment><comment><USER5> They have wiretapped the entire world with PRISM and other similar secret programs. They have seized and vanished a countless number of people to black site secret prisons.

Who cares about Russia.

<comment><USER6> А у вас негров линчуют ([https://en.wikipedia.org/wiki/And_you_are_lynching_Negroes](https://en.wikipedia.org/wiki/And_you_are_lynching_Negroes))

The bad actions of the US and their allies does not excuse the same actions of Russia (or China, or any other country).

<comment><USER7> Excuse, no. But there's nothing wrong with pointing out hypocrisy.

<comment><USER8> Highlighting the crimes of actor B to excuse the crimes of actor A is not "pointing out hypocrisy", it's an attempt to excuse a crime and confuse the conversation.

<comment><USER9> I a more worried about the UK government having access to my data as its more relevant being a citizen of the UK. I think that's the point.

<comment><USER10> You certainly should be worried if a future UK government turns out to be a drastically more coercive nature than the present. And that's on the cards.

</comment></comment></comment></comment></comment></comment><comment><USER11> Should we declare an International Factory Reset Your Router Day?

Edit: I know this is not a permanent solution. But it could be effective if combined with efforts to study the propagation of attacks and with efforts to educate the public about properly securing their routers.

<comment><USER12> Now that we understand a bit more about the behaviour of the system at scale, lets iterate and build the internet again, from scratch, but better this time. Factory resetting routers isn't enough, we need to factory reset the internet.

<comment><USER11> Agreed. <Insert Ideological Post About Blockchain Here>

</comment></comment></comment><comment><USER13> Meanwhile, propaganda threat from US and UK governments remains high.

<comment><USER14> Even internally [1]

[1] [http://foreignpolicy.com/2013/07/14/u-s-repeals- propaganda-b...](http://foreignpolicy.com/2013/07/14/u-s-repeals-propaganda- ban-spreads-government-made-news-to-americans/)

</comment></comment><comment><USER15> Slightly off topic (article mentions routers as prime targets): what do you guys consider a secure/affordable router these days?

</comment><comment><USER7> Rules for thee, but not for me.

</comment><comment><USER16> Fair game, IMO. Pretty sure Russia and the West are incompatible, at least for a long while. If you ask Russia they'll say that NATO violated the verbal agreement of not coming near Russia via membership, but NATO says that countries have the right to decide for themselves etc etc. Plus Russia is a shadow of USSR.

So it's a war, of sorts. Russia says that USA sponsors all these groups it determines to be anti-Russian and interferes in Russian elections, so it returns the favors with fake news /Trump election.

But in the end, Russia is bound to lose--again. Money talks and Russia doesn't have much, the richer world wants /needs to stay in good graces with the Western world. So we have sanctions, choose between Russians or USA+EU plus most of the world. This oligarch thing is kinda smart...if they hurt, they might try to take on Putin. There's a limit on how much a billionaire criminal who can't buy a villa in Spain anymore can take. But then, if they miss with the only bullet...

<comment><USER17> Meanwhile business selling defense systems for both NATO countries and Rusia is better than ever! Sometimes it seems to me they are playing by the WWF marketing rules, lots of chest thumping around, but mostly are others who are paying the broken bones(see how the death of 200 russian contractors that attacked Kurdish-American positions and got smashed, went mostly unnoticed 2 months ago) By others I mean Syrian, Yemenis, etc..

Of course it could go south and the blows become real (like in wrestling), but by the moment is mostly an useful show for both sides. NATO keeps the archenemy and the show business running. People in Russia see Putin as Peter the Great reborn, making Russia punch way above its weight internationally, recovering the pride lost in the 90s.

Edit a couple typos.</comment></comment>


PHP is much better than what you think - <AUTHOR> http://fabien.potencier.org/article/64/php-is-much-better-than-what-you-think <comment><USER3> For reference's sake, this article is written by Fabien Potencier, the creator of the symfony framework. This guy's probably single-handedly responsible for lifting the PHP community to a higher level, by making great software (which, when he started, was pretty unique, with horrible hacks-upon-hacks like CakePHP being the norm), and by showing people how to do so.

<comment><USER4> What's so horrible about CakePHP?

<comment><USER5> Its legacy (who wants to still support PHP4?). AFAIK, it's no longer maintained; I believe all the core development is now taking place on the Lithium project: <http://lithify.me/>

<comment><USER6> None of these things are true, I don't know where anyone comes up with this stuff. Sounds like a smear job more than anything. CakePHP2 is PHP 5.2.8+[1]. It's still being maintained and 2.2 was released this week[2]. Lithium is not a real 'fork' from Cake - rather it is a project that two of the Cake devs were working on as a 'next gen CakePHP' but decided to make into a separate project - the two frameworks don't share any code in their 'production' releases. Lithium has a much smaller community and is still poorly documented (as far as I can tell having tried to use it for a project).

[1] [http://book.cakephp.org/2.0/en/appendices/2-0-migration- guid...](http://book.cakephp.org/2.0/en/appendices/2-0-migration- guide.html#php-version-support)

[2] [http://bakery.cakephp.org/articles/lorenzo/2012/07/01/cakeph...](http://bakery.cakephp.org/articles/lorenzo/2012/07/01/cakephp_2_2_and_2_1_4_released)

<comment><USER5> > Sounds like a smear job more than anything.

Not at all. I'm sorry you misunderstood. Cake has been quite good to me over the years. Ever since I switched to Lithium I haven't looked back.

</comment></comment></comment></comment></comment><comment><USER7> PHP is easy to deploy on. That's it. That's why it's popular. It's braindead easy to go from text editor to web URL, it's braindead easy to unzip someone else's project and run it. It requires virtually zero sysops experience to be able to use. You don't even have to worry about setting those +x bits like you used to in the good old cgi-bin days.

For those of us who aren't afraid of a little ops work, there are _far_ better options, and I say that as developer that's been using PHP regularly for going on 13 years.

<comment><USER8> "PHP is easy to deploy on. That's it. That's why it's popular. It's braindead easy to go from text editor to web URL, it's braindead easy to unzip someone else's project and run it. It requires virtually zero sysops experience to be able to use. You don't even have to worry about setting those +x bits like you used to in the good old cgi-bin days."

And that's exactly why PHP is the better choice for those of us who distribute software to non-technical users.

<comment><USER9> Spot on - you nailed it.

The end user counts here, big time. A lot of the products out there would have precisely zero traction if they required literally hours of piddling around.

If you compare it to JVM based commercial offerings, and I'll pick Crucible as an example here, it requires:

1\. Find a working JVM that matches it.

2\. Piddle around with PATH settings and JAVA_HOMEW.

3\. Unzip it.

4\. Lots of database configuration.

5\. Frig around with ACLs.on disk so it can actually write to its home directory.

6\. Frigging around getting it to run as a service using a JVM service wrapper or init script that you have to write yourself.

7\. Extensive backup/restore scripting.

8\. Hours of dredging through Atlassian's shitty web site.

9\. Fuck around with Tomcat to persuade it to work behind a proxy.

10\. Set up an IIS ARR or apache AJP/HTTP proxy in front so you can serve it on a decent URL or port.

This applies to anything with stateful that requires any intevention other than copying files. That includes Python, Ruby, .Net (which is less painful I will say), Java, Scala, Clojure, common LISP. You name it.

The only things that it doesn't occur on are: ASP, PHP.

Most stuff in PHP is:

1\. Unzip.

2\. SFTP it up

3\. Change the connection info in config.php

4\. Run install.php and follow instructions.

5\. Done.

People don't care about nginx vs fastcgi vs apache vs this vs that. They just want it to work and PHP gives a viable and simple solution to that.

<comment><USER10> The funny thing is that if you do care about nginx and fastcgi you can get blazing fast high-volume/low-overhead php hosting with varnish + nginx + php_fpm.

<comment><USER11> Not to be a hater, but what's funny about that? The point is exactly that. Most people don't care about "blazing fast".

<comment><USER10> Right, most people who decide to use PHP aren't overly concerned about performance. And the folks who are concerned about it tend to choose other solutions (say, node.js, for example). The funny part is that it's fairly easy to take even bloated PHP apps like wordpress and turn them into high performance sites on very modest hardware.

<comment><USER7> When you're putting Varnish in front of static content, it doesn't really matter _what_ the backend is, it's going to fly.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Hacker News really doesn't like PHP. There's a whole lot of blind prejudice in this thread

Arguments against PHP are as futile as arguments in support of PHP. It's a programming language. The only thing that matters is the person using it. I'm sure Ruby, Node and Go are super duper awesome in a lot of academic ways, but unless we're talking about awesome things that have been made with them, it's just blah blah blah boring opinions no one should care about.

<comment><USER13> > Hacker News really doesn't like PHP.

But Y?

        function Y($F) {
            $func =  function ($f) { return $f($f); };
            return $func(function ($f) use($F) {
                    return $F(function ($x) use($f) {
                    $ff = $f($f);
                    return $ff($x);
                });
            });
        }

<comment><USER14> You can write that code in almost any language and it will look bad and be hard to mentally parse.

<comment><USER15> That might be true, but it's _a lot_ easier to do in PHP than Python for example

<comment><USER14> I looked at rosetta code - they both look pretty similar in clarity. Compare to JavaScript or R, which are much more legible.

</comment></comment></comment></comment></comment><comment><USER16> > PHP must have done something right, no?

Shitloads of people also believe in organised religion or naturopathy, doesn't mean that's a good thing.

> PHP is the best web platform... ever.

So because it's nearly caught up with other languages and you can install stuff easily if you have the prerequisite of knowing about composer? Bullshit.

I'm sure composer is great, but if your main argument is that PHP requires zero previous knowledge you can't really use that.

<comment><USER17> Honest question: Do you have more than a months professional experience writing modern PHP?

While I love appreciate the Java ecosystem with amazing stuff like Play framework, Scala, Camel (several apache sub projects actually), Python micro frameworks etc there still is something magic about PHP. I still haven't made up my mind but there is something about really fast turnaround time, transparency, and shared nothing from the ground up. Maybe "Just Works" is the word. (Cheap hosting and next to zero installation just to be an argument but I guess Play is even better in this regard.)

(background: I am allowed to be opinionated on this (programming since I was a kid) professionally mostly Java but also PHP (greenfield, maintenance), and since this is also my hobby I have also scripted non-trivial python, tried rails back at 1.0 etc.)

<comment><USER18> I'd argue PHP is, for any project of reasonable size, harder to get up and running than say Rails. For any serious development a PHP developer (some experience, did several years of PHP dev) will have to setup a local instance of Apache/ MySQL/ PHP and deal with making sure libraries installed on this dev server match libraries on the production server.

When it comes to deployment for both Rails (in this case) and PHP you can choose between pretty automated providers like Heroku/ PHPFog which make git deployment trivial or you have to deal with server set up and configuration.

So I'm not really sure these days that for anything except the smallest projects PHP just works any more than any other reasonably popular web language?

<comment><USER19> PHP 5.4 has a local development server, so even that point is moot. But how hard is setting up apache, mysql and PHP?

sudo yum install apache php mysql

done.

And anyway, for a serious project you need a local dev environment that somewhat mirrors live, and then staging (which exactly mirrors live).

<comment><USER18> Agree it's not that hard, I also don't think it's in any way a bad thing to have to learn how to do it (in fact probably a good thing). Just that learning how to do that is no easier than learning to deploy a rails/ django/ etc app so I'm not sure PHP really 'just works' any more than any other popular language.

<comment><USER20> You're comparing it to frameworks. You don't need a framework to handle URL routing, input parsing, output headers, etc. You save a PHP file and it's a URL; no routing. The query string, POST body, request headers, uploaded files, etc. are already parsed and sitting in variables in your global namespace. Output will automatically go to the web server, with the appropriate headers already set. No downloading or configuring of frameworks, no deploying. It "just works", to the point that an empty .php file with no source code at all is a working URL.

You _can_ have a framework, you _can_ do your own routing, input parsing, output sanitizing, and all the other things Rails/Django do. But unlike Ruby/Python, you don't need to just to get started on the web.

<comment><USER21> PHP is really a framework. It includes builtin routing, builtin request parsing, builtin templates, etc. All very tightly integrated. And it is definitely not just an interpreter or library.

And a lot of what you are listing as "just works" are misfeatures which break things and make life unnecessarily hard down the road. They are time bombs, because everything will seem OK up front and the problems won't occur to you until they are already serious and chronic.

There IS routing, it is just implicit, magical routing performed by the server by inspecting a filesystem (e.g. the same filesystem where you have code, databases, password files, configs, etc.) Exposing my internal project organization publicly as a grody looking URL scheme that will become enshrined in all my links? Oh boy!

I don't WANT everything magically parsed by default, regardless of whether I need it for this request. This must happen when and how I specify or the tool is useless to me. Also: it is not a POST body, it is a request body. What do you call the body of a PUT? (And this kind of mis-education is another PHP misfeature)

I don't WANT random mistakes like leaving empty files to pass silently. I want bad code to fail early so I can easily detect the presence of a problem, and locate it. There is nothing worse than silent failure. If you think that silencing errors "just works" then you have your head in the sand. Don't think that users don't notice when a site is broken.

You can use a builtin framework which behaves inappropriately by default and then rewrite later, but why would you actively choose to do this? I think that most people do not choose to do it, because they just don't know. That is why this topic keeps coming up.

It is nice to nurse people along, but it is not nice to require them to nurse your tool along continuously because of all its broken behavior. Their time is better spent working on their own code rather than nursing yours. So perhaps other frameworks could somehow do an even better job of nursing users along, and those specifics are worth discussing. But that doesn't mean the right answer is to hook people on PHP's builtin framework.

And by the time you dress up PHP with a third party framework and other tools to make it fit for use, which you can certainly do, it is absolutely not easier than frameworks in other languages.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> I am so sick of this kind of talk.

What language do you like to code in? Really? That's great. Now shut up and go code in it.

What difference does it make to you that I use PHP, Ruby or original ASP?

My website achieves the result I desire. I chose the programming language I use because of reasons that made sense to me and my project, not because I want the approval of a bunch of hipster start-up kids.

<comment><USER14> To be fair, this has been a while coming. There's so much PHP bashing that takes place now it's ridiculous. People take inefficiencies of the language from 5 years ago, tart them up as crimes against humanity, and then pretend that the only reason PHP is more popular than their language is because most people aren't smart enough to code in their language.

Fabien, though I sometimes disagree with his technical choices, is one of the brightest stars in PHP right now and he's just putting forward a somewhat modest defense of PHP.

<comment><USER21> A number of these critical articles point out problems from 5 years ago... which are also still problems today.

I would have more sympathy if it were clearly evident that serious bugs were taken seriously rather than being ignored for a decade

<comment><USER14> Do you have an example of one of these serious bugs?

<comment><USER21> Every time one is posted (at least once a month), you and others complain loudly about how PHP is being unfairly picked on.

You can't be satisfied

</comment></comment></comment></comment></comment><comment><USER23> To be honest I don't like PHP for exactly the reasons I don't like javascript.

It's easy to write in a way which is stupid.

You can write good php and you can write cool stuff with it. It is easy to non-technical folk to pickup and write a little bit of.

It's also amazingly easy to:

1) Write code which is broken and stupid (woops, left error_reporting(E_ALL) on! silly me. dumped all the passwords out into the website. woops. _stabs designer_ )

2) Write code which is clever, but different from the coding style of every other piece of code in the project (>_> look, my js is so clever, its using closures for everything and events and... oh, you guys weren't doing that? um... ok. Well, now we have some piece of code that only one person knows how to understand _stabs self important javascript ninja with spoon_ ).

3) Introduce bugs.

Managing your developers is really the key. If you can keep your php programmers in line, and keep bad code out of your project, php isn't that bad.

...but its that _much harder to do_ when twice as many people are working on the code, and some of them belong to another team.

<comment><USER24> 1) Use a framework like Symfony2.

2) Yes, I agree, PHP encourages you to write esoteric code. Oh wait, what the fuck am I smoking? Better yet, what are _you_ smoking? You can do this in every language I know.

3) Use unit and functional testing. You do use automated testing, don't you?

<comment><USER25> I think you missed the nuance in #2. Yes, you _can_ write esoteric code in any language, but few languages actively encourage it like PHP.

</comment></comment></comment><comment><USER26> No, it's exactly as bad _of a language_ as everyone is saying it is. In addition, it filled a void that is no longer a void (dynamic HTML generation in a programmer-friendly way) and has rightfully been supplanted as the go-to language for new projects by a number of superior languages.

</comment><comment><USER27> Every blog post about PHP mentions its 'easy to set up for non-technical people'.

I can't disagree more. PHP is as easy as any language should be. As if everyone implies the harder a language to use, the cooler it is.

In my understanding a smooth set up experience is a sign community cares about the thing. Extensive and up-to-date documentation means the community is large and not stagnating. A language easy to learn and use is a properly designed language. If the language is hard to understand and write code in, it should not exist at all.

<comment><USER28> Learning how to use a language is, essentially, an O(1) operation. The constant factor may be high, but it's just that--a constant. Moreover, it should not take you more than a couple of weeks to learn _any_ language (save obviously impractical ones like Malbolge) well enough to use it for a web project. The policy at my school is that you should be able to pick up a new language well enough to use in a class over the weekend; I agree with this. Picking up a language to use for a web project should not take much longer.

A language that's more productive gives you an O(n) benefit where n is the amount of work you do. Assuming you do a nontrivial amount of work, this is always going to outweigh the amount of time it takes to learn even the most difficult of languages.

Now, in a perfect world, a language would be _both_ easy to learn and productive. Unfortunately, in practice, the most productive languages are also the most difficult to learn. However, this doesn't mean they shouldn't exist-- quite the contrary even; I think they are more important than languages easy to learn but less productive.

Assuming you'll be spending any significant amount of time programming, don't pick a language exclusively because it is easy to learn!

<comment><USER29> > Moreover, it should not take you more than a couple of weeks to learn any > language

This is why I find the "you can't find Ruby/Python/whatever developers" argument unconvincing. If you're a _good_ software developer, you can learn new languages. You _like_ learning new languages. It's only the crap developers who typecast themselves in one role throughout their career.

And while I don't believe in all the nonsense about ninja coders and only hiring the best of the best, really, the ability to learn a new imperative language is not a very high bar to clear.

<comment><USER30> You can, but I think the benefits are vastly overestimated. Languages are tools and the purpose of engineering is building, not having a tool fetish. This doesn't mean one should use bad tools, but when learning new frameworks or languages I almost always feel like I am wasting time.

The innovative ideas in programming language design are few and have been known for many years. Learning Ruby or Python instead of let's say Perl will bring you almost no benefits from a technical perspective.

You're essentially paying with your time to enter the Ruby&Rails ecosystem of jobs, consulting gigs, events and so on but you're still building websites using the same protocols, servers, databases, etc.

<comment><USER28> The innovative ideas in programming languages design may have been known for many years, but at least half are cleverly not incorporated into mainstream languages like Python or Ruby, and don't get me started on Java.

Language design, more than anything, seems to be a field where using actual academic research is passé. C# seems to be the one rare exception among the popular languages. On other platforms, the innovative ideas are all stuck in less popular languages like Scala, OCaml or Haskell.

</comment></comment></comment></comment></comment><comment><USER31> One major problem I see in this article is that the stats that are cited as "proof" that PHP is the most widespread language are skewed.

* The sample is not representative. It's the top 1 million according to alexa.

* The percentage cited is "x percent of all pages that we can determine are..." which skews heavily in favor of PHP since PHP exposes it's version by default at least in older versions while other languages such as ruby don't. The percentage of pages that turned up as "unknown" is not listed.

* They don't give an error margin for their stats.

* Same is true for the Content-Management Sites. It skews heavily in favor of wordpress because lots of sites do have a wordpress blog installed somewhere.

I do acknowledge that PHP is probably leading by market share, but I'm not convinced that it's as pronounced as Fabien wants us to believe.

Composer is a nice step forward, but it's still behind of what bundler can do. One of it's main problems is that it created a completely new package format, so you need a new package repo - now they're at a respectable 1900 packages. Bundler uses the regular rubygems packages and has the full list of over 40.000 gems available. All tools that used to work with gems still work. There's also a couple of features that it's missing (local overrides for development, binstubs, etc.) but I guess that's just catch-up work. That the commandline interface looks plain ugly is probably just personal preference (heck, why do I need to call 'php composer.phar' instead of 'composer'?) Last but least, it's pretty much a feature-wise copy of bundler - that's maybe "on par" but not "the most awesome and best thing in existence".

So yes, PHP has taken huge steps forward but it's still ugly. You can get shit done if you know your way around and you can write amazing and elegant software in it - it's just harder than it needs to be.

<comment><USER32> While Composer introduced a new package format, it can be used to retrieve PEAR packages, 'plain' zip files and even git, svn and hg repositories - <USER2> these can be integrated even if they don't contain a composer.json file, needing just a little extra configuration in your project. This is a huge step forward and very convenient.

<http://getcomposer.org/doc/05-repositories.md>

I don't know how Bundler handles this and it probably isn't even needed, as gems are just the standard in Ruby but PHP didn't really have a standard besides PEAR and Composer brings everything together.

<comment><USER31> Well, it's not needed - that's my point. Bundler just uses the one well- established format for packaging libraries and declaring dependencies. Even git repositories and local code uses the same depency-declaring format: A standard gemspec. Otherwise bundler just stays out of the way to do it's main job - dependency resolution. There is no such thing as two package formats in the ruby world. There is now in the PHP world - PEAR and Composer (and zip and tarfiles). PEAR has always been severely lacking - no way to install two versions of the same PEAR package, improper dependency-tracking - so I guess that's required. It's probably a huge step forward, but it's still not "better" to be able to track two package formats "with just a little extra configuration" instead of "it works just fine without extra work with the default package format." And that's exactly what the article claims: "Yes, PHP has a better dependency manager than any other languages.

<comment><USER32> I didn't mean to say it is better than all other dependency managers and basically didn't want to argue at all. My point is just that I am happy that Composer is around now, as it lets me include all dependencies from various sources in a convenient and reliable way. So no matter which dependency manager for which language is 'the best', Composer definitely means better times for all PHP developers.

Seems that Ruby had one good standard solution with gems for a long time, let's hope that Composer has a similar bright future. From my perspective, it's already the standard and including a composer.json file is a 'best practice' for all 'well-connected' PHP developers releasing a library these days.

</comment></comment></comment></comment><comment><USER33> I think at this stage it would be tempting to give some kind of penalty to PHP good/bad posts. Pretty much everyone who cares one way or the other has taken a position and there is a minimal amount of people actually moving one way or the other.

Anyone who frequents Hacker News is well aware of the options out there for web development. If some people decide that they like PHP for any number of reasons and produce awesome stuff in it great. If some decide they hate PHP and go produce awesome stuff in another language then that is great to.

One thing is for sure we have seen a lot more of "this is all the reasons that PHP is bad" than "PHP killed my startup" posts.

<comment><USER21> There are almost no "X killed my startup posts" at all. Indeed, there are very few "killed my startup posts" of any kind. So that means nothing about PHP. It means that people don't see a lot of benefit in publicly advertising failure and then flagellating themselves for their own choice of tools. People don't do that, they just quietly switch.

People do hear about the problems with PHP, when they are mentioned. It's good to have specifics available rather than just delivering some general subjective statement, which is why we get one article after another highlighting various screwups in the project itself.

You can use any Turing complete language to write programs. That sets an upper bound on how difficult it can be to do virtually anything. But this is hardly a defense of PHP. There are also principles of good engineering beyond "write something which seems to work for now in any way possible".

</comment></comment><comment><USER28> Namespaces, closures and traits are "all the bells and whistles you might dream of in a modern web language"? Really? Now I understand why Lisp users are smug. And that's ignoring the basic syntax touted as _a feature_.

What I _actually_ dream of in a web language (or any language, for that matter) is quite a bit more. I want to be able to get event-driven IO without writing event-driven code. I want to get parallelism for free or as easily as possible. I want to encourage smaller functions and reduced coupling. I want good, or at least decent, performance with no especial effort. I want a consistent and elegant underlying design rather than an ad-hoc collection of features somebody thought were useful.

Ultimately, I want a high-level, modern language that's concise, fast to write, easy to maintain and reasonably performant. And PHP is none of those things. Which is why it's no good.

<comment><USER30> Well, we can all dream, but what are you using now do get things done and make a living? I'm pretty sure Python and Ruby fail your criteria.

Using the "perfect language" is a luxury that I for one can't afford. I need something that I can use reasonably easy and that is sought by employers. The fact that is has event-driven IO and parallelism (what kind of parallelism do you need for web sites?) is nearly irrelevant.

<comment><USER28> Yes, Python and Ruby do fail my criteria. Which is why I don't advocate them either.

I'm currently using OCaml, but I would probably prefer to use Haskell. They are both far ahead of PHP.

Assuming your website is doing anything non-trivial, parallelism would certainly be useful. Just because it's a web project does not mean you're not doing something computationally intensive, after all. But even if you don't need it, it certainly doesn't hurt to have the option!

Event-driven IO allows you to maintain more connections on the same resources than a thread-based model. There is just less overhead per connection. That's going to be relevant for most web projects. If you could get this for free (that is, without having to rewrite your code like in Node.js), why wouldn't you want it?

Just because employers seek PHP does not make it a good language, or even not a bad language. It just becomes a necessary evil.

Besides, that depends entirely on the job market in your area. Where I am (near SF), PHP is not in very high demand where Java, JavaScript, Python, Ruby and Objective-C are. I've also seen jobs using Haskell, Scala and (obviously) OCaml. This is obviously going to be different elsewhere, but my point is that it's all relative and not a function of any particular language's quality.

<comment><USER30> Well, OCaml and Haskell are nice, but I wouldn't think of using them for webdev. I would be literally unhireable in my area (major EU country).

I haven't done any webdev in years, but I am focusing on PHP instead of Python because I have more experience with it and it's easier to relearn. It will be a complement to my main skills which are actually mobile/desktop/embedded dev.

</comment></comment></comment></comment><comment><USER34> Yeah, PHP isn't perfect, we all know it has its quirks and oddities, but isn't that part of learning a language? What separates a hobbyist and professional PHP dev is experience, and knowing the correct method around such quirks.

In the end, PHP gets the job done. I've yet to come across a problem in my 11 years that was due to a bug or a quirk that I couldn't overcome.

Whether you defend PHP or rant about it, I still think PHP deserves respect within the programming community. It would be nice to see the end of rants and defensive posts, and for everyone to agree it's down to personal taste and experience. If we (defenders) are doing it wrong, then let us find out for ourselves.

<comment><USER21> What doesn't "get the job done"?

</comment></comment><comment><USER35> People who argue for PHP as a language always brings up this one argument: "PHP gets things done". Great. It get things done. Quick and dirty, but it gets things done.

That is all fine and dandy, but what when you need things done _proper_? How does it stack up then?

Oh. You mean you have to consider input-data as actual text, not as some byte- streams which incidentally maps to the same character-set you used to write your code with?

Oh. You mean I need to have locale-ware date, time and number-format handling?

Oh. You mean I need to actually validate these input-data and sanitize them for SQL injections and all that before sending off to the database?

Etc etc.

When you need things not just "done", but done _proper_ , how well does PHP stack up then?

It is my opinion (as in opposed to fact) that when you add that one tiny, but oh so important clause, all arguments for PHP being the one language which gets things done falls apart.

Or am I being too simplistic?

<comment><USER20> Have you written a production app for PHP in the last 5 years? It handles (out of the box) multibyte encodings, locale-aware number and date formatting, parameterized prepared statements for your SQL, etc as well as most any language.

<comment><USER35> I'll be intellectually honest and admit that, no, I haven't really touched PHP for anything near a production app in the last 5 years.

But to be absolutely clear: before PHP used to be the only language I wielded for money. I have enough lines of PHP on my back to claim the right to an opinion.

That said, last time I looked into PHP, modus operandi seemed to being focusing on making things easy, not making it easy to do things right.

AFAIK this one quote from "PHP is a fractal of bad design" still holds true and that if you ignore all the other obvious things (wildly inconsistent BCL, etc), it is probably the core reason why I can never bring myself to like anything PHP:

 _PHP is built to keep chugging along at all costs. When faced with either doing something nonsensical or aborting with an error, it will do something nonsensical. Anything is better than nothing._

AFAIK that's still true, and I find it hard to have confidence in any code written on top of something based on that core tenet.

Edit: Experience clarification

<comment><USER36> So why did you comment in the first place, in what world do you find it expectable to berate something with no working knowledge?

Also I have no trouble developing PHP code that halts on the first sniff of an error. But yes, with no experience of the language it will happily chug along.

<comment><USER35> See my clarification. I think I may have been a bit unclear and/or you may have misunderstood my post.

<comment><USER14> Talking about the PHP of 2006 and then blasting the PHP of 2012 is like talking about George W Bush and then blasting President Obama.

They're almost completely different language, and while PHP 5.3 certainly has warts it's vastly better than PHP 5.0.

<comment><USER37> To me, every PHP version being vastly better than the previous version says something: the current version is shit too, it's just going to take another few versions until you admit it :P

Compared to something like python, where version 3 has basically one major improvement over version 2 (ie, a unicode core); everything else was done pretty much right the first time, and massive changes aren't needed.

Heck, you can still use 2.5 (the python of 2006) quite happily today, and you'll be missing out on a few nice features that would make your life easier, but there's nothing _wrong_ with it like there is with previous version of PHP.

<comment><USER14> If I plot two lines on a graph for you:

y1 = 0.02x + 1

y2 = 0.10x + 0.5

Regardless of the fact that y2 started at 0.5, fully half of what y1 started at, at some point y2 overtakes y1. It's impotent to whine endlessly that a language used to be bad.

So PHP 5 years ago was terrible. PHP today is 'nearly as good' as Python (I'd argue it's better). In 5 years PHP is going to blow Python out of the water.

These languages that are 'better than PHP' have no appreciable market share, and it's not a vast conspiracy and it's not because PHP caters to the lowest common denominator. It's because they suck, fundamentally, at getting things done. WordPress doesn't exist in Python. Symfony doesn't exist in Python. Doctrine does, but PHP has more database drivers than Python so Doctrine is better.

You can be terse, elegant, and beautiful in Python. That's great, but no one I know has ever cared about what the code they're paying for looks like. They care about stability, agility, and testability - things you've been able to get in PHP since 2005.

<comment><USER37> I think your graph is accurate when it comes to the amount of effort put into polishing each language -- but as to actual quality, I'd firstly say y=1 is the goal (the language is basically complete; you can add more around the edges, but the core is solid and needs no more changes), and it doesn't account for the fact that with a constant large amount of effort as input, progress as output slows down exponentially due to backwards compatibility concerns. As such, I still think that starting off good and evolving slowly is better than starting off awful and rapidly turning into a giant blob of band- aids :P

Again with the scales, I agree that PHP is great for getting things done _to start with_ , and once you've started with something then carrying on using it is easier than changing. That's why my biggest and most successful project still uses PHP, even though experience has taught me that everything else is more productive after the initial setup hurdle~

Stability, agility, and testability have been in other languages for _decades_ , and in all three cases other languages have done them better, so I'm not sure why PHP having them since 2005 is supposed to be a good sign...

<comment><USER14> > I'd firstly say y=1 is the goal (the language is basically complete; you can > add more around the edges,

Not your functions, not your plane, you don't get to define parameters.

> starting off awful and rapidly turning into a giant blob of band-aids :P

PHP has been completely rewritten at least twice.

> everything else is more productive after the initial setup hurdle~

Can you give a single example of something in Python that introduces greater productivity than PHP?

> and in all three cases other languages have done them better

> so I'm not sure why PHP having them since 2005 is supposed to be a good > sign...

Now you're just being a pedant. The point is that it isn't 2005 and it's not 1978. It's 2012. Talking about what the capabilities of a language were almost a decade ago is useless.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER38> I disagree, just because PHP has recently obtained features long available in other languages doesn't bring it close to being on the same level. All the other ecosystems are still light years ahead in terms of features, and contain fewer gotchas.

<comment><USER39> What? You mean that while PHP figured out library management the other language ecosystems weren't just sitting on their hands?

</comment></comment><comment><USER40> Easiest language to learn for non-technical people? I do not believe that comment was made by someone who has tried to teach a non-technical person on how to program PhP. To get started to write a simple thing like a blog, you need to explain concepts like: classes, inheritance, public/private members, global/local decelerations, and context to name a few. Add that with the X number of ways each thing can be done, and the what ways are "right", and what ways are "wrong", and it becomes a huge information load for the student even before getting started writing something simple.

</comment><comment><USER41> IMO, more important than the language itself are the frameworks built on the language. Ruby might be _the best_ language ever, but without Rails it wouldn't have gotten famous. It wouldn't have mattered so much that Python is a beautiful language if Django sucked. If a good framework came out of the PHP community, we could forget that "PHP sucks". A good framework which prevented you from doing stupid things would be really great. Not sure if PHP has anything like that, at this moment.

I use PHP and Python(Django) - work and play.

<comment><USER39> I actually think that the PHP language itself is the cause of this framework disparity.

Alot of those nice framework features rely on higher level language features that are missing from or atrocious to use in PHP.

</comment></comment><comment><USER42> I am not convinced. My argument is not that PHP sucks or that anything else. It is rather that PHP is lexically tied to corner-case development. In that case PHP is very good at some things but not really all that great for others.

PHP started out as being a pre-processor for SGML documents. All PHP code is contained inside SGML program instruction tags. PHP has never changed this, so however it has developed it is still, in essence an SGML preprocessor because even today, all PHP code is contained in SGML PI tags.

This means that your class files, etc. all begin with opening a PI tag....

Now that doesn't mean there aren't some really cool niches for PHP. Using something like PL/PHP and the native XML support in PostgreSQL, you could do some pretty cool stuff. Similarly for lightweight web development there is simply not a better language.

But when you are building a framework where logic may have to be used in non- SGML environments, PHP is a very poor choice. This means when you choose PHP you are limiting yourself to web environments only. Better choices where there is any possibility of escape from the web include Perl, Python, and Ruby.

<comment><USER36> You've heard of PHP SAPIs right? You can most defiantly use PHP outside of a "web environment". I have PHP daemons managing the sending of email and sms, and another used to manage incoming data that is fed into our local database. These have all ran for years (7+) with no issues.

<comment><USER42> I have used it for all kinds of things. However your code is still embedded in SGML output ;-)

<comment><USER36> Erm, no it is not.

<comment><USER37> Your code doesn't start with a "<?php" tag?

<comment><USER36> What does that have to do with SGML?

<comment><USER42> It's the opening of an SGML process instruction tag. That's why PHP code is inherently embedded in SGML documents......

That's why the LedgerSMB project uses Template Toolkit with <?lsmb ?> tags (that and [% %] causes problems in LaTeX).

<comment><USER36> You seem to think you have some understanding of PHP which you blatantly do not. You've made a nonsense assumption based on the choice of tag used by PHP to tell the interpretor to treat the text following the tag as code and not to direct it back out the SAPI.

<comment><USER42> Ummm... I think you are missing my point.

<html> <body> <?mypitag ... ?> </body> </html>

That's an SGML document. It doesn't matter where the PI tag is, or what is in it, it's an SGML document.

<?printstuff

'<html> <body> <p>fun stuff here</p> </body> </html>'

?>

That's still an SGML document.

<?php

# logic goes here

?>

That's an SGML document.

This is not splitting hairs. The reason is relatively subtle.... When you are doing SGML stuff an extra newline or a space in front of the opening tag really doesn't have any effect but if you do any output in binary form, it's a mess.

<comment><USER36> You are making little to no sense. Sorry, but I've got to give up on this thread.

<comment><USER42> You are looking at it from the interpreter's perspective. I am looking at it from a document semantics perspective and what this means for more complex application environments.

Let me give you an example.

Suppose I have a GUI application that prints some XML fragments to standard output. The most natural way to do this in PHP is to write an XML pre- processor which happens to make decisions based upon operations in the GUI. In other languages you would print to standard output explicitly and the GUI would be primary. In PHP the XML output would be primary and the GUI would be secondary.

In fact your entire GUI is sort of contained in XML fragments to start with.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER43> What would happen if you could put a <?python> tag with python code right in a page just like you do with the <?php> tag? Is this even theoretically possible?

I feel like the biggest advantage PHP and classic ASP have is that there is a low barrier to get the most basic dynamic content working. If you're not a programmer, you don't need to understand a framework or a design pattern to get things going.

<comment><USER21> There's no reason you couldn't. It wouldn't be Python, but you could do it by defining a new file format to be parsed by the server (mod_whatever).

The earliest Python web frameworks were obsessed with this kind of stunt and it gave rise to a profusion of templating engines, some of which look pretty much exactly like what you are discussing.

I think what happened is that people tried it and found that the advantage is not that great, but the disadvantages are substantial for things significantly beyond "hello world".

</comment></comment><comment><USER44> > PHP is used by 77.9% of all the websites (...) PHP must have done something > right, no?

My favorite answer to this is "because millions of lemmings cannot be wrong".

PHP is a horrible language. Like FORTRAN and COBOL. Like BASIC.

Let me be clear about this. It _is_ a horrible language.

Having said that, a good programmer can make good programs even in the most horrible (and I'm deliberately excluding the deliberately horrible ones) language. It is possible to write elegant PHP just like it's possible to write concise Java. All it takes is lots of discipline. Something most programmers, sadly, lack.

PHP is immensely popular and its runtime is incredibly easy to deploy. I sometimes have small fights with Apache to enable some WSGI app (I never remember every detail I have to include in the configuration) but PHP is unusually easy to set up. That probably is a good explanation on why it's so popular on cheap hosting - because it's easy to manage. That also makes it a good choice for quick projects such as hotsites. I prefer to do those on Google's App Engine, but this is a question of taste, not of availability. In all fairness, those sites could be developed in ASP/VBScript and I wouldn't regard that as a mortal offense - they'll live for months under a single release lifecycle. Use whatever gets the job done for less. And programmers without discipline usually cost less.

Much like there are millions of lines of COBOL, FORTRAN and BASIC we'll never get rid of, there are millions of lines of PHP that'll keep running for decades. PHP is a fact of life. I won't be using it for any new projects and would question the sanity of anyone willing to start a long life one with it, but each developer must choose which tools they want to spend their lives with.

</comment><comment><USER45> "PHP is the easiest language to learn for non technical people".

I believe that is a flawed statement. I think looking at the number of existing sites and using that as evidence that because there are a large number of PHP websites, the website authors must have made some value judgement at some point on the easiest language available and arrived at PHP, is incorrect. I think the early availability of PHP as a web language, the perception of it as an easy language, and the wide install base drive its adoption.

I helped my brother learn PHP and JavaScript at the same time, my belief (at the time) being that PHP would be the easiest server side language to learn. Watching him struggle to: A) find adequate, modern PHP tutorials, B) see good examples of data structures, and C) understand the division between server side and client side development made me question my decision to have him learn PHP. By comparison, while JavaScript lacked a centralized site (php.net) to educate its users, he was able to find more than enough resources to help get learning fast.

</comment><comment><USER46> Well, the reasons I started learning PHP were:

1\. It was the most popular web language when I started (in 2000), the alternative being ASP...

2\. It's extremely easy to use and set up. Most starting programmers/developpers work on Windows. If you want to start developping on Ruby or Pythons you have two possibilities:

\- Install linux, which (whatever you may think) is not easy for any newbie.

\- Try to work out the Windows ports of your programming language of choice. In the case of ruby, you have to find windows installs for ruby, gems, bundler, rake, rails (or whatever app you want to use), git, probably cygwin, your webserver of choice, etc... Most of these elements are not made for the Windows ecosystem and the ports are usually pretty poorly documented.

If you use PHP, you just have to: 1. Install XAMPP. 2. Click on "launch server" 3. go to <http://localhost/>

This is why PHP is still popular.

</comment><comment><USER47> They have maid a decent progress in 5.4 <http://php.net/releases/5_4_0.php> [http://net.tutsplus.com/tutorials/php/php-5-4-is-here- what-y...](http://net.tutsplus.com/tutorials/php/php-5-4-is-here-what-you- must-know/)

<comment><USER37> "Has made great progress and will continue making great progress" is another way of saying "got it wrong first time and is still getting it wrong now" :P

It took more than _10 years_ and almost _6 major versions_ of a supposedly quick and easy scripting language to have short array notation? Or binary numbers? Seriously? And this _improves_ your faith that they know what they're doing?

</comment></comment><comment><USER48> If all your friends jumped off a bridge while programming in COBOL, would you follow them?

If Visual Basic was a popular language, did that make it good?

Maybe PHP Addiction is real: <http://www.marco.org/2012/06/29/php-addiction>. It does seem like its users will go out of their way to defend their choice, as if it really matters what anyone else thinks. Jeff Atwood didn't really rant on PHP so much as link to another rant and lament that there aren't any decent alternatives that are as easy for the rest of the world to deploy. He even called for us to quit whining about PHP's shortcomings and do something about it.

Why is that suggestion so offensive? What's wrong with trying to advance the state of the art of Web development?

Did anyone attacking this "rant" actually read the whole thing first?

</comment><comment><USER49> OK, I hate PHP. It's ugly, and I don't want to code anything with it.

Good developers mostly aren't available to small shops like mine; I don't have anything to get them in. I must do with young, cheap developers anyway. Young cheap developers knows only one language, to be chosen among PHP or Java (that's just the way it is).

So I'm getting a whole lot of interns coming in for two months at a time, and they mostly know nothing but PHP. so we make them code PHP.

They built a nice application in a few months for the quarter of the money I would need to get an half-decent <your preferred language here> developer. Getting more done with less money, from a business perspective that's the only thing that counts.

<comment><USER50> Using intern developers to write PHP.

I really hope you're using a framework, because that above sentence is a recipe for disaster.

<comment><USER49> No, we're using careful project management, code reviews, the interns are very happy because they're learning a lot, and the code is tolerable. Code elegance doesn't put food on the table, anyway.

<comment><USER50> Actually that sounds fine. Good they are learning.

</comment></comment></comment></comment><comment><USER51> This post reminds me of the infamous Chris Rock routine: <http://www.youtube.com/watch?v=f3PJF0YE-x4#t=130s>

"I take _care_ of my kids! I ain't _never_ been to jail!"

</comment><comment><USER52> Oh, not this shit again. This article shows everything that is so wrong about people who continue to defend PHP

/PHP developer for 6 years

<comment><USER3> I think you forgot to back up an argument there.

</comment></comment><comment><USER53> Composer has been a game changer for me in the last couple of months. Getting setup on a big framework (Symfony2), or even a small framework (Silex) always felt like a bit of a pain.

</comment><comment><USER54> As a developer I have great respect for Fabien Potencier and his contributions to the PHP community. Sadly thoguh, I think he's done so in vain. You cannot fix what's infinitely broken.

* PHP may have evolved to support many new methods and features that is expected from a modern language, but mixing and mashing ideas and implementations from other languages in a semingly random fashion doesn't make a language good; only messy. It still and always will lack a proper philosophical design.

* PHP's ecosystem is far from healthy. It's flooded with outdated and/or badly written code, so it really doesn't matter if dependency management is good. Wordpress is proof of this, just look at the source.

* PHP is neither easy to learn or code (correctly). It's just so forgivable that you can do more or less everything wrong and still have a working application. Fabien, you should know this.

* PHP is a resource hog compared to the competition; even with the tiniest stack. I.e. running Node.js will use less then a third of the resources compared to a LAMP stack.

There will never be a "best language" to rule them all. Every situation have different needs. Sure, PHP have filled its purpose during the years, but I'm certain that we've hit peak-PHP. It's the IE of programming languages, and its slow death have already begun.

</comment><comment><USER55> I'll admit, the new-ish built-in web server in PHP is fantastic and it definitely makes me want to use PHP more often. Configuring Apache, setting up virtual hosts, fixing directory permissions, etc. was horrible.

Composer also looks cool, and I'm going to give it a try. I never understood PEAR/PECL/etc and was never quite able to get them to work properly.

</comment><comment><USER56> Granted, there has been a lot of PHP bashing lately and by and large, those who bash PHP the most - whether they are right or not - generally have little to no meaningful experience with it and are re-iterating whatever they've read about it. Fact.

However, this is just stockholm syndrome, plain and simple. Fabien is the author of Symfony.

</comment><comment><USER57> Don't forget to turn off the Easter eggs when you use your default install of PHP (expose_php = off in php.ini). [1]

1\. [http://en.wikipedia.org/?=PHPE9568F36-D428-11d2-A769-00AA001...](http://en.wikipedia.org/?=PHPE9568F36-D428-11d2-A769-00AA001ACF42)

</comment><comment><USER58> It's like he didn't actually read Jeff Atwood's article, or if he did, he entirely missed the point. It _wasn't_ a rant about PHP; it was a _rant about people ranting about PHP_! So much heat; so little light.

<comment><USER59> This wasn't a response to Jeff Atwood's article. It was a response to all the articles, with Atwood's being the "straw."

<comment><USER58> Really?

> Rants about PHP are everywhere, and they even come from smart guys. When > Jeff Atwood wrote yet another rant about PHP…

That's not how it reads to me.

</comment></comment></comment><comment><USER60> PHP is ugly? So are knives and forks but i still prefer to eat with them.

</comment><comment><USER50> PHP is big because 10 years ago, it was the best choice. Back then, the non- microsoft options were Perl, ColdFusion, Java, and PHP. PHP was the best for web development out of that.

This isn't the case anymore. PHP has been far surpassed by Python and Ruby.

PHP is a wonderful templating language.

Where does my opinion come from? I switch us from PHP to Python after writing a large CMS in PHP.

<comment><USER61> I've written "large" systems in PHP and some things annoy me, but I imagine this is true with other languages too (I hear from Ruby and Python devs all the time, some things get annoying).

That said, I spend most of my time on the web writing templates, and PHP is amazing at making that easier. There's a good reason PHP is used in ~78% of all web sites -- most of them are basic blogs or content sites.

Most web development is just templating attached to a business model layer, so why not use a language ideal for templating?

</comment></comment><comment><USER37> Does PHP have a function to generate a new URL that is the current URL with one of the GET parameters changed yet?

After working with PHP for years, I've taken a look at rails and a few python frameworks, and looking back to PHP it makes me sad that I have to keep using a "web oriented language" that doesn't come with basic web features :-(

<comment><USER62> This is an excellent point that I think too few PHP developers care to admit.

</comment></comment><comment><USER63> If people who bash about PHP , had used symfony2 framework, they would have changed their mind to some extent..

<comment><USER62> I love and use many parts of symfony2 (as well as other high-quality libraries); however, that doesn't change my highly negative opinion about the core PHP language. It is still a far cry from desirable, elegant, fluent, or expressive.

</comment></comment><comment><USER64> Composer is pretty nice, but there's at least once vital package that's missing from it: PHPUnit.

As long as the only decent testing framework[1] isn't in the package repository, It just seems somehow not "official" enough.

[1] which still has more than its fair share of legacy warts

</comment><comment><USER65> If Fabpot seriously believes Composer is better than Bundler/apt/Maven, then he's crazy.

<comment><USER66> Have you used it at all? I'm not going to pretend it's better than Bundler, we took a lot of inspiration from it and we may have a few unique features compared to it, but that's it. apt is pretty different anyway since it does system level stuff. Maven I think is insane, it does way more than a package manager should do. That said when you look at Python for example, the package management landscape is a scattered mess, and there is a new "greater better" solution every couple years. I wouldn't call that a better situation than what we now have with Composer.

<comment><USER67> Maven is actually pretty sweet and good.

I know people have their own "perspective" when it comes to Maven: some said it's too big, too complicated, yadda-yadda. Some said it's the best tool out there.

The thing here is that you don't need to know Maven that much to use it. Especially if you were to use it with IDEs.

People typically use IDE to generate the absolute minimum Maven pom.xml file initially when they set up the project. From that point onward, if you're using mostly open-source library, the OSL website will give you snippet on how to add the JAR in Maven. All you have to do is to copy paste that snippet and you're done.

People who said that Maven is overly complicated typically tried to learn Maven from Zero to Expert rather than to "just use it".

It didn't take very long for me or many of my co-workers to become familiar and use Maven effectively from not-knowing to "yes, we can have Rails-like project structure/automation , deployment and packaging for multiple environment in place".

Sometime I'd argue that there's no point separating Bundler, Rake, and Gems. You need all 3 of them and that's what Maven does (and more but you don't have to know until you do...)

<comment><USER62> > Some said [Maven] it's the best tool out there.

Generally these are people that haven't tried anything better.

BTW, as someone who uses Composer and Bundler almost daily now (npm occasionally), I must say, Composer is right up there and it does offer some unique features that neither of the other two have.

Let me say this. Composer is probably one of the best things to happen to PHP in a LONG time.

I'm not saying I prefer PHP over Ruby, but given I am frequently tasked with providing PHP solutions, Composer is the way to go.

</comment></comment></comment></comment><comment><USER68> Funny. People criticize PHP the language and the PHP fanboys retort by praising PHP the platform.

Jeff Atwood more or less said that we should provide the platform advantages of PHP in other languages in order to steer new developers there.

<comment><USER14> You can't provide the platform advantages of PHP in other languages because either there aren't enough programmers in that language (Ruby, Python) or that language is fundamentally much more difficult to work with (Java).

<comment><USER10> So create something new.

<comment><USER14> But I like PHP. Even with its numerous warts, it's the easiest language I've ever written.

</comment></comment></comment></comment><comment><USER69> Yeah we know, weak typing and function parameters inconstancies sucks.

Move along :)

</comment><comment><USER70> From the article:

 _> PHP is used by 77.9% of all the websites whose server-side programming language is known._

Selection bias. PHP Has a higher tendency to advertise itself.

</comment><comment><USER71> Great post. The grammar in the post title has a bit to be desired though. "than what"?

<comment><USER72> English is not his first language.

</comment></comment><comment><USER73> Do PHP engineers even know what multithreading is?

ps. I don't mean crontab

<comment><USER74> Do you even know how many days/weeks/months I've seen engineers waste on tracking down threading issues?

ps. I don't mean sewing shirts.

<comment><USER73> PHP programs are indirectly affected by those issues anyway

</comment></comment></comment><comment><USER75> You can't polish a turd, but you can roll it in glitter.

</comment><comment><USER76> "homeopathy" arguments.

</comment><comment><USER77> "PHP is the best web platform ever", because it (finally) has a decent package manager. And don't mind that far fetched statement, the author will surely delete any rude comments.

Congrats, PHP has a package manager. This does nothing to shake my feeling that PHP's most ardent advocates have little hands-on experience with the more full-featured alternatives. You know, like the ones that also have decent package management without PHP's baggage and limitations.

edit: hell, calling PHP a "web platform" at all is insulting. Maybe if "web platform" is constrained to JSP/PHP/ASP style pages with no more complexity. Don't mind anything that requires websockets or anything other than... PHP style page rendering.

Can we stop with the "PHP is everywhere so it must be good meme"? PHP's availability makes it convenient; it doesn't make it good. I said it before and I'll say it again despite its painful obviousness. If you want to write a random script and upload it to some $2/month hosting, PHP is great. If you're going to build a real webapp that is going to have developers working on it and real users hitting it, you're going to be on a VPS or colo or on your own metal and have all sorts of choices that... have package management and aren't PHP. And if we're talking about throwaway quickie scripts, who really cares anyway?

<comment><USER78> Facebook.

<comment><USER28> Yes. And now Facebook is spending a ton of resource and man-hours programming around this. They had to write their own compiler!

Also, I think they are trying to move away from PHP as quickly as possible without rewriting the entire site. The new projects and tools are not in PHP; moreover, I think most of the new people they hire never have to use PHP at all.

Finally, just because they managed to use PHP to run a bit site does not mean it is the best web language, or even a good web language. It just means it's adequate.

<comment><USER30> Do you have inside info on this? I've seen several people from Facebook comment that they are in fact using PHP.

The fact that they're compiling to C++ is a consequence of the slowness of the programming language implementations of those languages that are used traditionally for web development. AFAIK Ruby was and still is the slowest of the bunch.

<comment><USER28> A couple people I know well spent the summer there (I actually visited one at the old headquarters; it was pretty cool). One now works there full time (the other hasn't graduated yet). I also talked to some fulltime engineers who were not using PHP.

Now, it's reasonable that I did not get the full picture, but the people I did talk did not use PHP themselves and claimed that new projects didn't either. Perhaps this varies per team. My impression was that existing code bases using PHP were still under active development (that is, getting new features) but new projects and new developers did not use PHP.

<comment><USER30> Interesting. What were they using, C++? I've heard about D...

<comment><USER28> The particular people I talked to were using C++. But I think there is even a team using Haskell for some internal tools :).

</comment></comment></comment></comment></comment></comment></comment><comment><USER79> PHP still can't access email inboxes inherently, can't do CSV import, can't download packages from GitHub the way Bundler can, doesn't support metaprogramming, has a hacked-together OOP system, and has an absolutely horrid syntax.

Why am I meant to use PHP again?

Oh yeah, because you haven't discovered Ruby yet.

<comment><USER80> Uh, Ruby can't do most of that out of the box either. Lots of those things you mention you need gems for.

And really? Can't do CSV import? What does that even mean?

I mean, it's a programming language. There are packages you can get that will do those things, and if there aren't, you program them.

I'll give you the point on the syntax.

</comment></comment><comment><USER81> I hate this apologist bullshit. Yes, we know that there are a lot of PHP sites on the net, we aren't retarded.

If PHP wouldn't be such a wide-spread problem, people wouldn't have to spend so much time fighting against it.

One positive thing: His post was didn't kill my spell checker, that's an impressive achievement for a PHP developer. You don't see coherent sentences that often from those people.

</comment><comment><USER82> I'd stay away from a language that has function names like array_keys or allows you to write array("a" => "green", "red", "blue");

<comment><USER83> What's wrong with array_keys? It's extremely useful.

Java has keySet(), Ruby has hash.keys, etc.

Your second argument is even dumber. Yes, PHP lets you do lots of things, which improve the speed of development. If you don't like it, don't write it that way.

<comment><USER21> I wouldn't pick on the example, but you've made me curious: how does it improve the speed of development to have array("a" => "green", "red", "blue") ?

<comment><USER83> This is just a side-effect of the fact that arrays in PHP are also hash-maps. That improves the speed of development, not your example.

<comment><USER82> And you think it's a good idea to have arrays be also hash maps?

<comment><USER83> As long as you're aware of it.</comment></comment></comment></comment></comment></comment>