Live data from Hacker News

PHP 8: Before and After

stitcher.io

261–270 of 346 posts

Re: PHP 8: Before and After

#261
post #159

Earlier quoted context omitted.

I converted about two dozens Ruby and Python apps to PHP in the last 7-8 years.

This single sentence horrified me more than the whole terrorist attacks over the last 26 years (before that, there was no PHP).

Come on guys, let's keep the discussion polite and constructive :)

Re: PHP 8: Before and After

#263

Please remember that PHP is more or less the only truly free (as freedom) community driven language suitable for both prototyping/pet projects and enterprise grade web software development. TypeScript and C# are Microsoft, Go is Google, Java is Oracle. Python is not suitable for complex multi-layered systems, Rust is too young and let's see where it will go without Mozilla. Ruby? IMO Ruby is in sunset phase, no new a…

Ruby is a fantastically good language with a slow bloated runtime. That killed Ruby.

Python was less good and less bloated, but still bloated.

I think we use Python now only because our computers are orders of magnitude more powerful than a decade ago when I was watching Python Zope slow to a crawl and die.

Re: PHP 8: Before and After

#264

Please remember that PHP is more or less the only truly free (as freedom) community driven language suitable for both prototyping/pet projects and enterprise grade web software development. TypeScript and C# are Microsoft, Go is Google, Java is Oracle. Python is not suitable for complex multi-layered systems, Rust is too young and let's see where it will go without Mozilla. Ruby? IMO Ruby is in sunset phase, no new a…

> no new ambitious projects are started with Ruby

What does this even mean, only lazy ass projects are started with Ruby? Yes Ruby is declining in popularity, as does PHP. It doesn't mean these languages are dying, there's just way more options to choose from these days.

Re: PHP 8: Before and After

#265

Earlier quoted context omitted.

> list of problems with PHP (Here we go again.) Such us?

Are you productive in any of the following? C#, Ruby, Rust, Elixir, Typescript (or even Haskell) If not, you're just proving my original point. It's hard to see the problems of a language if you are only productive in that language. I can start pointing out flaws in PHP, and you can claim that those flaws don't matter. Until you increase the number of languages in your repertoire, our discussion about the flaws of PH…

I dislike the patronising tone of your comment. If your first assumption is that the interlocutor is monolingual, that makes me think you are used to a quite unsophisticated company.

> I can start pointing out flaws in PHP, and you can claim that those flaws don't matter.

It is context-dependent. For some jobs it is a poor choice, for others - including most of web application back-end development - pretty much none of its so-called flaws actually matter.

Re: PHP 8: Before and After

#266
post #230

One of the underappreciated pros of php for web development is its execution model, it's fault tolerant by default and shares little memory across requests. This kind of makes sloppy programming far more tolerable in php than in other platforms. In effect this has an impact on performance but it also helps in ensuring that a bad request can't blow out the whole application from serving other requests like is common i…

This model is also exceptionally successful in Java Servlet, C# Razor Page, and elixir. And perl CGI. It's possibly more common than not!

Re: PHP 8: Before and After

#267
post #230

One of the underappreciated pros of php for web development is its execution model, it's fault tolerant by default and shares little memory across requests. This kind of makes sloppy programming far more tolerable in php than in other platforms. In effect this has an impact on performance but it also helps in ensuring that a bad request can't blow out the whole application from serving other requests like is common i…

PHP apps following modern best practices usually include stateful middleware of some kind though, so this applies in theory more than in practice.

If you mean persistent databases or caching like Redis, it's still much easier to accidentally reference a global pointer due to a programming error than accidentally put something in a cache store. All systems need some sort of persistence, this is true for other languages as well.

Re: PHP 8: Before and After

#268

Few months ago I was debating with a friend working since 15 years on PHP, my point was php is slow and max throughput is 200-500 rps, which is quite low compared to Go, node.js, C# and others, he answered that 100-200 request per second is more than enough for most use cases. I'm working on systems with 25K RPS at peaks, but for simple projects and small companies he is right ... But why should anyone start a new pr…

This is correct only if you run "Hello World" apps on a single server. PHP scales horizontally so any real-world application can easily scale to 10, 100 or 1000 servers. If there is no other scaling challenges (like databases) then it can scale forever thanks to its beneficial process model.

Re: PHP 8: Before and After

#269
post #7

Earlier quoted context omitted.

Very soon: "A long-standing goal of the WordPress project is to be compatible with new versions of PHP on their release day. The next major version of PHP (version 8.0) is currently scheduled for release on November 26, 2020. WordPress Core contributors are working to ensure PHP 8.0 is supported in the next major version of WordPress (version 5.6), which is currently scheduled to be released on December 8, 2020." htt…

Possibly not what the author meant. Support for PHP 8 in WordPress will come soon after PHP 8 is released. But to upgrade WordPress to PHP 8, that is to rewrite its codebase to make use of PHP 8 features, probably will not happen anytime soon. WordPress still has a minimum PHP version requirement of 5.6, so...

The latest trunk version of WordPress already works with PHP 8!

Re: PHP 8: Before and After

#270

Can a fellow geek knowledgeable in PHP gives me a few pointers? I have inherited a 12 year old PHP app written by 2 interns. The code was written with Notepad++ (no IDE), no comments except when they copy pasted something from the internet, most variables are single letter and it's the biggest spaghetti bowl I have ever seen. To add insult to injury I have no experience with PHP (apart from peeking at this code to fi…

I maintain half a dozen PHP apps written for PHP 4-5, all of which now run on at least PHP 5.6, and a few of which I've gotten to PHP 7. Advice given by everyone else is excellent. PHPStorm is a must for me, one of the only pieces of software I pay for instead of using some OSS alternative.

One thing on automated tools: getting a good result is decently tied in to the structure of your project in my experience. A common scenario I've seen is projects relying on requiring other files as part of their business logic (IE, parent file A includes file B that processes and renders content vs file B including file A that defines helpers and what not). This is especially common when projects use something like index.php?file=whatever for URLs. Most automated tools and IDEs will struggle with this and false-flag undefined variables, etc, because there is no hard include path. There are a lot of ways to resolve this but it depends on your project.

Also, PHP 7 is much more aggressive about warnings on types and various other things. Unless you adjust your error reporting settings, you'll likely see a ton of these when you finally switch. I personally enable them on dev so I can clean them up, and keep them reporting to Rollbar on production.

Post reply on HN