Live data from Hacker News

PHP 8: Before and After

stitcher.io

231–240 of 346 posts

Re: PHP 8: Before and After

#231

Earlier quoted context omitted.

Roughly in the order you should do it. Hopefully it's at least PHP 5.3 code: 1. Definitely get a PHP IDE: https://www.jetbrains.com/phpstorm/ 2. Get a step debugger and hook it in: https://xdebug.org/ 3. Fix the code style: https://github.com/FriendsOfPHP/PHP-CS-Fixer 4. Run the code through some static analysis tools https://phpstan.org/ https://psalm.dev/ 5. Upgrade the code with an AST fixer (might help you update…

All good advice for the average PHP developer, but I think it is overkill for someone that is starting with PHP just to keep alive a very old app. Adding tests for an app with no documentation requires a lot of effort.

> Adding tests for an app with no documentation requires a lot of effort.

code tests yes. Assuming it's a web app, probably not too hard. Get something that records the browser interactions, and do the common tasks people do (log in, click links, make a report, etc). Having general things like that automated to ensure you can run them repeatedly to make sure basic stuff didn't break unexpectedly will help provide some confidence when making changes.

Re: PHP 8: Before and After

#232
post #26

Earlier quoted context omitted.

This is such a shallow elitist comment. A lot of the common criticisms levied at PHP have been corrected years ago, and PHP is responsible for hundreds of billions of dollars of turnover globally. Of the top 10 websites in the world, PHP is partially or wholly powering more than half of them. Wikipedia, Wordpress, online retail. I have personally created 6 figures of value because I could quickly dump some PHP script…

How can you call this elitism? Nobody forces you to learn PHP, you can learn any of the many other open source existing languages. There's no gatekeeping preventing you from learning languages other than PHP. I'm just calling it for what it is: a broken tool. I'm suggesting we let go of this broken tool and focus on tools that already work great, instead of wasting millions of human work hours on sub-par coding. Sure…

I've seen companies decimated by refactors to new shiny technology. Security, scalability and ease-of-use is practically solved in PHP.

PHP is inherently stateless, making it easy to scale up. Facebook has had pretty close to a 100% availability rate since launch and PHP is still responsible for large swathes of their functionality.

Most people attacking PHP read a snarky article written in 2012 about PHP's limitations and cannot actually provide reasoning for why it's so awful.

Wikipedia, huge portions of online retail, forums and Facebook. Are these things inherently less secure or available than companies with a "modern" stack? Not really, in fact pretty much the opposite.

I'll let you in on a little secret: your customers could not care less about your shiny modern stack. As long as it's not preventing performance, security and new development then they don't care.

My PHP endpoints respond in <100ms, which to my customers is perceptionally instantaneous. They wouldn't benefit from any shiny modern language at all (but I do use them).

Re: PHP 8: Before and After

#233

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…

Dev. here, using PHP for 20 years. Short story: I'm working on a system that peaks at 200k rps. Using PHP with Swoole.

Re: PHP 8: Before and After

#234
post #163
post #125

Earlier quoted context omitted.

This is because you‘ve built up expertise and know the ins and outs of the language and frameworks (which are often very complex and idiosyncratic to achieve their cleanliness and expressivity). You know what to use, how to use it, what to avoid, how to debug stuff etc. However for people who have not invested this time and effort it is an objectively worse language than other web focused ones in many dimensions. PHP…

The fact that it is worse doesn’t make it bad. I’d take Typescript over PHP any day, but not Javascript.

> The fact that it is worse doesn’t make it bad.

That's correct. It turns out that it's also bad, though. People don't like to hear it because I'm "just a hater", and maybe one or two of these issues isn't a deal breaker. And yes, you can write real, useful, applications in PHP, but it's a terribly awkward language with a lot of missing features and sloppy dynamic typing nonsense.

* No (real) async or threads (pthreads never worked on backend and is deprecated anyway for those who always mention it in response to me)

* No generics

* Interfaces must be complied to at class definition (leading to verbose nonsense like the "adapter pattern")

* No const or immutability

* `array` is a shitty hybrid of an actual array and a dictionary and it sucks at both

* No other native data structures beside the shitty `array` mentioned above

* No ability to typehint callable function params

* switch statements use loose equality checks, so you should avoid them

