Live data from Hacker News

PHP 8 to Add a JIT

blog.krakjoe.ninja

171–180 of 190 posts

Re: PHP 8 to Add a JIT

#171
post #167
post #90

Earlier quoted context omitted.

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.

"Often wrong"? Really? By often, 50% more wrong than right or less? Or more? I can count on one hand the number of occasions I've found the documentation to be incorrect.

"Often" is a fuzzy term and it's used subjectively here. It doesn't mean "most of the documentation" (which would be the >50% goal post you're driving at). It simply means "a lot of the time $OP checks the docs". It might be the case that the only time they need to check the docs is for some of the more advanced features of PHP where errors are more likely to be found in the docs. While you could correctly argue "selection bias", it doesn't still take away from the OPs perspective that it often happens to him.

Re: PHP 8 to Add a JIT

#172
post #120
post #90

Earlier quoted context omitted.

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.

If you find the documentation wrong or confused please let us know. https://bugs.php.net/ We do our best. I was granted access some ten years ago and whenever I find a confusing page I fix it. I know there has been terrible pieces before but for the last oh five or six years I don't really find anything too bad. Please let us know what you found wrong. Thanks!

I was mostly responding to the idea in an ancestor comment that PHP has unusually good documentation (better than that of other languages), "best of all" having comments.

I'm sure the PHP documentation is getting better all the time! Other languages also have good documentation, though. And as pushpop said in an earlier comment, the reason that the comments were useful historically is that the documentation was not always correct or complete. (Perhaps in part because the the language used to have a lot more unintended quirks?)

Re: PHP 8 to Add a JIT

#173
post #82
post #67

Earlier quoted context omitted.

What's that mistake?

Perl 6. You think Python 3 was bad?

Ah, of course. But IIRC Perl usage on the web already started to decline (mainly in favor of PHP) before the whole Perl 6 debacle.

I think PHP's strength was also its weakness: an amalgamation of specialized functions thrown into a global namespace without having to bother with modules, CPAN or anything.

If you're an experienced dev it looks like a huge mess but if you're a complete beginner it makes it easier to work with.

Re: PHP 8 to Add a JIT

#174
post #163
post #102

Earlier quoted context omitted.

PHP was not really designed , though. It grew accidentally from a templating system. When other systems are said to be more secure, I think it's meant in the sense of not being horrifically broken and routinely injecting untrusted input into namespaces, markup and SQL queries.

Just like C grew accidentenly from a language created to bootstrap compilers and JavaScript was a hacky 10 day solution.

Wikipedia quotes[1] Rasmus Lerdorf as saying: "I don't know how to stop it, there was never any intent to write a programming language [...] I have absolutely no idea how to write a programming language, I just kept adding the next logical step on the way."

Another relevant quote: "I'm not a real programmer. I throw together things until it works then I move on. The real programmers will say 'Yeah it works but you're leaking memory everywhere. Perhaps we should fix that.' I’ll just restart Apache every 10 requests."

And: "For all the folks getting excited about my quotes. Here is another - Yes, I am a terrible coder, but I am probably still better than you :) "

...which is probably true, but all the more reason to use tools that work properly rather than encouraging me to build more poorly thought-out stuff on top of a broken hack.

[1] https://en.wikipedia.org/wiki/PHP#cite_ref-itconversations_1...

[2] https://en.wikiquote.org/wiki/Rasmus_Lerdorf

Re: PHP 8 to Add a JIT

#175
post #13
post #11

Earlier quoted context omitted.

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.

I could be wrong, but I think the ubiquity of those frameworks/CMSes is rather due to the language's success rather than vice versa. Web hosts made the near universal decision to support PHP as a dynamic language at some point, and the frameworks that were built in PHP then thrived on that. Wordpress wasn't that popular back when I started out with PHP, but PHP was already universally supported by web hosts (hence my…

I could be wrong but my recollection was that PHP initially became the only way to do dynamic pages on shared hosts since it had "safe_mode". At least at my first host, if you wanted to use cgi-bin, you had to submit it to their admin who would read the code and vet it for safety before installing it. While safe_mode probably didn't actually solve that many problems it was a good enough excuse that it meant that admins could allow arbitrary PHP without too much worry.

Re: PHP 8 to Add a JIT

#176

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.

PHP is faster than both Ruby [1] and Python [2] and unlike TypeScript the executed code is the same as the written code, no transpiling. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Like the author of the article said, most websites are I/O bound tasks. This is a CPU bound benchmark.

Re: PHP 8 to Add a JIT

#177
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 .

What are the messy bits? I know they are there but how is it a mess in your opinion?

There seems to be a lot of "PHP is a mess/garabage/whatever else" hyperbole in this thread with no actual explanations why.

Re: PHP 8 to Add a JIT

#178
post #123

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.

For majority of backend web project, in 2019, there should be nearly no technical advantage re: one language over another among all the popular ones. (i.e. the ones you listed: PHP, Ruby, Python. I would argue to use pure nodejs over Typescript though. Most people underestimate the dev flow speed it gives you to not to have a compile/transpile step. Refresh and rerun is part of what made PHP so popular years ago.) In…

I find that the cost of TypeScript's compiler more than pays for itself with all the other benefits it offers. It's to the point that I can't imagine working in JavaScript without it and I'm less happy working in other dynamic languages when I'm forced to. Refresh and rerun is great when you're developing but offers you nothing when you come back to the code weeks or months later. A good type system has your back even after you've forgotten how everything fits together.

Re: PHP 8 to Add a JIT

#179

Earlier quoted context omitted.

PHP is faster than both Ruby [1] and Python [2] and unlike TypeScript the executed code is the same as the written code, no transpiling. [1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [2] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Like the author of the article said, most websites are I/O bound tasks. This is a CPU bound benchmark.

Like the author of the article also said:

"To improve the ability to execute math faster in PHP seems, at a glance, to be a very narrow scope.

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."

Re: PHP 8 to Add a JIT

#180
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…

the very first first mover advantage was that php was the free alternative to asp, jsp, and coldfusion. all of these languages were built around the simple premise that web devs wanted to inject code into html, which is the way beginners tended to think about coding.

asp locked you into microsoft, jsp was laden with heavy/expensive java app servers and semantics, and coldfusion was a paid product (and eventually locked you into macromedia/adobe).

i think that if coldfusion had the same free+paid model as php, it would have taken the place of php in web history. despite its faults (maintenance and performance, for example), it was easier and faster to learn and matched the mental model of beginners, just like html itself.

Post reply on HN