PHP 8: Before and After | Hacker News Reader

PHP 8: Before and After

stitcher.io

314 pointsbrendt_gd335 comments

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 in platforms like nodejs where you need to be extra careful. Needless to say this makes php becomes quite viable for production envs, and prevents a whole host of issues that need expertise and careful programming to fix.

I'm thankful to have started programming in PHP when I first started doing web work for this reason. Shared mutable state is (almost always) bad and virtually everything I've built after that (on any stack) follows similar rules around per-request isolation because of the patterns PHP instilled in me.

Not only does this reduce (1) the likelihood of correctness issues, but it also dramatically reduces (2) deployment complexity because you don't need to migrate a bunch of in-memory state distributed across web backends. Your servers should all be considered dispensable.

In 2020, I tend to bias towards things like AWS lambda for this reason (for low volume applications). By default, there's no guarantee on the lifetime of the serving process and any unhandled exception recycles the process so you're never in an unknown (bad) state. There are of course performance downsides to this (particularly when it comes to pooling connections for things like Postgres), but once you figure that out things are generally smooth sailing.

What I miss about PHP is that it was possible to put a file in a folder and use it instantly.

If you want to quickly do something without diving into frameworks the tooling was easy to setup and rarely fell apart, if ever. There are not many moving parts, you usually have a web server that is very solid and comes with an installer that you hit next next next. Then you have a database server, usually MySQL. Sometimes you would need an extension to work with images, you put it in place by editing an .ini file.

Almost like an Excel for backend.

This is still possible, how do you think isn't anymore? As example I mean

Not OP but I read this as something they miss because they no longer work with PHP.

Exactly :) Last time I touch PHP I think it was 5, I don’t know what happened in between so when I say “was” I mean it was for me.

I see, my mistake!

> this has an impact on performance

And yet, I find that PHP apps tend to be quite performant, compared to say Java or Rails (I don't know about node, maybe not compared to node). But I'm not a PHP developer, this is just my impression. And the complaints you hear about PHP, I seldom hear performance. No?

It varies considerably. If you write the kind of simple PHP pages which gave it that reputation, it's almost always going to be limited by I/O. If you use a framework which encourages enterprise-style apps with hundreds of includes and object hierarchies which would make a J2EE developer weep, even the opcode cache won't be enough to get back to that spot. I don't follow it enough to see if this passing away niw but there was definitely a sizable chunk of the community which really thought that Real Programmers™ didn't write simple code.

i did a simple test between PHP, Java, Elixir and Haskell for fun (with a full payload/page that represents my problem domain) - PHP was within +/-10ms of the others for the same payload/template process. Guess which one was the slowest?

if you do something in a naive way, PHP performance can tank pretty severe - but that's more down to the developer implementation rather than a shortcoming of the language itself

I fully agree, but I think this is an issue in most languages (not counting compiler optimizations)

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

Servlet shares instance between request (or you can configure DI container, not so simple), Razor is just a template.

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.

No, I'm talking about the kind of thing that provides a `Context`-like object that allows the application developer to share memory between requests.

that's not really a thing you do in PHP, outside of frameworks like swoole/roadrunner. by nature it's a fire/execute/die shared-nothing model

Like others have mentioned, there is no such thing in PHP. Each request is handled individually from a blank slate and the context is destroyed when the request finishes.

Write to a database or file?

you mean $_SESSION? that was there since at least php4

And even that is limited to sharing data for a single user between requests. It's hard to accidentally share data between users.

the largest performance issue i've come across with the execution model is that connection pooling is...well, pretty crap. opcache handles most of the other interpreted woes rather well.

Are you talking about connection pooling to services like databases and caches? Most extensions implement it (pgsql and I think MySQL) but you need to configure it. I’ve also use a local nginx proxy to pool the connections.

It's becoming kind of an Enterprise language [1]. Don't get me wrong I think PHP is getting cooler, hopefully everybody catches up and the fact that You can have a shared hosting for pennies run Your PHP code really puts it at an advantage compared to others.

[1]: https://github.com/joaomilho/Enterprise

> It's becoming kind of an Enterprise language

It tried for decades to be one with Doctrine, Symonfy and co, trying to copy the worst of Java EE with every single possible design pattern implemented in these frameworks, XML configuration files and co... The problem is no generics, no private packages makes PHP OO a horrible mess compared to Java (or C#).

I agree with you. Symfony and composer in general has just turned our code base into some kind of fugly java like monstrosity.

When I used composer the first time I really enjoyed it, that project also used Silex a minimalistic symfony2, which I also really liked. But what I found out is that in general it is really terrible to be dependent on others, as Silex was dropped by Potencier and my project is left in limbo, sadly. Its very sad because its one of the coolest things I ever worked on, and its still in use today many years after. But I am worrying that some time in the feature, a vulnerability or problem with Silex comes up, the company will have to rewrite the project completely some day.

I worked alot with Drupal7, absolutely hated it mostly because the hook system was hard to remember and performance of Drupal7 in general was absolutely terrible. Then I tried Drupal8 and though some changes are welcome, some stuff are just so god damn complicated, a task that would have been as simple as a few lines of code becomes pages of boiler plate, EventSubscribers and YML config files.

PHP used to be a good choice because it was rapid application development on crack cocaine, developers were cheap and diverse in skill and background.

I still think there is SOME use for PHP, I personally like it for shell scripts mostly because im so familiar with it. I used it alot the past 10 years for making stuff fast for friends and personal use I guess its also a decent beginner language for web development, though javascript would be higher on my list today because of the obvious front end relation.

I have been bitten too by the abandoning of silex and symfony becoming more and more like a complex java beast. The zend framework 1 was once good with a simple abstraction but they turned java like too.

Nowadays i develop in laravel which is breeze to work with. A simple framework and you can choose whether to use it as simple as silex, full blown like symfony or somewhere between. I started using it like a silex with controller classes and migrated more and more to the symfony way, but still its really easy understandable for any new developer.

PHP is filled to the brim with bad frameworks with one size fits all type of mentality. Just avoid them and make your life easier.

If you need a framework, look for something small, small enough to read thru and understand in one hour.

Silex was ok but to be fair you can get almost the same thing with the Symfony micro-kernel trait.

Have you tried October CMS? It really gets back to the basics and is awesome for rapid application development. Disclaimer, I'm the lead maintainer

That's what baffles me with PHP. Instead of building on PHP's unique capabilities, they try to become more like Java. When PHP was and is quite successful as server-side language for HTML templating, rooted in embedded PHP triggered from SGMLish processing instructions in otherwise static HTML. It's only that they made such a hack job without context-dependent, HTML-aware escaping, making it a primary vector for injection attacks.

It was because every developer in the West was taught that inheritance based OOP was the one thing to rule them all.

And that unfortunate school of thought created the Java mythos that spread to many languages, not only PHP, eg JavaScript (everyone trying to write inheritance based OOP in a prototype based language).

Few years ago the mythos changed somewhat to every programming language should be functional.

Thus it is not a specific PHP problem, it is common problem of trend sensitivity in programming culture.

And the funny thing is that much of the critique against PHP, like in this thread, is in the form of "why isn’t PHP like the other programming languages?"

But agree PHP should go it’s own way, it has much to contribute to the world still and it feels like it has started to create its own path again.

> It was because every developer in the West was taught that inheritance based OOP was the one thing to rule them all. > > And that unfortunate school of thought created the Java mythos that spread to many languages, not only PHP, eg JavaScript (everyone trying to write inheritance based OOP in a prototype based language)

I don't think it's as simple as OOP being bad but rather the culture of complexity that everything had to have deep object hierarchies, layers of indirection and runtime configuration, etc. If you write Python, JavaScript, PHP, etc. classes which don't try to follow the enterprise Java style and only pay for the complexity needed by the problem domain the results are fine.

I think a large part of it was that many people learned not OOP but how the Java standard library and J2EE worked, and internalized the idea that you were trying to produce a reusable abstraction for the entire stack which could be used by unrelated projects without realizing how expensive that kind general framework development is.

Correct, OOP in itself it’s not bad. I use it every day, but I mostly use composition rather than inheritance.

What I was trying to say was that the inheritance based OOP was sold as the ultimate problem solver.

We all remember programming classes with Hello World like examples of Cat inherits from Animal.

Problem is of course that in the real world is never that simple so the inheritance based model turned out many times to be a mess because it was applied to problems where it didn’t fit.

That doesn’t mean that inheritance based OOP has its place, it does, but that is usually in very specific domains.

I totally agree. What I'd actually welcome these days is a web "glue language" which adheres to what PHP wanted to be in the beginning (easy HTML output, one file per page, easy database querying, easy CGI interfacing), but without any OOP bolted on (C-style procedural would be fine), without any of the horrible security decisions, and with strong typing.

It would make a nice counterpoint to all OOP-style web dev languages (Django, RoR, PHP8+framework + routing logic) and all frontend-focused frameworks (React, Vue). Super-simple, super old-fashioned, but rock-stable and easy to kickstart a small website or prototype, and great for teaching (nothing is easier than "drop a index.lang" file in this directory and you have a website).

Isn't this what PHP still is? Can't you just drop index.php into a directory?

Was going to ask the same thing.

There's not much in PHP 5/7/8 which precludes just doing some raw db queries and including some templates.

The biggest 'drawback' might be that there's not one name-branch 'framework' which takes this approach (indeed, it's the opposite of 'framework' thinking). But if there was some project that documented/demonstrated 'best practices' for 'non-framework' projects, it might help reduce the "I need a framework because raw PHP is so messy" objections.

It is, but also note my other points:

1 - security-safe and type-safe from the beginning 2 - none of the additional programming paradigms. PHP wants to be everything in one language. I know you can still use PHP "basics" like that, but it's not going to be easy to find tutorials etc. showing that

The main point I wanted to make was not about the index.php file. In other words, I'd like a PHP3, but a clean, safe, very well-designed one.

Probably because Java (and it’s structure) is what is taught in school.

It does surprise me to encounter over-complicated Java-style patterns in PHP.

It would be impossible to maintain backward compatibility if they made the language HTML context aware. It would make it more difficult to output any non-HTML content type from a PHP script. It would require many new syntaxes (e.g. for outputting variable data in the attribute values of elements, selectively outputting elements or attributes, looping through them, etc). It would also mean the language is tied to specific HTML versions and it would not be able to be forgiving of HTML syntax errors, defeating much of its ease of use.

I am not sure it would have been practical to turn PHP into a strongly HTML aware template language like Thymeleaf for example, while still having it be useful as a general purpose programming language. IMO, the dream of PHP/CFML/JSP/ASP mixing code with templates just isn't realistically possible.

Backward-compat and syntax doesn't have to be a problem. The `<?php ...>` processing instruction can stay as it is, only to be augmented with a new opt-in mechanism based on entity expansion (the fully context-aware templating mechanism built-in to SGML/XML). Eg roughly

    <title>bla</>
    <?php let x =
      "<p>whatever</p>"?>
    &x
    <div class="debug">
     <![ RCDATA [
       &x
     ]]>
    </div>

where x is bound to markup checked against permissible elements in the first context (eg rejecting <script>) and escaped into <p>whatever<p> in the second. Rejecting script elements in user or other dynamic content as well as escaping comes for free with regular SGML parsing.

There are many cases that doesn't solve, for example, how can I conditionally decide to either inject an attribute or not inject it using this technique? How do I mix user-controlled text which should be escaped with dynamically generated HTML in PHP strings that I don't want to be escaped? How will scope be managed and can those constants be redefined (not normally a concern in SGML)?

Plus, what makes you expect this opt-in syntax would catch on if people already don't care enough to use HTML-aware template engines?

EDIT: Also, what happens if the static parts of the document aren't syntactically correct SGML? How can you even know if the final output will be syntactically correct SGML until you run all the legacy parts of the PHP code that output directly in the document stream?

Symfony supports YAML files too since... almost forever.

actually in future versions symfony will move mostly to php based configs instead of yamk, xml. at least parts of internal configs which were xml now are rewritten to php

Which is a sad choice on it's own

Is it? Why is that?

First because you don't really have completion or templating over its content: you mostly do copy/pasting or guessing what you have to put in there.

Second because they are using all kind of tricks to add variables into it (ENV, ...): the configuration is often dynamic by nature or by re-use.

Third because it's only strings, which is prone to mistakes: they are having a huge lot of code to check those configurations.

It's a different culture. They go around the problems differently. Also the way the write programs seems simpler and leaner (composer in mind)... probably not ultra safe but a good enough ratio I guess.

> It's a different culture. They go around the problems differently. Also the way the write programs seems simpler and leaner (composer in mind)... probably not ultra safe but a good enough ratio I guess.

No it's not a different culture, they(enterprise Java and enterprise PHP) both try to force some IoC container everywhere, except PHP is an interpreted language, it doesn't need a IoC container with with XML/YAML configuration files cause there is no long and costly compilation step to begin with...

That's unrelated, you can tell very rapidly how nicer a tool like composer is from most java things of this era; this is entirely cultural IMO.. you can use xml or yaml in fine or absurd ways.

I’ve seen some self-balancing backed priority queues implementations, using some quirks of PHP, that are faster than the C implemented ones and faster than a “standard” implementation. Wall clock time, it’s still O(log n).

Lately I see myself abusing (???) types more often than ever. Before, I'd feel comfortable returning an array of structured data from a function. Now, I'm creating Value Objects to ensure my data is both valid and correctly used elsewhere. Kinda feels nice to get intellisense working too and knowing that the things that I'm trying to do with that VO are valid

> Before, I'd feel comfortable returning an array of structured data from a function. Now, I'm creating Value Objects to ensure my data is both valid and correctly used elsewhere.

Same. I've written some complicated ETL/data transform processes in PHP, and used arrays because the array_* functions are so useful for manipulation.

But keeping track of what keys were available was a nightmare - especially coming back to maintain the system.

Like you I've switched to Value Objects. In many ways it's a pain (the intermediate representation that I'd stick into a new array key and pass to the next transformation - it doesn't belong on any of the objects; and PHP needs the equivalent of the array_* functions for objects) but knowing I can't use the wrong key somewhere makes it worthwhile.

PHPStan and Psalm support what they call "array shapes", basically you can treat the array keys as a type, similar to how TypeScript does it.

But your IDE could understand your code for years with:

  /* @return MyObject */

Returning an array with unknown items has always been bad practice imho.

Your IDE but not the PHP Interpreter, that's the advantage of making a typed return.

that's why I like the "shape" type in Hack - the ease of returning an assoc array, but with field and type checks enforced.

PHP started to enterprise the moment they add PSRs IMO. It was no more a scripting language first. It was also at the clean OO push. Very Java like in a way.

I really like the idea of different types of comments for usage with external tools.

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

   <?python

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

If you are sufficiently motivated, you might look into Emac's "babel" scripts, which can run Python embedded in org-mode files. You could use mod_wsgi in Apache to set your .pml (Python Markup Language, I just made that up) files to be parsed.

I too use php for automation. It has a lot of "built ins" that are always there (reading csv files for example/ json reading), which I find makes things a little easier for a lot of simple things.

if i have to crunch numbers in a script I like R, or Python w/ Pandas

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 fix a minor bug here and there). To be fair the app works OK and has done the job for all those years.

