91–100 of 190 posts
> However, this in fact opens the door on things such as machine learning, 3d rendering, 2d (gui) rendering, and data analysis, to name just a few.
Shouldn't we get decent threading built in before we consider most of those? I've hit that wall many times when processing larger amounts of data w/ php scripts. I know about the pthreads plugin but nothing beats a first class citizen like goroutines for go or similar.
Earlier quoted context omitted.
I haven't found PHP documentation to be better or worse than the documentation of other languages I've used. What I dislike about it is the comments that every page includes. Most of them are very poorly written snippets of code from 15 years ago. If you dislike those comments too, consider adding this to your ad blocker: php.net###usernotes
I've actually found many of the comments rather useful over the years, and although I'm not crazy on how old and random they often are, I find them at least worth a quick look.
There is the issue of bad advice, but recently I've noticed that there seems to have been a voting system introduced at some point (not sure how long that's been there, I was away from PHP for a good chunk of the last decade), and I think the moderation system is older, so in theory, some of the worst advice should be filtered down/out and some of the best should be filtered up.
Earlier quoted context omitted.
and now you see why "serverless" is misleading. "serverless" now means you don't run your own web server, you use someone else's.
That's not what serverless means. It means that your code isn't running on a specific server, and between requests it isn't in any kind of running state whatsoever. It's effectively in cold storage until it's needed, then it's pushed to a frontend/edge server and run. Serverless doesn't mean that there's no servers anywhere, but rather that you don't have a webserver or set of webservers that your code is on; it goes…
Earlier quoted context omitted.
and now you see why "serverless" is misleading. "serverless" now means you don't run your own web server, you use someone else's.
That's not what serverless means. It means that your code isn't running on a specific server, and between requests it isn't in any kind of running state whatsoever. It's effectively in cold storage until it's needed, then it's pushed to a frontend/edge server and run. Serverless doesn't mean that there's no servers anywhere, but rather that you don't have a webserver or set of webservers that your code is on; it goes…
This is the RFC with more technical details https://wiki.php.net/rfc/jit . I believe their plan is to emit low-level code directly via DynAsm, without their own intermediate representation. This kind of approach has been tried again and again and again and every project doing this either not got the results they wanted and given up or has had to go back and add a proper intermediate representation. Examples include R…
I respect that the PHP maintainers recognize that it is not enough to accept a working JIT implementation - they have to understand and maintain it. Speed is one thing, but long term maintenance is more important. > use DynAsm (developed for LuaJIT project) for generation of native code But at the very least, this exercise will ensure that DynAsm will be actively used by a few people. So even if this PHP JIT effort f…
Earlier quoted context omitted.
Not sure if this qualifies as intermediate representation in the LLVM sense, but PHP has opcodes already, it is not fully interpreted anymore (like it was in PHP 3). These opcodes are used for optimizations and cached for the lifetime of the PHP process (across multiple requests).
That's probably too low-level. Usually an AST is needed that is void of all syntactic sugar, yet can express the required data flows and dependencies so the trivial substitutions/replacements/caching and refactorings can be done at this level. Lower level bytecode lacks these higher level references (it usually has a lot of indices that index into raw lookup tables, but no real symbols that refer to results of comput…
Can you point me to some paper/reference about this? AFAIK it doesn't matter whether you have an AST or bytecode. Optimizations are done on an IR anyways.
Earlier quoted context omitted.
Well, you can do $moo = "hello"; $zork = "moo"; echo $$zork; // hello It doesn't get much more dynamic than that.
It can. Python, for example, builds up classes at runtime. PHP builds up classes at compile time. There are plenty of other examples. PHP is really dynamic through eval() but that's more rare. Although PHP does support the above syntax, it's actually pretty rare in production code. PHP can be optimized like JavaScript is: perform direct variable/member access but provide a slow path for these kinds of dynamic lookups…
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…
Part of its staying power is also due to Wordpress. If you're looking for an off the shelf CMS you'll almost certainly be considering Wordpress, Drupal, Joomla, et al.
Earlier quoted context omitted.
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…
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.