Live data from Hacker News

PHP 8 to Add a JIT

blog.krakjoe.ninja

81–90 of 190 posts

Re: PHP 8 to Add a JIT

#81
post #23

I am pretty impressed with the path PHP has been taking lately. They have moved the language from being a mess into aggressively incorporating modern features at a very rapid pace. Especially PHP7 is a really nice language.

I think the problem with PHP is that it's a mature language that is aggressively incorporating modern features, yet still is a mess.

Re: PHP 8 to Add a JIT

#82
post #67
post #3

Earlier quoted context omitted.

PHP also didn't make the mistake Perl did. A shame because Perl tried very hard to make the right thing easy with security.

What's that mistake?

Perl 6. You think Python 3 was bad?

Re: PHP 8 to Add a JIT

#84
post #23

I am pretty impressed with the path PHP has been taking lately. They have moved the language from being a mess into aggressively incorporating modern features at a very rapid pace. Especially PHP7 is a really nice language.

I think the problem with PHP is that it's a mature language that is aggressively incorporating modern features, yet still is a mess .

It's definitely not my language of choice but I commend them for making good progress from a bad starting point.

Re: PHP 8 to Add a JIT

#85
post #25

Earlier quoted context omitted.

"it almost had a "first mover" advantage in that it happened to be installed alongside CGI-BIN on shared webhosts way back in the way" That's a good observation. Because the mod_php and mod_perl Apache modules were much faster and lighter weight than CGI-BIN, and pre-installed on shared hosting, both PHP and Perl dominated the early web days.

When / where was mod_perl ever widespread? Perl was usually provided via CGI, and php was mostly deployed with mod_php back in the day which gave it a great speed advantage, often at the price of security.

[deleted]

Re: PHP 8 to Add a JIT

#86
post #47

Earlier quoted context omitted.

Rails was popular among those that never saw such approaches before, like on AOLServer and Zope. I just kept using Java, .NET and C++, while enjoying their performance, IDE tooling, and whatever ideas they could bring into their web stacks. Nowadays most cool companies that were pushing Ruby, are on JVM languages.

I think your view is skewed and doesn't reflect what actually happened in the mid-00s.

Skewed from European enterprises point of view.

I only got to know one start-up doing Ruby (not Rails), which happened to rewrite our Perl deployment scripts as a project subcontractor, as they didn't had anyone with Perl knowledge.

Re: PHP 8 to Add a JIT

#87

Earlier quoted context omitted.

Isn't reflection slow as hell? If not please correct me.

It's less fast than direct lookups, but if the compiler supports it properly, it shouldn't be any slower than a associative array lookup. echo $FOO[$BAR]; echo $$BAZ; >>> push FOO.ptr push BAR.ptr call hash_get push ax call print push local_table // static per compiled scope push BAZ.ptr call hash_get push [ax+24] // entry->value call print You'd probably want to add error handling (to both cases) and accessing a glo…

And of course a smart JIT compiler can even put the variable access lookup in an inline cache on the function so that in the future it's a direct type + key = offset calculation rather than a memory lookup and the hash_get call is avoided.

Re: PHP 8 to Add a JIT

#88
post #10
post #2

There is something to be said about PHP's staying power. The early versions of the language weren't considered "right". Except maybe they were right for the problem at hand. The way I see it was PHP captured the vector of change , and left ample room for future developments. Both internal changes (hello, bytecode; hello, JIT), language level features (hi there, namespaces), and runtime level features (oh hai, countle…

I think PHP had a couple of obvious advantages - it almost had a "first mover" advantage in that it happened to be installed alongside CGI-BIN on shared webhosts way back in the way - plus Drupal and WordPress being PHP projects. But to me, one of the most significant advantages PHP has is that its documentation is terrific . PHP.net is simple, clear about parameters and return values (as clear as PHP lets it be anyw…

I learned to program through php and the documentation was a major part of that before the prevalence of stack overflow etc

Re: PHP 8 to Add a JIT

#89
post #24

Article appears to be from the same person that maintains apcu, a very popular user space kv memory cache for PHP. https://github.com/krakjoe/apcu

Joe Watkins is a really nice person and contributed a lot to php including the thread support (php-pthreads) the debugger (php-dbg) and other really impressive stuff.

The nice story here is when he was in financial trouble (because of a bad employer) the community stepped up and donated to him ( https://www.gofundme.com/b9dfcg ).

He has constantly been useful and a positive force of change and any language ecosystem would be happy to have him.

Re: PHP 8 to Add a JIT

#90
post #22

Earlier quoted context omitted.

Things may have changed since v7 but historically I’ve not found PHPs documentation any better than any other language. In fact I remember a few occasions where I’ve ended up going by the advice of the comments rather than the documentation itself because the documentation was either out dated or just plain wrong.

Perhaps not better, but there certainly have been worse. As for the comments. Yes. But at least they're there, and quite often helpful. Plenty of times I've read other docs where I wished they had commenting but alas didn't.

The comments are only needed because the documentation is often wrong or confused. And, of course, usually most of the comments are wrong too.

Other languages don't need comments because they at least aim to have documentation that's correct.

Post reply on HN