This app has never been updated so it's PHP version 4 or 5 I think, it runs on an old Debian 5 VM, it's not facing internet, internal use only. It was supposed to be deprecated last year, but now given our budget (or lack thereof) and the sheer incompetence of our new provider I don't see it happening soon.

Is there a way for me to have an IDE with a kind of "compiler" that would help me convert this to PHP 8 so I can migrate it on a more recent VM? Of course there's 0 budget for this.

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 to newer PHP version): https://github.com/rectorphp/rector

6. Add tests to it: https://phpunit.de/

7. Run mutation tests: https://infection.github.io/

The "0 budget" is rough, though.

In addition:

- Make sure you have version control. So easy to do these days, so often forgotten.

- don't think that the steps above must be done in order, right now.

- dkarlovi mentions tests. Start with 1.) smoke tests like simple selenium tests or something like that. You'll find lots of vate towards it if you look and I admit it has issues but for simple projects like this that doesn't change much it should be fine. Of course of you find something better use that.

- one of the most important things about a good IDE is being able to refactor confidently so you can rename variables to something reasonable as you figure out what they really are.

- the book "refactoring legacy code" might be the best programming book I've read.

There's also "Modernizing Legacy Applications in PHP": https://leanpub.com/mlaphp (but leanpub seems to be down right now lol)

I tried searching for "refactoring legacy code" but I couldn't find it. Who's the author?

Sorry, I misremembered:

"Working Effectively with Legacy Code" is the name. The author is Michael C. Feathers I think.

There seems to be a new version coming out in the next couple of months (ISBN 9780136657125) but I can't tell if it's a new edition or just a redesign.

If you do #1, you'll get #3 and #4 for free, and full integration of #2 and #6 :-) Best 80 bucks you can ever spend if you write PHP.

My basic procedure when inheriting legacy code is:

- Load the project in phpstorm

- Perform autoformatting so it becomes readable

- Run code inspection to find any obvious issues the original author missed

- Write tests in phpstorm, if not already exists

- Run the code with xdebug, step through it

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.

Of course, that's why the list is sorted, he might never make it pass 1 :)

Yes. Upgrading really old php application (v4? really?) to v8 is such a big step it will need much dedication, so many things changed between 4 and 5 its not easy. And even upgrading 5 to 7 may break so many things. I would not like to switch with him.

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

Do you have a staging enviroment you can use?

As others said, vscode with php extensions works quite well (you do need a local php install for intellisense to work iirc?)

As for migrating. I wouldn't aim for 8, that's a hell of a jump to make from 4/5 and just getting to 7.x would give you a few years of breathing room https://www.php.net/supported-versions.php .

First goal, get it working on 5.6 without any deprecation errors or notices, that's a good basis for a "legacy" codebase to be on.