* foreach is broken and leaves a dangling reference

* `array` keys are automatically cast to int if they can be, which is broken and insane. (E.g., if I use `array` as a dictionary and one of the keys is the string "123", it will NOT store the entry as key-value pair: "123" -> $data. It will instead store $data in the 123rd slot of the "array". Iterating this `array` with an index will end in a bad way).

But surely someone will drive by and say that none of these things matter and that an experience PHP dev would never be bothered by any of these things, etc, etc. "You can write bad code in any language."

But... you can always just choose a better language if you have the choice. I feel like people get Stockholm syndrome over their tech choices. It all sucks, but some suck worse than others. Don't tie your identity to shitty stuff like programming languages: "I'm a PHP dev." "I'm a Rust dev." Give me a break.

Re: PHP 8: Before and After

#235

PHP is a perfect language for webdev and automation: much faster and lightweight than python, good package ecosystem. I do all my process automation tasks in PHP and it's been such a pleasure.

It's situations like that where I'd like a way to write

   
And dump some python code the same what you'd do php and have my web server serve it up. It would be handy, but I'm sure the uses cases are limited.

Re: PHP 8: Before and After

#236

Earlier quoted context omitted.

"he answered that 100-200 request per second is more than enough for most use cases" Exactly this. If you already know PHP and can produce results (mostly CRUD apps) and it doesn't need millions of rps, why do we need to use another language because they are so much better ? So much better at what ? It is like saying "I have a hammer, so everything looks like a nail to me". Not every web app has to be written in Lua/…

I am wondering this: are people who do crud apps (in php or otherwise) do consider race-conditions in the database? Like one query and then based on that query another one which inserts/updates? And if so, where can I read about the standard techniques used in practice?

https://blog.coeo.com/a-cheat-sheet-for-isolation-levels-in-... The standard technique is deciding which isolation level you want to use for your queries.

Re: PHP 8: Before and After

#237

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…

Given the 0 budget etc. you could perhaps as a compromise migrate to a recent VM but with an old PHP? (eg like https://www.howtoforge.com/tutorial/install-apache-with-php-...)

Re: PHP 8: Before and After

#238
post #235

PHP is a perfect language for webdev and automation: much faster and lightweight than python, good package ecosystem. I do all my process automation tasks in PHP and it's been such a pleasure.

It's situations like that where I'd like a way to write And dump some python code the same what you'd do php and have my web server serve it up. It would be handy, but I'm sure the uses cases are limited.

This style of embedding was popular at one point in Python's evolution before Django appeared. You can probably find 10 such systems in this list: https://wiki.python.org/moin/WebFrameworks#Discontinued.2FIn...

There are probably a few still around

Re: PHP 8: Before and After

#239

A lot of those changes look like good things taken from other languages that have done it well (the null ?-> and ??, ...). But many things seem to be quite of a burden instead of a progress => why create a new match syntax when a switch is already well known for something similar? That will create confusion (thinking of all the for types of loops in JS!), plus it's still not an enum and cases will be missed. And the…

> And the worst being the attribute #[] syntax... why?!

Hah. Since the initial RFC was agreed, I think there were three changes to the syntax because no-one could agree. At one point it was going to be `@@attribute`. #[] is similar to or the same as Rust, I believe. It also has the advantage of being backwards compatible; while rarely used, comments in PHP can start with # instead of //, so older versions of PHP will just see an attribute as a comment. Of course, that also means that a comment in old code might now be interpreted as an attribute, but there you go.

Single @ is probably a no go because @ is already the error suppressing operator. Now, in my opinion that should be ejected from the language with extreme prejudice, but I doubt it ever will be.

Re: PHP 8: Before and After

#240

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 think arguments against PHP could be make against many other languages, ie: Javascript or python. But they are not done as much and I think this indicates that people make those arguments in bad faith.

If we say once a better language comes along, we should say that the old language is shit and should die, then sure keep doing that. But looking at the languages that you have listed above, none of them are dynamically type I belive although not familiar with a couple of them. For some small projects people might prefer dynamic typing, or if you are prototyping something.

Also the amount of libraries, frameworks and projects already written PHP is massive so if someone wants to do something fast, why limit people's choices by trying to convince everyone that the language is shit instead of letting people decide for themselves? It just feels like a witch hunt to me.

Post reply on HN