Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 7 deployment at Dailymotion

engineering.dailymotion.com

Post reply on HN
Print view View original

121–130 of 166 posts

Re: PHP 7 deployment at Dailymotion

#121

Post by nkozyra »

kyriakos wrote: post #65
nkozyra wrote: post #40

Earlier quoted context omitted.

Hack's influence is all over PHP7, unsurprisingly. As someone still bound to PHP due to technical debt, I'm thrilled this happened. PHP still has warts, but changes in 7 are tantamount to ES5 :: ES6. The language feels more mature, real, sensical.

A much needed overhaul to the utility functions (array, strings etc) should be the next step.

Of course, but they won't do that because of backwards compatibility and I get that.

It's one of the nice parts of rebranding. Hack could keep and throw out anything they wanted because it was intended for private FB use. At some point, PHP will have to start cutting off the stdlib PHP4.x warts. There's enough about PHP 7 that's good enough to be compelling to anyone working in an interpreted language on the web, but the (well earned) reputation keeps a lot of people away.

Re: PHP 7 deployment at Dailymotion

#122

Post by ascagnel_ »

babyrainbow wrote: post #89
Akujin wrote: post #38

Earlier quoted context omitted.

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

> The variables are there. You can use them or ignore them... Ever worked in a team?

The team can set up a linting rule to flag any use of superglobals and block committing them.

Re: PHP 7 deployment at Dailymotion

#123

Post by phatbyte »

Akujin wrote: post #38
nikcub wrote: post #14

Hack and HHVM solves what is, IMO, the worst feature of the default PHP runtime environment[0] - and that is the superglobals. It wasn't mentioned in the post from Slack, but default superglobals and the earlier register_globals design decisions are the worst and most impactful wart in PHP. Because it was designed as a templating language, the default web server interface, which is CGI - will auto-expose all variable…

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

Doesn't PHP 7 support type declarations?

eg: function foo(int $number) { ... }

Re: PHP 7 deployment at Dailymotion

#124

Post by Aaargh20318 »

Akujin wrote: post #38
nikcub wrote: post #14

Hack and HHVM solves what is, IMO, the worst feature of the default PHP runtime environment[0] - and that is the superglobals. It wasn't mentioned in the post from Slack, but default superglobals and the earlier register_globals design decisions are the worst and most impactful wart in PHP. Because it was designed as a templating language, the default web server interface, which is CGI - will auto-expose all variable…

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

> There's absolutely NOTHING wrong with having $_POST['whatever'] inside a controller as long as you're doing proper checks.

The last part is why this is a problem.

The truth is that programming is simply too difficult a task for human beings. Software is so complicated with so many moving parts that it is impossible for anyone to understand all the details of even the simplest piece of code. This is why we have operating systems, programming languages, and frameworks. Or more generally: this is why we have abstractions and tools: to make it possible for humans to actually write somewhat functional software.

This is also why you not only want languages, frameworks and tools that let you do the right thing; you want them to prevent you from doing the wrong thing. You want to reduce the number of things you have to think about to the absolute minimum, simply because no one is smart enough to fully understand everything that's going on. That is why you want things like strongly typed languages.

Sure, you can make something that works and is safe, if you make no mistakes. The point is that we want to take the human ability to make mistakes out of the equation as much as possible. Sometimes it is inevitable because of what a language, framework or tool is used for. In the case of PHP there are a lot of ways to shoot yourself in the foot that do not need to exist in a high-level language such as PHP, and that is the reason why PHP sucks and is a bad idea. It is way more fragile than it has a need to be.

Re: PHP 7 deployment at Dailymotion

#125

Post by vcarl »

wvenable wrote: post #59
vcarl wrote: post #39

Earlier quoted context omitted.