From there, the hop to 7.x is mostly changing any mysql_* calls, avoiding the short tags (use `<?php` instead of `<?' and a few other things found by looking at the migration notes here https://www.php.net/manual/en/migration70.php (other version notes available from the menu on that page).

As for tooling, Rector, phpstan and Psalm might be helpful, but might be more trouble than their worth if you've only dipped your toe into PHP development. Rector can do automated refactoring with some code (helpful for the mysql_* function removal/replacement with mysqli_* for instance). phpstan and psalm are static analysis tools that can help find problems or issues with the code.

Final comment, make sure this is in version control so you can track any changes made and have known working versions.

While not free, Paul M Jones book Modernizing Legacy Applications in PHP has really helped me get control of a large old codebase.

https://leanpub.com/mlaphp

It gives examples and goes bit by bit through the process of organizing code.

I'm using its suggestions along with a static checker called Phan, which I chose because it attempts to "prove incorrectness rather than correctness."

https://github.com/phan/phan

I've spent a lot of my career updating/fixing/replacing aging PHP apps, so here are some pointers:

0. Ignore PHP8 for now. There's much more community support for PHP7, so fix it up to work on PHP 7.4 first.

1. My first task is always to use a code scanner to test if the codebase is PHP7 compatible (or PHP 5.6, or the next version on from whatever you're running). See https://blog.fortrabbit.com/php-testing for an incomplete list (I've used others but haven't got my bookmarks to hand). You'll get false positives but also a good feel for whether there are serious issues.

2. You don't say if it's a CRUD app or an API. If it's the latter: set up a PHP 7.4 box (with a copy of the datastore) and route all traffic to the current production box and to the copy. Save the responses from both and compare they're the same. A simple way to see if the app will work on PHP, and when you find something that's broken, you can fix it, reset the logs, and try again. Hard(er) to do with CRUD, but I have compared the datastore contents before to check they're the same.

3. Needless to say, stick it all in source control if it's not already.

4. For your own sanity, run a code formatter over it if the code is messy.

5. I like PhpStorm as an IDE. It's not free, but the intellisense and refactoring support (and the built-in debugger) are timesavers.

6. Assuming it's not global variables everywhere, that they've used functions/classes(!), then as you fix bits of the code rename the single letter variables and add comments. PhpStorm can refactor variable names, so you see what will change before it happens.

7. If the code's using mysql_* functions, which aren't present in PHP7, there's a shim to make them work: https://github.com/dshafik/php7-mysql-shim

8. Good luck! I like unpicking codebases like this and keeping them running. As a sibling commenter has said, it's an internal system so assuming staff are not going to exploit any vulnerabilities or you have guarded against those already, there is no problem keeping it running internally as-is. So long as you can still recreate the VM from scratch (I have had old packages disappear - now that makes for an interensting disaster recovery plan) and reinstall everything you need should backups fail, you're okay.

re: #5 phpstorm

Correct, it's not free, but there is a 30 day trial. And... if you want to try it past that, it's $9/month on month-to-month pricing. For anyone working in "western" economies, it's near enough to free to at least give it a trial for a few months. The other 'big' competitors - vscode and probably... eclipse - both can provide value, but I've found the JetBrains stuff provide a much nicer out of the box experience for most PHP folks getting started out that that $89/year or $9/month to try is almost a no-brainer. But have also had people disagree, and almost always spend more than the $89 of their own time (or their company's time) getting VSCode set up with a collection of plugins.

Regarding mysql* i 'd guess it's probably easier to just replace it with mysqli_* calls. Only a few changes would be needed unless the app is doing something unconventional.

Getting a copy of PHPStorm will make things much easier, you can run Reformat code on PHP files and you can also do mass updates from code inspections.

Also worth checking out is a package called Rector (https://github.com/rectorphp/rector) which will automate a lot of this by scanning the codebase and providing diffs so you can upgrade safely.

> Is there a way for me to have an IDE with a kind of "compiler" that would help me convert this to PHP 8 so I can migrate it on a more recent VM? Of course there's 0 budget for this.

There is your problem. If it's runs on PHP5 (<?php phpinfo(); // in a php page), it might run without hurdle on more recent versions of PHP... or not, but PHP8 isn't a different language, they just added some stuff on top of PHP5. C extensions might break though, because yes, PHP relies heavily on them as the language is too slow to do anything meaningful like writing a database driver.

> PHP8 isn't a different language, they just added some stuff on top of PHP5.

there were some backwards-incompatible syntax changes between PHP 5 and 7 though. a client once switched on PHP 7 on his ancient WP website and it stopped working altogether because it used some weird no-longer-supported form of `new Foo`.

IDE: Visual Studio Code with the PHP extensions, free.

Compiler: you are looking in the wrong direction, PHP is interpreted. There were some compilers, but it's not what you need.

Converting to PPHP 8: do you need that? what are you trying to achieve? You can keep the app another year or so it it is working, don't fix what is not broken. There is no way to convert to 8, you need to rewrite it, PHP become more object oriented with each version and that is a paradigm shift there is no converter for.

I was able to convert a PHP 5.4 app to 7.1 but after that there are too many backwards incompatible changes to be easy to fix. Even the upgrade to 7.1 took a few days of tweaks to the code.

In my case the upgrade was demanded by security because the latest PHP5 release is no longer maintained.

For an internal app you're much better off just leaving it on PHP 5. Maybe add an op-cache for performance.

I know PHP is interpreted hence my comment "to have an IDE with a kind of "compiler"".

What I would like is an IDE experience: everything that isn't PHP8 compliant is underlined in red so I can fix the thing without launching the app every time and see if I broke something.

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.

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

As others pointed, the best thing you can do is learn to debug PHP interactively with an IDE (easier locally) so you can step, REPL and so on, into a mess of a code to improve it

I don't really understand why in 2020 there's still this kind of blind hatred against this language. It often comes from horrible bad memories from previous versions or old frameworks.

Objectively, compared to other languages i've been working with it is more than OK. Despite it's lack of "style" it is easy to understand, host, tests, diagnose and it is powerfull for web applications.

I've been working on a SaaS API with Symfony now for 2 years, our metrics are good...

It is a good tool, it builds good softwares

It's essentially sinking in popularity because of bad faith and lack of hype, really sad !

> I don't really understand why in 2020 there's still this kind of blind hatred against this language.

Well, the language is burned for a whole generation of devs, and it's hard to lose the nasty stench once it has settled. A major reason might be that you don't touch again what you learned to dislike. Because you known anyway that it will be painful, why go for it?

> It often comes from horrible bad memories from previous versions or old frameworks.

Those old versions and frameworks are still around. Companies don't lose their legacy fast.

That always was the case with PHP. Doesn't say whether it has lost it's old flaws.

> It's essentially sinking in popularity because of bad faith and lack of hype, really sad !

Is more losing because of competition. PHP still is mainly a web-stack backend-language that can't offer much in other areas. But now there are other languages who can equally shine on backend, while also shine on other areas. So obvisouly people go for the language which can give them more, instead of less.

I haven't found any good arguments against PHP in the comments here, just pure hate. Let's name a few of the arguments people are making:

1. Its variables start with $ and that is ugly: I mean, come on, I won't even entertain this bigotry.

2. It used to be better before: This is just pure nonesense, before OOP PHP wasn't good to create any big and well-structured application, it is ironic because most of the bad opinions about PHP come from people who used it a long time ago. Besides, you can still use PHP as you used to, but now you have more tools at your dispossal, You are free to use it as before.

3. It is trying to be Java: Well, sure it is more like Java, only less verbose and easier to write. Developers can be much more productive in PHP. And moving in the direction of Java is not a bad thing as the language moved into the Enterprise space. I worked with Magento every day and I am glad the language is more than Java than it used to be, it means we can organise our code better. Again, ironic that some people who mentioned this as something bad about PHP, then went on to say they prefer Java.

4. Composer has made the language worse: Honestly this is so ridiculous... so now having package managers is a bad thing? I haven't met an actual professional PHP programmer who holds that opinion. All of them like composer, it makes reusing code and creating apps in PHP much easier.

> 1. Its variables start with $ and that is ugly:

At the very least it seems nonsensical and cargo-cultish: As a non PHP-er, what is the actual purpose of $? In Perl, it indicates variable context (for better or worse, there's more than one, so it has to be indicated somehow). In shell, it indicates the substitution of variable name by its value. In PHP...I draw a blank. It really seems like an "I wanted my language to look like some other language but I had no idea what it should be doing" kind of thing.

$ was taken from Perl

https://stackoverflow.com/a/3073818

but because early PHP was more simplistic than Perl it only has $.

Powershell also uses $ for variables.

Regardless of etymology of the $ sign and the usefulness of it, personally I like it because it makes it easier for me when I'm reading code, especially if you are scanning fast, to differentiate variables from symbols. Yes, you can get that with your editor too, but for me it is easier to associate the $ sign with a variable rather than a specific color, sometimes you don't have coloring available like when in command line going thru diffs, cat, nano etc.

It seemed kind of obvious to me even at that time that it was taken from Perl. I just didn't get why. PHP could have lifted IMPLEMENTATION DIVISION from COBOL, but likewise, there would have been no point either (fortunately it didn't do that!).

Early web was written in Perl, I guess it was the classic approach of lets borrow what is already successful and in end PHP won over Perl so it worked too. Bill Gates would have been proud.

It's actually slightly wrong to just say "variables start with $". It's more like "$ dereferences a string":

  $foo = "I am foo\n";
  $bar = "foo";
  echo $$bar;

This is in the documentation under "variable variables" [0]. This also lets you create dynamic function names:

  function run_foo() {
      echo "I'm a foo\n";
  }

  $method = 'foo';  
  $picked = "run_$method";
  $picked();

[0] https://www.php.net/manual/en/language.variables.variable.ph...

It differentiates variables from global constant things (constants, class names, function names, ...) for which the scoping is different. So you can have $strlen = strlen(...);

Off the top of my head, I struggle to come up with situations where you'd need an $ to distinguish class names or function names syntactically. Hell, in Lisp I can do (let ((length (length seq-1))) ... (length seq-2) ... ) just fine and it still works as expected, so no special characters necessary either.

Plus, to have different scoping rules was considered a good idea? Weird scoping issues were why I gave up on Ruby fifteen years ago; perhaps it was a good idea that I got never that far with PHP. But I'm intrigued now; what exactly are the scoping differences in question?

TBH, I don't know lisp and I have no clue what you just wrote. Someone new to PHP can just be told $something is how variables look like. And they will recognize variables forever from then on. What's a variable in that lisp code, or in any general lisp code? I have no clue at first glance.

I didn't say it's necessary for the parser, but it's useful for the learner/user.

You can do:

$strlen = 'strlen';

echo $strlen('test');

I’ve also seen things like this:

$return = ...

You can’t use a keyword as a variable in most other languages.

It means the start of a variable name, as simple as that, it isn't anything significant. Maybe it was made to make parsing the language easier at the time, who cares?

You can get used to that in 10 min and move on with your life, it is not a reason to not pick up the language, it's bike shedding.

There was a number of other reasons why I didn't end up using PHP, so it was a bit like death by a thousand cuts. It was not the reason for me, just a small showcase of the weirdness for a newcomer.

> 3. It is trying to be Java: Well, sure it is more like Java, only less verbose and easier to write. Developers can be much more productive in PHP.

I suppose if you are equating extra keystrokes to productivity, then sure. However, Java has vast ecosystems and standard libraries that dwarf most languages. The real gains in productivity are in not re-inventing the wheel for everything. Verbosity has little to do with productivity in the bigger picture.

You are proving my point by defending Java against PHP because my argument was that being more like Java isn't a negative thing.

The productivity point was a secondary point but when it comes to building websites I think people can build faster in PHP although I guess that depends on many factors.

I guess I am not following your argument. Are you not saying that since PHP is less verbose than Java, this is better for productivity? After which you then follow up and say that PHP becoming more like Java is not bad? Seems contradictory, no?

My point was that it was ironic for people to say that PHP becoming more Java-like was a bad thing, but then they said that they prefer Java to PHP.

You are right, I did sneak in there that I find PHP less verbose than Java as an advantage, since most people complain about how much typing you need to do in Java I thought this was worth highlighting.

However personally I think PHP evolving to be more similar to Java was a good thing, even better because imo they copied the good parts, ie: OOP instead of the verbosity but that's up for debate.

In short, becoming more like Java was good, but PHP isn't Java and has its own advantages for web development, imo this is that it is less verbose and easier to write.

I have my reasons to _despise_ hosting PHP from an operational perspective. These mostly come from having to host ready-made PHP applications like Nextcloud, Wordpress, Dokuwiki, etc.

1) 'Language configuration' kept in a php.ini that is usually not shipped with any project. Instead, each project tells you what flags to flip so that it runs, but very often every distribution ships PHP with slightly different flags, effectively making it _very_ hard to have a 100% correct php.ini.

2) 'Deployment configuration' that is additionally present in your FPM/apache configuaration. Again, you have to be told by a project that that these given options (often related to timeouts and request size) have to be set. Many projects just assume you have some 'sane defaults' like things bumped up from the defaults. Again, very difficult to get reproducible deployments of an app, unless the developers are very insistent on documenting everything.

3) Extremely painful to debug. If 1) or 2) are broken and a connection terminates during an upload with some 400 error, the error can be in multiple places: nginx/apache, php-fpm, or the PHP code itself. Each one of them logs to a different place, or not at all. It's difficult to actually understand the _source_ of the error. Good luck. Bring strace.

4) Broken upload model. If I understand correctly, all file uploads in PHP must end up on the local filesystem, and they are impossible to directly stream onto something like S3. This means that my Nextcloud instance will first save a few gigs of data on /tmp, and then only punt it over to S3. Gross.

5) Annoying to host in containerized environments. Both Apache and nginx are the kind of applications that insist on doing a bunch of setuid()s, thereby breaking on hardened containerized environments. Not to mention having to host a nginx+fpm/apache combo per application just seems wasteful, but there's no other easy way to deploy PHP apps in a containerized way that I'm aware of.

6) Configuration woes with rewrites, static files, etc. This is related to 2), in which you have to spend a bunch of time configuring your HTTP server in order to split up requests between static file serving and PHP, set up rewrites, and hope you don't accidentally introduce a security vulnerability.

All in all, compares to something like 'here's a go binary, run it, push HTTP traffic to it, it will serve its own static files, too', PHP is an _extreme_ pain in the ass to host.

You're not being fair to the argument #3. PHP is becoming a less good Java. That's the problem. It's like Java, except it doesn't have generics, doesn't have real data structures (List, HashMap, Deque), no threads or async, no method/function reference or typed function parameters, etc.

So the whole "It's trying to be Java" is more like "What does it offer that's better than Java? Because Java has stuff that is better than PHP."

And I'm saying this as someone who doesn't like Java at all.

> it doesn't have generics

It doesn't need them IMO. It brings no benefit to the language, really. They would need to be type checked at runtime, which can become quite expensive. Static analysis is a better option for an interpreted language. Read this answer from Nikita (one of the top PHP contributors) https://www.reddit.com/r/PHP/comments/j65968/ama_with_the_ph...

> doesn't have real data structures

Untrue. See https://www.php.net/manual/en/book.spl.php It's usefulness is limited though, because it's rare that you need those types of data structures for web applications.

> no threads or async

Untrue. All kinds of projects like Swoole (gives you a runtime similar to Go) and ReactPHP (runtime similar to Node) and https://github.com/krakjoe/parallel for lower level concurrency. There's also pthreads https://www.php.net/manual/en/book.pthreads.php But again most of these aren't necessary for most apps because of PHP's request-response model. Useful for one-off services though.

> typed function parameters

Completely untrue. https://www.php.net/manual/en/functions.arguments.php#functi...

> no method/function reference

You do those like this: [Example::class, 'someFunction']

I hate it when people write such blatantly misinformed comments. Sigh.

> It doesn't need them IMO. It brings no benefit to the language, really. They would need to be type checked at runtime, which can become quite expensive. Static analysis is a better option for an interpreted language. Read this answer from Nikita (one of the top PHP contributors) https://www.reddit.com/r/PHP/comments/j65968/ama_with_the_ph...

Right. You need to use something like Psalm if you want the benefits of generics, which is basically a tacked on type system. Having static checking is absolutely beneficial. I'd be willing to bet good money that you don't write PHP without typehints and/or Psalm/PHPstan.

> Untrue. See https://www.php.net/manual/en/book.spl.php It's usefulness is limited though, because it's rare that you need those types of data structures for web applications.

You're totally right. I was thinking that you still needed to explicitly enable SPL, but that hasn't been true for a long time, IIRC. So, fair enough. I was wrong here.

> Untrue. All kinds of projects like Swoole (gives you a runtime similar to Go) and ReactPHP (runtime similar to Node) and https://github.com/krakjoe/parallel for lower level concurrency. There's also pthreads https://www.php.net/manual/en/book.pthreads.php But again most of these aren't necessary for most apps because of PHP's request-response model. Useful for one-off services though.

pthreads was never worth much. It never worked on web servers and is now deprecated. Parallel is a PECL extension, which may or may not be considered part of PHP, IMO. I believe it also doesn't use threads unless you use pthreads (which you should/can not). So it's just multiple processes- not threads or async. I don't know much about Swoole, etc, but those are frameworks- not PHP itself. Also, I believe Swoole is process based, not thread or (true) async. I could be mistaken. So, again, AFAIK, PHP does not have threads or async.

> Completely untrue. https://www.php.net/manual/en/functions.arguments.php#functi...

That's not what I meant. My wording was poor. I meant specifically `callable`. You can't typehint the inputs and outputs of `callable` parameters. So passing around lambdas, etc, is not robust/safe.

> You do those like this: [Example::class, 'someFunction']

Yeah... an array of two strings. Again, I should've been more clear. I know that's how you refer to functions in PHP. But it's not the same as actually getting to write Example::someFunction and knowing that the inputs/outputs line up with whatever you're doing. If you're lucky, your PHPStorm or whatever can tell where you're trying to refer to a function and maybe point to it for you, but otherwise, it just thinks you're passing some strings around, because you are.

> I'd be willing to bet good money that you don't write PHP without typehints and/or Psalm/PHPstan.

Yeah, think of it like Typescript. Same idea.

> Also, I believe Swoole is process based, not thread or (true) async.

It's a coroutine model, like Go. Very fast. But I don't use it because it's primarily a chinese community, lots of the docs are in broken english. But it's an impressive thing anyways.

IMO, you don't need threading in PHP, there's not really that many situations where it would help during a request-response flow. People generally delegate slow tasks to job queues, which often use https://www.php.net/manual/en/function.pcntl-fork.php to fork off workers. Works great.

> That's not what I meant. My wording was poor. I meant specifically `callable`. You can't typehint the inputs and outputs of `callable` parameters. So passing around lambdas, etc, is not robust/safe.

You can though. `fn(SomeClass $foo) => $foo->doThing()`

> and knowing that the inputs/outputs line up with whatever you're doing

Fair enough, but you can use reflection to look at the callable if you care enough. It rarely matters.

PHP have nice libs as extensions for those data structures. It's std variants that should be avoided.

> It is trying to be Java: Well, sure it is more like Java, only less verbose and easier to write. Developers can be much more productive in PHP

This sounds like kool-aid. Any productivity gain from reduced verbosity would be minimal. Typing out two extra keywords for your method signature is not going to affect your productivity in any real way in reality.

And it being dynamic. If just want to dump some JSON or a CSV into an array to do something with it it is probably going to be much quicker than in Java.

The latest version of PHP that I used was 5.3. The power, and disadvantage, was that it was basically a scripting language which allowed for quick prototyping and easily making some of a site dynamic and allowing for templating. For the more serious/involved/enterprise applications, a lot of workarounds were needed to cache database connections etc.

Lots has improved: ide support, jit, package manager. In doing so it became more mature now joining the realm of more serious, enterprise, languages which had all of this for ages. As such it is also being compared against those languages. At the same time templating is now easier and more cheaply done through static site generators. So imho PHP falls a bit in the middle and it is only kept afloat because of the likes of Magento, Wordpress, and other big products built on top of PHP that thrive by being modifiable by practically any developer.

> I worked with Magento every day and I am glad the language is more than Java than it used to be, it means we can organise our code better

Do you consider Magento being a framework you are happy to work with? I'm also working in Magento 2 and honestly it's a painful experience. It's a so bloated framework that without cache enabled the development is completely awful.

>I won't even entertain this bigotry.

I'm not sure using a word that has historically been used for people who are racist is the right word when talking about programming languages.

You might want to look up the definition of "bigotry" then...

The dictionary definition does not change cultural context.

There is a discrepancy between what’s hip, and what’s actually used. On places like HN where everyone is in love with Ruby... errr... Go.... errrr I mean, Rust, you’d think that those languages are the what’s what.

Then when you look at the job market, you get a very different picture of what actually gets used. In my country there hasn’t been a single job posting for all Rust in all of 2020. There’s been a single mention of Go as a “nice to know” PHD job at Google Denmark and there is just a single company who has had openings for Ruby. Hell even with everyone’s favourite Python, almost every job involving it is in DataScience and needs you to be a mathematician first, analyst of some kind second and a programmer third. There are a few django jobs, and good for those guys, but in general, even python doesn’t see that much general usage.

The vast overwhelming amount of jobs that’s been listed in 2020 in Denmark have been for C#, PHP and JavaScript, with JAVA still hanging in there somewhat, though typically bundled with whatever they call JBOSS these days.

So unless you’re smack in the centre of Silicon Valley, I probably wouldn’t worry too much about the hate PHP gets.

That's quite strange. Rust is system level language.

Most web stuff need no memory management and can happily live with GC or even with giant memory footprint and reboot once a day.

Ruby is direct competition. One of two PHP major web frameworks borrowed everything they could from it. Even PHP is on Ruby bandwagon .... XD

> One of two PHP major web frameworks borrowed everything they could from it.

Weird flex.

So you're saying that an aged veteran in any sport who observes and learns from his younger peers should be looked down upon as being on their bandwagon? Their growth, improvement and continued success should be discounted?

> Even PHP is on _Rails'_ bandwagon .... XD

I fixed that for you.

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 is a workhorse for the web and still the most important language next to JS in that regard. But there is a reason it is declining (slowly) as well.

I think that's it. No argument that it's improved, so much, but if you're not already using it then it's hard to pick it over other options. Good luck to the fans though, you can do anything you need with it and if you enjoy it all the better.

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.

People keep saying “PHP in ${current_year} is actually great, it only sucked in ${current_year-5}!” - I feel like it still sucks[1] today, but it’ll take 5 more years for the fans to realise it, when they have the PHP from ${current_year+5} to compare against :P

[1] Being slightly hyperbolic - I won’t deny that you can do good things with PHP, as you can do good things with any tool; and AFAIK it’s still unmatched when it comes to low barrier of entry and shallow learning curve.

(I’m coming from the perspective of someone who mostly uses rust, python, and PHP7.3, with odd bits of Hack - in the past week, PHP7.3 has frustrated me with lack of typed arrays, lack of typed properties [fixed in 7.4! Only took 5 years between the introduction of type declarations and consistent support for type declarations...], and dictionary keys being automatically cast from string to int if they look vaguely numeric. It’s a shame Hack never took off in the open source world, as it’s basically “What if we could reimagine PHP without the legacy baggage?”)

The key to becoming a person who thinks PHP is great now is to primarily use features that have existed for more than 5 years. For me, PHP 7 was PHP 5 that was faster and had some nice little bits of new syntax. They started down the type system road but I avoided it then.

Now it seems like the basic type system is in place, great. This new stuff in the article I'll probably start using it when 8.4 drops.

5 years is an exaggeration, but staying a version or two behind really helps you stay sane.

By the way I found Hack/HHVM thoroughly disappointing. Tried running some fairly complex apps on it and it felt like they reimagined the legacy baggage. Seems like PHP itself borrowed a lot of ideas from it though.

> I don't really understand why in 2020 there's still this kind of blind hatred against this language.

I don't either, but what I also don't understand is why in 2020 anyone would use PHP over many available vastly superior alternatives.

Other than keeping old stuff running, why do people keep beating this dead horse? I just don't get it.

Perhaps some developers who already know PHP want to get on with building things instead spending time comparing language penis lengths?

Probably the package/ framework ecosystem. There is also a self reinforcing quality, there are a lot of devs which in turn encourage people to do projects in PHP to access those devs.

It depends on your goal. I personally think PHP still wins for a solo developers in speed of feature creation. Think of the ratio of business value per development cost. Someone should find a way to objectively measure this.

Then there's this, choose boring technology: https://news.ycombinator.com/item?id=23444594

Same here. Sure, PHP in 2020 is a mostly passable language. But then next to it you have Java/Kotlin/Scala, Go, Clojure, Node w/ TypeScript, even Elixir is pretty awesome.

Though, to be honest, I'd probably use PHP over Node even with TypeScript because the Node ecosystem is such garbage.

You just have to really like Laravel, I guess, to choose PHP in 2020. Which is totally fair. I haven't used Laravel, but people do rave about it.

More than anything, I find the language $ugly. Is that fair? No. Am I being unreasonable. Yes. Do I love PHP? Gross. I just have to live with it and go past the ugly syntax. It’s like an unhappy marriage. It’s just fine.

But that's just like your opinion man (quoting the Big Lebowski). I like seeing the $ sign. Does that mean I am not a good developer ?

I think PHP is a fine language if you are working on an existing application or are building on top of symfony but I’ll begin second guessing all your design decisions if you increase the default execution time of php from thirty seconds to over five minutes. I submit PHP does not belong anywhere outside the request response cycle. If you use it for other stuff, you are not wrong. I mean I’ve used puppeteer and node js to capture screenshots and I still think that ideally JavaScript should only exist in client-side web browser based development. I would never voluntarily do any of the react native or express/hapi server side development with JavaScript. I will do it if there is money involved, it just isn’t my preference.

It is ok to have a preference to do non web work with PHP but you owe it to yourself to at least try something else before saying you prefer it over everything else.

There is nothing wrong with $ though. That’s just insane. Also I’m very excited to see Drupal 9 being released with twig 2 support and more recent symfony support. I just think you should at least evaluate other options before saying “everything goes better with php sauce” just like the JavaScript crowd should stop and get some help before using JavaScript for native development and or server side development.

> Does that mean I am not a good developer ?

He never implied anything remotely similar.

Maybe think of money everytime you see the $ symbol, to make it more palatable? :P

On a serious note, I find the JS ecosystem more annoying than PHP. Modern frameworks like Laravel (Laravel is nice to work with), PHP is more than enough for its intended use - web applications. PHP 7 has good performance improvements too.

> Maybe think of money everytime you see the $ symbol, to make it more palatable? :P

Well, if you had a dollar every time you typed one... ;)

To be fair, a good PHP programmer should earn more than one dollar per each dollar sign typed.

I think it’s popularity has been soaring lately, actually.

It looked like a dead language in the 5.X days, then there was a resurgence with 7.

The funny part is that all the hate they have towards PHP, pretty much most languages have similar or other problems. I say this as someone who loves languages like Go, Python but I run a SAAS business in PHP which brings in close to 7 figures ARR and employs 15+ people. All these developers shitting on PHP are basically the elitist form of "I don't do PHP so you shouldn't either because it sucks and <my shiny language> is so much better".

I know people who run decently sized and successful businesses in a variety of mind-numbing technology (try FileMaker scripting or shell scripting) but that definitely doesn't mean those things don't often suck and that there aren't advances in PL's that don't or won't lead to better software. (I personally don't use PHP at all because I haven't yet seen a reason to use it for any new projects over Python or TS. Is that new match expression proper pattern matching? ;))

It's pretty hard to draw a link between these things and commercial success, but it somewhat unseriously reminds me of Jonathan Blow's warnings that eventually everything is just going to fall apart.

Yes I am not necessarily disagreeing. I am saying that people who shit on PHP think that other languages are somehow this magic wand that is so much better. I challenge the "so much better" part because the cost vs benefit matters.

  "foo" == TRUE
  "foo" == 0
  TRUE != 0

  NULL == 0
  NULL < -1
  0 > -1

You have to test the simplest expressions because you can't trust the language to do what you wrote.

That's why `===` is a thing. But FYI, "foo" == 0 is no longer true in PHP 8: https://3v4l.org/fQLXX RFC is here: https://wiki.php.net/rfc/string_to_number_comparison

Because those of us who know and have used several languages tend to develop a preference for expressiveness, terseness, safety, and dare I say, elegance.

PHP (and JavaScript) gained and maintain their relevance, despite being inferior languages, because of their historical placement. I'm sure COBOL has improved over the years, and we know it is still used and "needed"... because of its historical placement. But you probably wouldn't use it, either, unless you had to (or you didn't know a better alternative).

You can find bad code in any popular language. Therefore, any popular language will get bad rap. Java, C++, PHP...

Bad developers will write bad code in any language, and they will blame the language for it.

Scala is one of my favorites and yet I saw some really horrible projects. They made such a mess since lots of Java developers rushed into it.

People blame Go for lack of a some features like generics just because they are unable to write clean code.

> It often comes from horrible bad memories from previous versions or old frameworks. Not only that. There is a huge amount of devs hating PHP w/o ever having worked with it. Same with Perl.

And I imagine most people would prefer indoor plumbing instead of an outdoor toilet, even if they haven't used an outdoor toilet before.

I also prefer beef steak to catfood, but I admit I have not actually tried cat food...

same for c++

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 project in php now that we have so many good alternatives?

"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/Rust/Go/Julia etc. Each language comes at a cost. No free lunch.

"But why should anyone start a new project in php now that we have so many good alternatives?"

Because everything comes at a cost. You want to use Rust instead of PHP ? Sure, sounds great. Now lets go find a really good Rust developer who also understands how to host it correctly and then if he leaves, can I easily find another Rust developer ? Hmmm. You also need to account for maturity, ecosytem, hosting, maintenance etc which are all real world problems. Building a new shiny toy project ? Go ahead use whatever language you love. Again, it is about cost vs benefit.

Reminds me of "PHP Hammer"

I can’t even say what’s wrong with PHP, because— okay. Imagine you have uh, a toolbox. A set of tools. Looks okay, standard stuff in there.

You pull out a screwdriver, and you see it’s one of those weird tri-headed things. Okay, well, that’s not very useful to you, but you guess it comes in handy sometimes.

You pull out the hammer, but to your dismay, it has the claw part on both sides. Still serviceable though, I mean, you can hit nails with the middle of the head holding it sideways.

You pull out the pliers, but they don’t have those serrated surfaces; it’s flat and smooth. That’s less useful, but it still turns bolts well enough, so whatever.

And on you go. Everything in the box is kind of weird and quirky, but maybe not enough to make it completely worthless. And there’s no clear problem with the set as a whole; it still has all the tools.

Now imagine you meet millions of carpenters using this toolbox who tell you “well hey what’s the problem with these tools? They’re all I’ve ever used and they work fine!” And the carpenters show you the houses they’ve built, where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards and they all yell at you for breaking their door.

That’s what’s wrong with PHP.

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/

edit: Flickr user @raindrift made an actual PHP hammer, famously https://www.flickr.com/photos/nicoletbn/6949293600

2012 discussion of hammer https://news.ycombinator.com/item?id=3866488

TechCrunch defence of the hammer https://techcrunch.com/2012/07/28/not-that-kind-of-filthy-ge...

That's funny and all, but it doesn't drive home much more of a point than "PHP is bad because PHP is bad". The insinuation that all "houses" built with PHP are defective and waiting to fall apart is so obviously untrue that it feels unworthy of discussion.

A more reasonable analogy would be that there's a standardized toolbox that carpenters use that's weird, quirky and sometimes so bad that you need to know workarounds to use it correctly, but the houses that are being built do what they're supposed to in the vast majority of cases because most of the carpenters know the quirks well.

The question then is, if you're contracting someone to build your house, or you're the manager of a construction company, do you go with the standard toolbox that's used by the X% majority of carpenters, or do you hire carpenters that use more obscure (but functionally "better") toolboxes while running the risk of now ending up with unmaintainable or deviating houses that are hard to recruit additional carpenters for because they refuse to work on what is quite objectively "non-standard" houses?

The answer in my mind is no less complex than it would be for software development: it depends, and you should be wary of anyone telling you that it's "obvious" that the answer is one or the other.

Fair point about the houses

I think a better analogy would be that the PHP carpenters have standard old tools that people have used forever, and they work just fine. Normal hammer with wooden handles, normal planes, etc etc.

But there are modern carpenters that have hammers that are 100% metal and never break and actually improve your hammering power. The new electric hand planes work a lot faster, though you do have to be more careful because they can get out of hand quicker. etc etc.

In the end, they both build houses. The old-school carpenters might take longer, and they might have to know more techniques, but they get there in the end.

On the other hand, the modern carpenters sometimes go a littler overboard with their tools and have problems that old-school carpenters don't have, especially with their tools randomly stopping working in the middle of a job. It might not be often, but it happens.

To add to that, the old-school carpenters can actually use a lot of the new tools, too. They fit into the workflow and can be adapted to their old tools. It's just that they primarily stick with their old tools because they're used to them.

It's kind of interesting how much the world of woodworking and software development overlaps in that way.

> On the other hand, the modern carpenters sometimes go a littler overboard with their tools and have problems that old-school carpenters don't have, especially with their tools randomly stopping working in the middle of a job. It might not be often, but it happens.

Great extra point. I'm often surprised at how much random breakage other people just accept as normal in "modern" webdev (meaning, for better or worse, you're involving javascript somewhere in the process). Put another way, I'm frustrated by how much I'm expected to just 'deal with' because a seeming large number of other people don't see a problem with it (or don't see enough of a problem with it).

Your analogy makes is sound as if the problem with PHP is that it's old or lacking features, whereas the point of the original analogy is that it's poorly designed. (Python is older than PHP, so it's not a question of being modern or not.)

By today's standards, old tools are poorly designed. At least, most of them. The one's that have stood the test of time aren't the bad ones.

Those old tools still worked, just not as well as modern versions.

The difference comes in how often modifications need to be made

As yes, the 2012 fractal of bad design, being peddled out yet again - your post is just pure hate, it adds no valid argument whatsoever.

I don't want to get into an "all languages are the same / all languages have quirks" kind of thing, but the idea that PHP is weird, different, and in a sense inscrutable, and this has an impact on its use and performance, just doesn't bear out.

Yes, it has quirks -- so does C, so does C#, so does JS, so does lua, so does tcl, so does every assembly language I've ever worked with.

So what? Are those preventing people from writing good code? Are those preventing people from shipping? Could it be improved? Has it already been improved? No, no, yes, and yes.

The biggest reason PHP's gotten so much scrutiny, to where people write these kinds of posts, is its ubiquity. When JS moved from being that simple, silly language built into the browser into a widely used one, we started seeing slide deck gags about the inscrutability of its comparison operators, yet JS seldom attracts this level of derision.

You can't rely on a compiled/JIT language to address performance requirements. There's always time when your server is overloaded, no matter if it can handle 100 or 10000 RPS. You should architect your app with scalability in mind. And then there's not much difference between languages, only marginal savings on infrastructure. But one month of decend web server host costs about the same as one hour of decent software engineer.

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?

Database transactions is the topic you should look into. There's ways to handle these in all environments.

https://en.wikipedia.org/wiki/Database_transaction

Thanks. So is the general industry practice? I read MySql only supports this since like 2004, somehow reading material doesnt seem to be too concerned about these.

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.

well, on the other hand, if you are starting from scratch as a new developer, trying out go or rust is not too risky as large orgs backing it up. Also, for me, hosting go is much easier than php, as I am not from that era.

200-500 requests per second? I'm sure it can do a ton more. Here's some benchmark numbers: https://www.techempower.com/benchmarks/#section=data-r19&hw=...

I don't believe the constraint would be the language itself, not with accellerators, opcode caches, JIT compilers, etc. I've always been told that PHP's performance is more down to the database than anything else.

> php is slow and max throughput is 200-500 rps

I don't know where you pulled that number out of, but I just used an outdated version of `ab` to request the Hello World page of a fairly heavy PHP framework on a modest virtual server and got over 4k rps. Give me a proper server box and a well-written application, and I'll deliver the 25k rps that you want.

Besides, most webapps spend most of their execution time waiting for the database, memcached, redis, elasticsearch, or whatever. The speed of the language runtime makes very little difference.

> my point was php is slow and max throughput is 200-500 rps

Absolutely not, you could already go to 5k rps 10 years ago and PHP has massively improved since.

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

Because the alternatives is actually not good, it just a fallacy.

There will always be something negative regardless of what you pick, problem is to decide what your core values are when writing different types of software. If you don't, you are just comparing apples to oranges.

When it comes to PHP, core values are usually things that has to do with tooling, server architecture & deployment, not much the language (syntax, expressions, lambdas, classes etc) it self, except maybe it is easy to learn & use.

This means that developers who comes from a background of that the language itself is the most important part of a project will most of the time just get confused what PHP is about.

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.

Well, good performance of http request/response cycle is mostly related to async operation, in some form, when long-lived daemon can process big amount of requests without spending time on initialization. Workerman and swoole, powered by async PHP approach, are very fast and suitable for high load. The problem with async PHP, though, is that you need to be careful with libraries (e.g. mysql client) because most of them were designed with short-lived PHP script execution in mind.

That's true, until a stupid non-rate limited web spider takes most of your resources.

That first example brings back fond memories of Java 1.5 UI programming.

Well it's a bit different, now the events are sent over the network and if you're using the term event-sourcing you can even consider yourself hip.

A quick job search on indeed.com based on coding language:

    Java 32K
    Javascript 30K
    Python 23K
    C 10K
    C++ 10K
    PHP 5K
    Go 3K
    Rust 500

When can we expect Wordpress to upgrade to PHP 8?

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

https://make.wordpress.org/core/2020/10/06/call-for-testing-...

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

And thank fuck for that.

WordPress is the only web framework I've found that approaches stability of the Linux kernel.

Backwards compat is important and maintained.

Gutenberg hurt this a bit but it still does a great job of maintaining backwards compat.

I take old wordpress websites and update them and everything just works.

I take old laravel or code igniter or Drupal sites update them and everything just fucking falls over.

Fwiw, most modern WordPress development is JavaScript / React based. PHP is just a backend glue language at this point for things like templating.

It's a blessing and a curse.

Drupal 5/6/7/8 intentionally broke backward compatibility between versions in order to move the architecture and the feature set forward. The net result is that they are now at a point where Drupal could drop PHP 5 support. They also moved towards modern PHP / coding practices over the past years (Not invented here -> Proudly found elsewhere, composer, PSR's, OOP,...).

WordPress stuck with preserving backward compatibility and so the core API's have never seen a fundamental breaking change between versions. New features have been tacked onto what was already there over time.

I have kept a personal WordPress blog since 2005 and I have always been able to easily update things without migration pains. Of course, I run a minimum of customized code (beyond a custom theme that is). And I suppose YMMV and you still might have a different experience, if you did heavy customization through plugins, heavily leaning on WP's core API's.

Drupal? Totally different experience. Breaking changes and fundamental alterations of the database schema have been par for the course. I've seen 6 month long migration projects to migrate crucial enterprise data between versions. The PTSD of migrating from Drupal 6 to 7 to 8 is real.

Then again, WordPress and Drupal are different tools despite a significant use case overlap. I'd be weary to use either Drupal for a simple blog, or WordPress for an intricate, tailored back office application. I think they are both designed to do different things all together.

Having said that, it's worth noting that the Drupal project is very aware of past pains. One of the big goals of the past few years was working towards avoiding big breaking changes between major versions. It is purported that migrating between Drupal 8 and 9 is far less painful. Of course, it remains to be seen how that holds up in the long term.

Yeah, and just like in the case of Perl, PHP 5 isn't going away anytime soon; there's simply far too much legacy software running on top of it.

The WordPress ecosystem, on the other hand, will probably make the switch much sooner.

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

WP recently said they'll support 5.6 for an unknown amount of time. So not soon

I'm not sure why you're asking or what new features you'd like them to take advantage of, but given PHP's reasonable approach to backwards compatibility, I expect that it won't take too much effort to get Wordpress running on PHP 8, but obviously it's not going to utilize much of the new stuff that way.

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 worst being the attribute #[] syntax... why?! Almost every other language uses @attribute, and it is successful: simple to write, easy to read, why on earth a new and such complicated solution?

While php is making progress step by step, it has no chance of ever becoming of good reputation if it goes all the way to make itself more crazy.

> And the worst being the attribute #[] syntax... why?! Almost every other language uses @attribute, and it is successful: simple to write, easy to read, why on earth a new and such complicated solution?

Simple, it was already taken up [1]. Also `@attribute` syntax is by no way universal (and semantics wildly vary even with the same syntax): `#[]` in particular might have been inspired by Rust.

[1] https://www.php.net/language.operators.errorcontrol

The rfcs have a lot of discussion on those subjects indeed, but I still disagree with the choice!

Also, the current use of @ is before a function call or some get, not before a method/class/... declaration, so a change in that direction would probably be possible. (plus the @ to suppress errors should probably be removed from the language anyway!)

It's not possible because PHP has a LALR(1) parser but this would require arbitrary lookahead.

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

PHP laughably adds warts almost as fast as it removes them, then codifies the new ones as intentional. Hack was a good attempt, but I fear it's too late to fix the soup of features by forking/cloning. I sincerely believe another language will replace it (not python), if they havent already (javascript shudder).

I've used PHP professionally for over 20 years along with other languages. The decisioning of language design, at large, has been mired in "good enough and doesn't break backward compatibility" nonsense all over the spectrum. PHP was the poster child of thinking differently in the 90s. Make the languages BETTER by looking at others, not clutching your Perls /s. Arcane sigils are not the way forward, that's a known (eg Erlang, Haskell, Pony, Perl, etc), even with powerful features that put existing languages to shame.

I'm not up to date on php code, but can't the first example be done using reflection? For example a SubscriberBase class which: lists all of its "on*" methods, checks if there's only one parameter, gets its type via https://www.php.net/manual/en/reflectionparameter.gettype.ph... and registers the method to receive events of that type.

From the docs it looks like it's possible in php7 and doesn't need explicit text mapping. But maybe I'm missing something?

Definitely possible, but that's a bit "magic". It's nicer not to have to rely on methods being named exactly a certain way.

There was a discussion on reddit about this exact same thing, shows that attributes lets you bind multiple events to the same listener more easily: https://www.reddit.com/r/PHP/comments/jgkp2r/php_8_before_an...

I'd need to check if this is still the case in PHP, but Reflection was orders of magnitude slower just a few short years go for cases such as ReflectionClass->methodExists() vs method_exists()

Does it matter if you execute it only once per request?

I'm just going to come out and say it, and say it proudly !

1) I love coding in PHP (I am a cs major)

