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.
PHP 8 to Add a JIT
81–90 of 190 posts
Re: PHP 8 to Add a JIT
#82Re: PHP 8 to Add a JIT
#83Re: PHP 8 to Add a JIT
#84I 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
#85Earlier 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.
Re: PHP 8 to Add a JIT
#86Earlier 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.
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
#87Earlier 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…
Re: PHP 8 to Add a JIT
#88There 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…
Re: PHP 8 to Add a JIT
#89Article 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
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
#90Earlier 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.
Other languages don't need comments because they at least aim to have documentation that's correct.