This is the typical "hatred of the web" that I usually ignore. ES2015 brought a ton of huge language improvements that are still filtering out into usage, Babel means you can use them all now without waiting for browsers to implement them, Webpack gives you a ton of flexibility for packaging it, Eslint allows you to lint in a completely pluggable way, NPM (and now Yarn, which fixes many of NPM's problems at scale) al…

The length of that paragraph and the number of tools mentioned is exactly one of the problems of web development. It's like missing the forest for the trees. And even with all the huge language improvements, it's still no where near the capabilities and safety of non-web languages. But I don't disagree that it's possible to write very high quality JavaScript code -- it's just a little bit painful.

It's certainly a little bit painful, but that's only because these things are brand new. These tools let you create applications most comparable to native apps, and could you imagine developing for iOS or Android without a Xcode or Android Studio? The current trajectory is very, very good, and it's with a bunch of tools and ideas that came from the community.

Re: PHP 7 deployment at Dailymotion

#126

Post by [deleted] »

vcarl wrote: post #125
wvenable wrote: post #59

Earlier quoted context omitted.

The length of that paragraph and the number of tools mentioned is exactly one of the problems of web development. It's like missing the forest for the trees. And even with all the huge language improvements, it's still no where near the capabilities and safety of non-web languages. But I don't disagree that it's possible to write very high quality JavaScript code -- it's just a little bit painful.

It's certainly a little bit painful, but that's only because these things are brand new. These tools let you create applications most comparable to native apps, and could you imagine developing for iOS or Android without a Xcode or Android Studio? The current trajectory is very, very good, and it's with a bunch of tools and ideas that came from the community.

[deleted]

Re: PHP 7 deployment at Dailymotion

#127

Post by TazeTSchnitzel »

mgkimsal wrote: post #32
geerlingguy wrote: post #8

Earlier quoted context omitted.

For a lot of array-heavy applications (where you store all kinds of data in giant multi-level PHP arrays), the memory usage alone counts for most of the speedup; instead of wading through tens or hundreds of MB of array structures, PHP 7 trimmed things down by a factor of 2 or more. There are a lot of PHP apps/CMSes/etc that gained 30-50% speedups due to just that improvement. Other more optimized apps/scripts saw a…

IIRC, a PHP array entry had 127 bytes of overhead. PHP 7, that went down to 42(?). Also, IIRC, for JVM, it's .. 37? 40? PHP7 got array overhead down a lot, and I do believe that's where a lot of speed improvement came from (though certainly not all of it).

This talk's slides have a good summary of how much overhead was reduced: http://www.slideshare.net/nikita_ppv/php-7-what-changed-inte...

Re: PHP 7 deployment at Dailymotion

#128

Post by st3v3r »

corobo wrote: post #115
babyrainbow wrote: post #93

Earlier quoted context omitted.

>You have a point though. I used this internet thing about 17 years ago, it was terrible. Only dial-up. SLOW! And don't talk to me about browsers. Netscape? Internet Explorer? Ugh. Forget it. I don't care what they might have changed, or replaced or completely removed, its always terrible. We have only one Internet. But we have a lot of alternatives for Php to choose from. If you have an Internet provider that gave y…

After 12 years? I wouldn't consider them to be the exact same as when I left them at least.

But what is the reason why I would look back at PHP, when there have been better alternatives available for quite a while now?

Re: PHP 7 deployment at Dailymotion

#129

Post by corobo »

st3v3r wrote: post #128
corobo wrote: post #115

Earlier quoted context omitted.

After 12 years? I wouldn't consider them to be the exact same as when I left them at least.

But what is the reason why I would look back at PHP, when there have been better alternatives available for quite a while now?

I'll be honest I don't really care what languages people use, not my place to convince you back. Just saying there's quite high chances PHP has changed at least a tiny bit over the past 12 years

Re: PHP 7 deployment at Dailymotion

#130

Post by wwweston »

Aaargh20318 wrote: post #124
Akujin wrote: post #38

Earlier quoted context omitted.

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

> There's absolutely NOTHING wrong with having $_POST['whatever'] inside a controller as long as you're doing proper checks. The last part is why this is a problem. The truth is that programming is simply too difficult a task for human beings. Software is so complicated with so many moving parts that it is impossible for anyone to understand all the details of even the simplest piece of code. This is why we have oper…

> The last part is why this is a problem.

$_POST isn't the problem. The scope of the variable isn't the problem. You've realized this, too, and that's why you're shifting the argument to one about typing instead of superglobals-are-bad (typing and scope are obviously independent features).

> You want to reduce the number of things you have to think about to the absolute minimum

The net effect of type systems seems to actually be to force you to think about a larger number of things very very carefully. The only thing that ends up being reduced is having to think about having to think about them.

Post reply on HN