2) I love riding scooters.

There - internet be damned !

1) I love coding in PHP (I am a cs major)

2) I love riding scooters (I am a cs major)

FTFY

Hahah ok fine ! I accept it !

Not a CS major, but PHP has been my preferred language for web stuff the last 20 years. Even way back it was just so damn easy to work with.

Sure, I'll look to Go, Ruby, Crystal, Elixir and others for more specialized stuff, but plain and simple CRUD web stuff is what PHP is made for.

Couldn't agree more ! Ja Go is fun for "heavy lifting" but CRUD or "throwing something on the internet"... Give me my PHP :)

PHP picks up ideas and syntax from many other languages. I'm happy about it, because it popularizes and normalizes concepts that used to be niche or advanced.

C established a lot of common syntax, and there's some consensus for post-C syntax emerging, like `name: type` syntax, `match` expressions, non-nullable types and operators for them.

Nowadays `[1,2,3]` seems like an obvious syntax for array literals, but it wasn't obvious before JSON and other languages converging on it.

I'm glad you can now write:

    public static function new(): static
    {
        return new static();
    }

It really brings the point across it's static.

I know you're trolling, but FYI the `static` before function has nothing to do with the `static` return type. Like other programming languages the term `static` is used to denote two things.

And other programming languages get away wihout overloading the term.

