111–120 of 190 posts
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…
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…
Earlier quoted context omitted.
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…
You can't just wave away the impact of having eval though. Just the fact that it exists means you need to keep around some supporting state like variable names. You can't do full constant folding and eliminate all intermediate steps for example if there a chance a runtime-created code will reach into your frame and want them back.
Earlier quoted context omitted.
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.
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.
Maybe this is true, but by virtue of its popularity and ease of use, PHP has one of the largest selections of tutorials on everything , so that it’s possible to write code by just copy-pasting example snippets.
Really the kind of stuff that is well documented in PHP is the kind of stuff that is well documented in most general purpose languages. They are also the kind of problems that aren’t particularly hard to solve anyway.
But this is a moot point because the reason documentation was discussed was because it was credited as being one of the reasons for PHPs popularity. However tutorials wouldn’t exist if a language wasn’t already popular so your comment doesn’t reinforce the point made by the GP.
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.
That has not been my experience but anyway there's a "Report a Bug" link on every doc page.
I don’t really recall earlier versions of PHP being any better either. So I really don’t think PHP became popular because of the docs.
The other comments about how it was easy to learn and easy to deploy is far more accurate. If I recall correctly, back when PHP gained traction, your main options then were Perl (which understandably confused the hell out of a lot of people), ASP (VBScript / JSScipt and requires Windows NT + IIS so not a popular option) or JSP (Java and at that time was pain to deploy. So not something you’d expect a casual web developer to bother with). So PHP is like BASIC or Raspberry Pi of the 90s web. It was made for one specific job, it didn’t do it perfectly, but it was cheap, easy to learn and just about good enough to get the job done.
My feelings about PHP are stuck in what I remember from 2004. If I’m starting a new backend web project in 2019, should I be considering PHP over Ruby, Python, or TypeScript? Why or why not? I’m curious to hear from anyone who’s used it professionally in the last couple years.
you'll "figure it out later"? anything else that floats your boat
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…
Can u give an example or link to a relevant article. Context: my area is more of high-level program (e.g. shape) analysis
But who knows? I wouldn't have thought it would be as popular as it is now, if you'd asked me 5 years ago.
Earlier quoted context omitted.
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.