Live data from Hacker News

Taking PHP Seriously [pdf]

raw.github.com

51–60 of 155 posts

Re: Taking PHP Seriously [pdf]

#51
post #4

This was an interesting talk. My own interpretation was that PHP's strengths were claimed to be: 1) State => because endpoints have no persistent state 2) Concurrency => because there is no concurrency model 3) Transparency => (1) + (2) + fast reload = easy to understand These combined give the language nice programmer "ergonomics" (Keith's terminology). It also limits the collateral damage any particular change to t…

Indeed, there's something to be said about shared-nothing. Lua takes the cake in that since it can be so easily fit into so many nooks and crannies.

Re: Taking PHP Seriously [pdf]

#52
post #44

At this point we almost need to stop saying facebook programs in PHP. I know this was defending PHP, but look at what is happening. Facebook ( big engineering firm, lots of developers and resources ) could not get php to work for them short of rewriting the core (HPHP ) and then adding on features to the language that most other languages have determined are useful enough to be baked into the language. Here is my TL;…

could not get php to work for them short of rewriting the core (HPHP ) I've heard this argument before, but it's important to realize that Facebook was able to use standard PHP up until the point when they had roughly 500 million users. Unless your site has a half billion users you can't compare your use case to Facebook's.

They're making three sorts of changes: 1) removing/restricting the footguns in the language 2) adding interesting features taken from other languages (typing, traits, etc). 3) creating a new VM with better performance.

As far as I can tell, only 3 is obviously something that only affects whether you can use the language once you have a certain number of users. The first two are really about changing the language.

Re: Taking PHP Seriously [pdf]

#53
Before this turns into a recanting of the points in the "PHP is a double-clawed hammer" post again, I would like to remind people that PHP still has a place in the business world that nno other language has stepped up to fill.

http://blog.samuellevy.com/post/41-php-is-the-right-tool-for...

Please stop complaining about how horrible PHP is if you don't use it or have. intentions to replace it.

Re: Taking PHP Seriously [pdf]

#54
post #34
post #23

Earlier quoted context omitted.

In what ways is PHP less hassle than Python? I don't understand this argument.

I'm going to say it, better documentation. I don't know, maybe it's just me, but I find it takes me significantly less time do find out how to do something in PHP, or a PHP library than in the corresponding Python. Though, there are obviously exceptions to this.

Ooh, yes. While PHP's docs sometimes promose horrible worst practices, they are more detailed and fleshed out than Python's.

Re: Taking PHP Seriously [pdf]

#55
post #23
post #21

Earlier quoted context omitted.

I code in Python, BASH, C, and PHP on a regular basis and still strongly prefer PHP for everyday coding and hobby tasks. I even prefer to create command-line scripts in PHP (though will switch to Python if it's large to begin with). For me getting Flask to work properly under NGINX + uwsgi was such a hassle. Having to tell it what module, and hooking things up to touch versus just passing to PHP under fast cgi. To be…

In what ways is PHP less hassle than Python? I don't understand this argument.

Abstract classes in Python are kinda bolted on http://docs.python.org/2/library/abc.html

They're native to PHP http://php.net/manual/en/language.oop5.abstract.php

Re: Taking PHP Seriously [pdf]

#56

Earlier quoted context omitted.

could not get php to work for them short of rewriting the core (HPHP ) I've heard this argument before, but it's important to realize that Facebook was able to use standard PHP up until the point when they had roughly 500 million users. Unless your site has a half billion users you can't compare your use case to Facebook's.

They're making three sorts of changes: 1) removing/restricting the footguns in the language 2) adding interesting features taken from other languages (typing, traits, etc). 3) creating a new VM with better performance. As far as I can tell, only 3 is obviously something that only affects whether you can use the language once you have a certain number of users. The first two are really about changing the language.

Maybe I should have expressed myself more clearly: The comment I replied to seemed to indicate that PHP must be bad since Facebook had a need to change it. My point was that, given the fact that Facebook has way more users than other sites and mostly serves non-cacheable pages, their needs are different than the needs of 99.9999% of other sites in the world, so the fact that they were forced to change PHP doesn't say anything about PHP's quality as a language.

Re: Taking PHP Seriously [pdf]

#57
post #44

At this point we almost need to stop saying facebook programs in PHP. I know this was defending PHP, but look at what is happening. Facebook ( big engineering firm, lots of developers and resources ) could not get php to work for them short of rewriting the core (HPHP ) and then adding on features to the language that most other languages have determined are useful enough to be baked into the language. Here is my TL;…

Video of the talk is not up yet, and it's a little cryptic with just the slides. But one of the points I was trying to make is that PHP actually makes you more likely to be successful than a lot of its competition. The lolsy stuff on "The Case Against PHP" slides is all you ever hear because ... well, because they fit on slides. They're immediately, obviously weird. But these problems are shallow. There are deeper properties of the language and its interaction with the environment that overcome those problems, and then some.

Also, it's a little obscure for languages like PHP where we're unused to making architecture/implementation distinctions, but if HHVM is good then PHP is good. It runs the same core language as php.net. To the extent we don't, it's likely to be a bug these days. I think HHVM is a better implementation of that language than php.net, but I am biased, and that isn't the point of the talk. We're also chipping away at running other popular programs, extensions and all: http://www.hhvm.com/blog/?p=875

Edit: transposed sentence

Re: Taking PHP Seriously [pdf]

#58
post #3

obligatory X is better than php flames on the way.. php just works.. end of story

$productid = "0x4zz5"; print $productid + 4; If printing "8" is your idea of a working interpretation of that code, then PHP is the language for you. If not, then PHP doesn't work. End of story.

8 is sane here. The + operator adds numbers. It converts the string to a number implicitly in the process. it takes "0x4zz5" and tries to parse as much as possible. Since "z" is not a valid hexadecimal digit, it stops at z, and reads it as 0x4.

Of course, it is better to manually convert.

Re: Taking PHP Seriously [pdf]

#59

Before this turns into a recanting of the points in the "PHP is a double-clawed hammer" post again, I would like to remind people that PHP still has a place in the business world that nno other language has stepped up to fill. http://blog.samuellevy.com/post/41-php-is-the-right-tool-for... Please stop complaining about how horrible PHP is if you don't use it or have. intentions to replace it.

I actually feel the same way about "classic" ASP. Yeah, it wasn't pretty. But for simple CRUD pages of the day, it was damn simple and you didn't need ninjas or rockstars to get stuff done.

Re: Taking PHP Seriously [pdf]

#60

Before this turns into a recanting of the points in the "PHP is a double-clawed hammer" post again, I would like to remind people that PHP still has a place in the business world that nno other language has stepped up to fill. http://blog.samuellevy.com/post/41-php-is-the-right-tool-for... Please stop complaining about how horrible PHP is if you don't use it or have. intentions to replace it.

I couldn't agree more.

Having worked with clients that publish thousands of articles of content per month the best solution for the job at the end of the day is still WordPress. Have a client that needs an online store? Magento (both of which are built in PHP).

Development shops don't have time to custom build CMS's and eCommerce solution because their clients don't give a shit what language or framework their site is built in.

Show me a CMS built in ruby, python or javascript that comes anywhere near WordPress and I'll gladly switch. Unfortunately it just doesn't exist. Like you said, PHP has its place and until something better comes along stop complaining.

Post reply on HN