It's not an excuse for slacking on language design.

"static" itself is originally an overloaded term, and still remains such to this day in C++.

The term is overloaded, which is a bit unfortunate.

However, the unfortunateness is static.

> It really brings the point across it's static.

A bit better, due from 7.x backward it really doesn't transmit any sense to me. Just confusion. And I'm not alone. See https://www.reddit.com/r/PHP/comments/elrnp4/rfc_for_static_...

C did it first:

    static a(int a[static 1]);

Why didnt they use the term singleton or object?

What would they use it for? The first 'static' means the method is a part of the class rather than the instances of that class. The second and third 'static' indicate late static binding, meaning they refer to the class being called, rather than the class defining this method.

(Disclaimer: I know absolutely no PHP whatsoever.)

> The second and third 'static' indicate late static binding, meaning they refer to the class being called, rather than the class defining this method.

Wait, so they're using "static" to mean the binding is happening later? Isn't that essentially less static than binding against the class being defined?

It's still static in the sense that the method is tied to a class, not to an object instance. Does that mean it's "less" static? I wouldn't say so.

Well then I guess we'll have to agree to disagree :-)

It's less static than a method dependent on the object instance, but more static than a method that doesn't even depend on the class. If I've understood correctly (which I quite possibly haven't, in fairness), these are analogous to Python's static methods, class methods and regular methods, and its static methods really are the "most" static.

and new

Let's hope this takes off: https://github.com/abertschi/graalphp

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 ambitious projects are started with Ruby.

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.

I think we use Python now because it is a language of choice in US schools, colleges and universities. Python is a new Basic.

> Python is not suitable for complex multi-layered systems

But PHP is? I cannot imagine a "complex multi-layered system" for which PHP is a better solution than a Python stack.

PHP has (almost) complete strong typing system and all the bells and whistles of OOP needed to implement said systems using proper patterns and methodologies and make it modular and testable enough to be robust and supportable for a long time.

Python has literally all of those things, and has been strongly (but dynamically) type from the very beginning. PHP is still weakly typed today. This code doesn't raise a warning or anything:

  $ php --version
  PHP 7.3.11 (cli) (built: Jun  5 2020 23:50:40) ( NTS )
  Copyright (c) 1997-2018 The PHP Group
  Zend Engine v3.3.11, Copyright (c) 1998-2018 Zend Technologies
  
  $ php -r 'echo "123" + 45;'                                                                
  168

Contrast with Python:

  Python 3.8.3 (default, Jun  1 2020, 10:55:34)
  >>> "123" + 45
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: can only concatenate str (not "int") to str

These examples are not about strong typing, but about type juggling. Strong typing is this:

  declare(strict_types=1);

  use \Domain\SomeItem;
  use \Domain\SomeItemId;
  use \Domain\SomeItemSpec;

  abstract class SomeItemRepo {
    public function GetOneByID(SomeItemId $id): SomeItem;
    /*
     * Still hacky
     *
     * @param []SomeItemSpec $specs
     *
     * @return []SomeItem
     */
    public function GetManyBySpecs(array $specs): array; 
  }

Haskell is very free, and very suitable for complex systems!

Go isn't free? JS isn't free? Guile (which is probably as free as you can get) comes with a web framework too.

Also what does "enterprise grade" mean? I'm not sure if you're aware but the forum we're talking on right now is written in PG's lisp dialect. I'm pretty sure arc is free.

Go will go where Google wants. If you are not Google, you have zero chance introducing substantial changes into it.

JS is not a programming language, it's some nonsense.

If we count C as a programming language with all it's nonsense we have to count JS. Your point with Go makes sense (although IMO it's better than most of google's "open source" projects.)

You didn't have an answer for Guile though. I'd pay money to be able to build web apps in scheme instead of PHP.

I know nothing about Gulie. That makes me think it is some niche language with no ecosystem, no frameworks and limited number of packages.

Go is good, but my point was not about goodness, but about language being free and community-driven.

What nonsense in C makes it comparable to JS? JS today is more like assembly language, other high-level languages are translated into JS.

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

> Python is not suitable for complex multi-layered systems

For example what?

Yeah, really interested to know why ?

It is too loose typed and it's implementation of interfaces is too relaxed to use complex software engineering patterns and methodologies like DDD and SOLID.

> it's implementation of interfaces is too relaxed

as someone only casually used to python im curious how so?

It only has duck-typed interfaces, unable to verify methods' signatures. Trying to implement strong inheritance leads to monstrosities __instancecheck__ and __subclasscheck__ and manual type checking of injected dependencies.

Seriously, enough with PHP. Can we just let it die?

I worked with PHP 5.6 years ago and I hated it.

Recently I worked with PHP 7. Heard about all the work that's been done on it and I was kinda excited to try it. It's still so broken. It doesn't matter if they improve performance or add new cool features. PHP is broken in ways that can't be fixed without breaking compatibility. Fork it or put it out of its pain.

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 scripts on a VPS server and start doing business.

My employer makes billions with PHP. It's not perfect, but it's rock solid for gigantic businesses.

Sure you can build yourself perfect shiny web services using modern bleeding edge languages, meanwhile businesses using PHP for decades are innovating and printing money daily.

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, you can still make billions with broken tools, but you could also have done that more easily with the right tools.

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

>I'm just calling it for what it is: a broken tool.

Thats what every Rust-Fanboy says about the C/C++ Ecosystem

Why is it a broken tool ?

VBA or Excel formulas are responsible for at least as much.

They're actually great technologies, but for a very specific scope. Once you're outside of that strictly restricted scope, they're objectively horrible from an engineering point of view. The standard example is building a database with Excel + formulas.

There is a point in this whole thing. Some technologies should whither and disappear, slowly, over time, so that better one can take over. Or they should remain in their very narrow niches. For PHP I'd venture that it should remain a language for hobbyists creating personal home pages.

Related to this, standard, fixed column, steering wheels also were probably responsible for hundreds of billions of dollars of turnover globally.

But I'd still want my car to have a telescopic steering wheel, airbags, and all the modern safety features you find in a car.

The old school fixed column steering wheel should only be seen in museums or in classic cars out on the road with a special license.

One of our acquisitions was one guy with no real background in tech working over a few years in his spare time and turning a project into a multi-million dollar business competing well against other entries in the market put together by teams of a dozen or more actual developers with millions in VC funding.

And that was a project originally targeting PHP 4 and, by the time I was brought on, had made it all the way up to 5.x.

I mean, yeah, the code is garbage, but if he weren't allowed to write garbage code _he just wouldn't have written the code at all_. If that guy had to sit and learn proper paradigms and server administration and a bunch of other stuff, he would have just gone out and done something else instead.

Yeah, PHP lets you write shitty code (though it also lets you write _good_ code...). But in lowering the barrier to entry as it does, it also lets people who don't know how to write great code turn their ideas into reality. Unlike the suggestion of another comment, I've got a great deal of experience with "saner" languages, but despite PHP getting a bad rap because of its low barrier to entry I still admire PHP as a great equalizer.

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

So does Java, Python, C and C++. This is also a shallow argument. No language is perfect but PHP still suffer from the same design issues a 10/15 years ago, none of them have been correct and it's perfectly valid to point that out.

> My employer makes billions with PHP. It's not perfect, but it's rock solid for gigantic businesses.

And with C, since PHP is written in C and probably whatever fronts your PHP applications, and with Javascript because you sure ain't running PHP on the client and so on and so forth...

PHP is a great fit for the web, always will be. There are “better” languages and solutions but they are usually more difficult to setup or not as easy to learn.

How is it a great fit for the web, compared to other languages? All its unique strengths (in this very narrow context) are being phased out:

1) It used to be loaded straight into the Apache process as a module, which made it very convenient to get started with but required terrible broken hacks to run multiple applications/users separated from each other in a secure way. But nowadays people are switching to PHP-FPM, which is the same approach used by Python, Java and most other languages.

2) Every possible extension baked right into the language as a global function instead of using namespaces and a package manager like other languages. But nowadays people use namespaces and a package manager, just like in other languages.

3) Templating as part of the core language (in fact the core language is a templating language) so you don't need a separate templating library like in other languages. But nowadays people use separate templating libraries, just like in other languages.

> But nowadays people are switching to PHP-FPM, which is the same approach used by Python, Java and most other languages.

What? Not even close. You can update PHP code by just replacing the files, it's not compiled. PHP-FPM is just a layer that provides a fastcgi interface and manages processes that run PHP. It's super easy to run, super easy to proxy to with Caddy or Nginx or whatever else support fastcgi.

Java is compiled, and typically runs its own HTTP server. Python is not compiled, but usually it runs its own HTTP server, or a WSGI server which adds another layer.

> Every possible extension baked right into the language as a global function instead of using namespaces and a package manager like other languages.

Are you trying to say that global functions are a strength? Namespaces are a big improvement. Many modern PHP extensions provide namespaced classes now, it's mainly the older ones that don't.

> PHP is a great fit for the web, always will be. There are “better” languages and solutions but they are usually more difficult to setup or not as easy to learn.

Talking about shallow comment you could say that from dozens of languages that have saner foundations.

> There are “better” languages and solutions but they are usually more difficult to setup or not as easy to learn.

No they are not more difficult to set up, not in the era of containers and PAAS. Of course if you still rely on Go Daddy for hosting, it might be...

Well it's still broken because the broken stuff was never removed, PHP just added new some stuff on top of it. Typing is neat though, but no generics, no private classes/packages so you get the worst of Java "enterprise" OO on top of some dubious language foundations.

I have worked with PHP for years, and I agree completely. I think the people who defend PHP either have too much invested in it, or they have never gotten productive in a saner language. Or both.

The people who invested "too much" in it don't have to defend it. They'll simply continue using it. They'll enjoy the new functionality. If I make millions upon millions of revenue with a PHP application, I don't care if tech nerds dislike the syntax used to build it.

Syntax is very far down the list of problems with PHP

> list of problems with PHP

(Here we go again.) Such us?

And even those problems are very far down the line if the business logic results in the expected revenue.

I use PHP for scripting in Windows, a saner language is not needed for that, in many ways PHP is saner than scripting options included in Windows. It is a good enough product for that job. I can also quickly create a few minimalistic web pages to simplify some of my work, the other languages are an overkill in most of my use cases. There are other reasons to use PHP than what you listed.

Most of the bugs or spaghetti code I have to fix this days are not caused by the language, the issue is most of the time the requirements that changed or the developer was not experienced with that certain problem so he created a monster.

its like saying most of the seg fault caused is not due to use of C. Common langauge pattern / design choices made php to have bugs/ spaghetti code. At the end developer control many thing but that doesn't mean language don't have any fault.

It is not fair to bring C into this, C is an old language and when all the kernels and core libraries were created it was the best tool for the job. You hate C please go and contribute to the many rewrites and one day 25 years from now maybe we will have an OS written in some language that is cool now but would be outdated then.

My advice is use the best tool for the job when possible, if you don't have a choice then learn to accept that most of us work with less cool languages/frameworks/projects ... the skill we bring is to find solutions for our customers and implement this solutions as best we can with the tools we have, most of the time a developer should be spending reading stuff(documentation,articles, code), thinking and the least time should be spent on typing code or tooling.

If we want to really reduce typing we should make everyone program in Haskell (and start a national effort to improve its tooling) ;)

I think you misunderstand me , my point is think more and type less. Is not about clever one liners or languages with less verbosity but better implementations and abstractions and you can implement a good solution in a lot of languages.

An example would be where a dev needs to implement X, then he goes on Google , finds some code sample , copy-pastes it, tests it, then changes here and there to make it work. The issue is that he maybe forgot to read the documentation for the functions used in the sample, or did not think that the sample is incomplete (maybe missinfg input sanitation) or is outdated or the solution was already in the project code if he only have asked or looked around in the code.

Other example is when a dev wants to solve X, installs a package from npm that does X but does not understand it and in fact that npm package is just a few lines of code that you could have read, learn something, find limitations and improve that.

Yeah, as another user has said, PHP is getting "cooler" (do you get it?). However not only because it is turning into a sort of "Java-like" is will be get heater again. PHP is fine for its stuff on FastCGI but more further than that, I don't think so, sorry. There are many of programming language alternatives out there.

Live and let live. There is enough space in this Universe for you and PHP to coexist without interacting, if you don't like it then ignore it.

Yeah that's mostly true, at least until you get a new job and only a few weeks in you find out they have a "small" years old service written in PHP that no one else wants to maintain :)

That's my story, I ignored PHP for years but since I had to work again on it recently and got pretty quickly hit by its "rough edges" I couldn't help but ask myself why such a bad language is still around.

Because unlike "good" languages it generates revenue.

The day you reach perfection is the day you finish your project as in never...

PHP works (thought not perfect) lets me get things done.

Lots of languages work and let you get things done. You don't have to choose PHP.

Yeah, It's because certain devs instead of adopting a defensive position in favor of PHP. They don't think in the fact that there are many alternatives of programming languages even superior than PHP for different use cases and exigencies. E.g Lua, Julia, Erlang, Python, even the slow Ruby just to name few of them.

"Lua, Julia, Erlang"

For most CRUD web development, using Lua/Julia/Erlang has a heavy cost upfront of learning, finding developers and many other issues like hosting etc. PHP works out of the box on most servers and has a mature ecosytem. So this is why I cannot just get into Lua or Julia because it is much better than PHP. It is all about cost vs benefit analysis. Sure, if I am building something like whatsapp, I should probably learn Erlang over PHP but if I am building yet another CRUD App (which most web apps are even in 2020), I am totally ok with PHP since that gives me the quickest and most mature way to get started.

People who care too much about languages remind me of the "If you have a hammer, everything looks like a nail" situation. Not every application has to be built in Julia/Lua/Rust whatever.

PHP lets you get things done. You don't have to choose another language.

I didn't use PHP since ver 4-5. This looks like a different language. Even so I hope I won't have to use it again.

It has a great package manager since then, a nice ecosystem, and deployment remains trivial too. There's still a use case for PHP.

While I used drupal heavily then switched to wordpress for all sites I do, I'm now using golang instead.

PHP is good at what it does, but its usage is in decline over recent two decades, actually, if without wordpress's installation, its relevance might be very very limited if anything at all these days.

I don't understand as of 2020 the use case for PHP. It's verbose as Java without its speed. Seriously, can anybody help here?

It made sense to use PHP EXACLTLY in the good bad old days because it was just leaner to bang out applications in PHP than with other languages.

Nowadays, I feel that PHP cake has been largely eaten by Python and Ruby.

Why using PHP with such a level of verbosity?

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

I don't know what to say in response.

Conciseness is a valuable property which, for web development, PHP seems to have given up.

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 :)

PHP is faster than both Python and Ruby. That's one reason. And its request-response, shared-nothing model makes it incredibly scalable. Huge community, one of the best package managers in existence, etc.

See the comment by TheHemric, it's a bit more informed than you seem to be.

Uhm

>Objectively, compared to other languages i've been working with it is more than OK. Despite it's lack of "style" it is easy to understand, host, tests, diagnose and it is powerfull for web applications. >I've been working on a SaaS API with Symfony now for 2 years, our metrics are good... >It is a good tool, it builds good softwares

Informed? These are opinions, dude. Where are the objective arguments? "It is ok, works for me" is not "being informed"

I am not a developer, but by far most of the code I had to write in the past 5-6 years was in PHP. I see it going in a direction where it is no longer PHP, but trying to be something else it will never be (Java? C#?), so I may continue using it as long as it is backward compatible and that's it: good bye PHP, I am the same but you are not. I am not resistant to change, just the reasons I picked PHP versus something else are going away.

Nothing is stopping you of writing PHP the "old" way, all new stuff is optional.

Only if you work alone. If you're in a team, you'll eventually have to start dealing with the new stuff.

8 years after the publication of the famous "PHP: a fractal of bad design", has PHP overcome any of the point raised in this article?

https://www.pixelstech.net/article/1334166417-PHP%3A-a-fract...

Reply on news.ycombinator.com