Modern PHP

If anything, it's holding PHP back. I don't often work with WordPress projects, but when I have to, it makes me want to cry with how backwards they are. WordPress doesn't even have a real routing system!

Furthermore, its ecosystem just seems to encourage really, really bad things, like user-editable templates, PHP code "snippets" stored in the database, images which should be in themes stored as post attachments instead, and just general lack of respect for the idea of separating code and content. Almost every "plug-in" or template is crippled and begging for license fees and/or throwing spammy "notifications" all over the admin interface. I know this sort of stuff are more culture issues than code ones, but they're still problems, and ones you only really see happening in WordPress sites.

I get angry when a client comes to me with a bundle of WordPress mess and asks me to fix or improve something. It's shameful and disrespectful to take a client's money and give them a WordPress site in return. Do these people actually not realize there's far better things out there?

What are your credentials with non-PHP, non-JS/TS languages? Have you written some Rust, Kotlin, Swift, ReasonML/ReScript/OCaml, Haskell, Elm or Clojure? Those languages are different to some extend, they take fresh approaches, they contain new ideas and are scrape throat well designed.

I find most cheering for PHP and JS have very little exposure to other camps of software development.

> PHP is probably the best language for server side webdev today.

I'm telling you (opinion ahead), it most likely is not. And most likely will never be. It simply has too many fundamental design errors that have long known solutions, are near impossible to fix in PHP/JS and are fixed-by-design in other languages that also have good tooling for web-dev.

This is not just PHP/JS. But since we are looking at "the best lang for webdev" I limit myself the these and this use case.

Composer suddenly got good, didn't it! Composer 1.x was one of my pain points I think.

I can't think of many things that really bug me much anymore.

Null coalescing operators and named parameters are the kinds of things that make me happy.

I also adore Laravel (and particularly Lighthouse).

But what I really like about PHP is the humility and maturity of the whole endeavour. It's really typified by Rasmus Lerdorf who openly critiques his own abilities and seeks out smart people.

This attitude of “what is the best” promotes cargo culting and should stop.

This is very interesting, I didn't know this. This is a perfect fit for PHP, as it was always designed with this model in mind, and the programmers that use PHP are already used to this way of developing, as that's exactly how php-fpm and mod_php already work and always have.

This has not been my experience at all. Updating PHP versions _and_ some even fundamental libraries has been very painful and anxiety inducing, you had to be very careful and patient. It's similar to JS in that regard and in some cases worse.

Maybe there’s a way to do them “right”, where they have the same positive impact on code readability. But I haven’t found a font yet which pulls that off.

I’m not a font designer, so this is just using my imagination, but I suspect they’d work better if they still left some space in the monospace grid rather than fully spanning multiple characters. Eg => looks like an arrow but with a very fine gap (1px at any size? maybe 1 device pixel on high DPI at smaller sizes?) between the characters.

The problem with templating systems, routers, DI containers, testing frameworks, etc.. is that they are all very opinionated. There is no one way to do it, and each implementation has upsides and downsides.

On top of that, the PHP ecosystem is so mature that for each of the possible implementations of these features, there is a stable, production-ready and actively maintained library/framework. Why reinvent the wheel?

An important detail is that most of these frameworks have also built a business around their product, which means that people are being paid to work on them. How would the financial situation work if you moved all that into the core?

For me, the current situation is close to the ideal one. For example, the recent addition of fibers into the core in PHP 8.1 was a logical step to allow cooperative multi-threading. It will be used by great userland frameworks like Revolt, Amp, ReactPHP and more. The full event loop feature would be too heavy for the core.

+ Composer is so great that installing any of these packages is a breeze anyway.

PHP scripts on shared webhosting was the original "serverless" and you didn't have to be too careful about object lifetimes and leaking database connections because as soon as the request was finished the entire process was nuked from orbit.

But "modern PHP" is the complete antithesis of everything that I grew to admire about PHP because it's just another Java or C# with awful syntax and weird equality rules and gigantic frameworks with thousands of classes and interfaces.

I would very much like to see a version of PHP that dropped all the nasty namespace and object-oriented misfeatures and just focused on cleaning up the language semantics and enhancing the built-in framework features...

As someone who had to deploy PHP applications: hell no. For developers it might be easy, but for admins, the runtime is nowhere near good. Sure if you think deploying your site using scp, already discovered rsync to do this, or even use the cutting edge way of deploying by using a git checkout on the server, you might think it's great. But that's how you take down sites or have service interruption.

The problem is not that it cannot be done right, the problem is that the runtime enables and even promotes such bad practices, and makes doing it properly harder than it should be. And then we don't go into php extensions, performance tuning, profiling, scaling, ...

And that solves both issues at once.

[1] https://openswoole.com/

I guess I started writing PHP when PHP 5 was already a thing, didn't depend on any third party code, and used PDO from the start, so... I guess I was lucky to pick the right abstractions.

I mean, we have ways to catch those errors, its just that when they do appear in prod its usually because the project is so low impact (99%) that the budget for testing and whatnot is nonexistant (and the reasons for that vary from project to project, of course).

My experience suggests that, were this error to appear in a more complex component (say a shopping cart or notification system) these "non-entirely static-content-based" parts usually are either separate projects or have their own adequately-sized test code.

"But this is not a website, its a complex web app" - then PHP was probably not the most sound technical choice from the start.

"But this teaches bad practices" - practices are always evolving, new languages appear from time to time. I'd rather work on fixing real world problems.

"But PHP is old!" - so is Java... besides, another name for "old technology" is "stable tecnology".

In short, it is best if there are no errors in your code (haha yeah right..). If there are any, and its a website written in PHP acessing an undefined variable, it is probably a small thing. And if its critical that it does not happen, its usually an engineering blunder. Not the language's fault.

In particular, this exact case you're talking about is being voted on right now, to promote it to an error instead in PHP 9.0: https://wiki.php.net/rfc/undefined_variable_error_promotion

It's looking like the vote will pass (as of writing, 33 to 8 ~= 80%, and 67% is needed).

https://github.com/laravel/framework/blob/master/src/Illumin...

For other frameworks, you can convert warnings into exceptions with 3 lines by implementing a custom error handler.

Every time a PHP post makes it to the HN frontpage, there's a ton of people saying how easy it is to pick up, build a project on, and deploy. I sometimes wondered "hm, maybe I was wrong about it, I might try it out". I had no idea it had skeletons like this hidden in the closet.

I agree the type system is superior, given the language was created to have a type system in the first place (PHP was not).

But PHP has allowed nullable types in syntax since PHP 7.1.

> Named parameters are an interesting one. The Hack equivalent is to use shapes

Hack shapes are not Hack’s answer to named parameters. Instead they’re a way to specify dict contents on a more granular level. A comparable array shape type, expressed in docblock form, is now supported by all major PHP static analysis software.

> Take match expressions plus enums. Incredibly useful. You know what's even more useful? When it's a type error to leave out one of the values.

Most PHP static analysis tools give you this information.

> I also find the Hack collection types (vec, keyset, dict) to be superior to PHP's array with more obvious semantics and less weird type coercion.

Absolutely agree with this, but for now (and maybe in perpetuity) we’ll have to settle for the swiss-army-knife array type.

The divide could be catastrophic and for me, would be a major turn off. Look at JS and TS. Some projects go all in, but then others half ass it with `any` return types all over the place. If the JS ecosystem can come together around TS, it’s probably still a decade out until it becomes the default used everywhere. That gap creates confusion and chaos.

If people want similar languages with more/less features, they can create those communities. Erlang and Elixir are good examples.

It's not. Unless you have a strict typing on the function in TS, you can't know if you're typing the right member.

This is actually one of the thing in PHP I like more than TS.

It takes no effort to provide meaningful names to parameters from the caller.

Static typing cannot be retrofited into PHP. Core already has hard time with generics. PHP Types will always be just type guards with dynamically typed variables.

The dollar sign does kinda look like a loose piece of shoestring, though

with each category had it's own optional syntax, many language will avoid this through context in which the symbol is, thus (+ a 1) equates (+ (deref a) 1), but he meant that it was a choice and not an obligation and some systems used $ or other syntactic constructs.

A lot of PHP projects are littered with this kind of stuff, and when there's actually some important comment it's easy to miss.

They’re a great idea in languages designed with them from the start, but adding them to an existing language makes something that was previously a private implementation detail part of the public contract, and only for certain versions of the language. There are already packages that opt out of considering parameters names part of their semantic versioning, effectively demoting it to a “use at your own risk” feature.

I would almost have preferred it to be added only as a special case for built-in features, which are almost all plain functions and have become somewhat unwieldy in places. Third-party code is more often than not object oriented, and so could easily lean on stuff like parameter arrays or fluent interfaces to avoid the ergonomic issues from having tons of parameters.

Convoluted example: sort some cars by year then by weight except with all Toyota first

In general it is easy to simulate multiple SQL `order by` clauses with [-1,0,1].

Using primitives you can map each car to something like "0t-1994y-0300kg" (remembering to left pad numbers) and sort by that.

In practice they are equivalent (when used correctly) but it is easier to implement primitive sorting with [-1,0,1] than viceversa.

Sometimes I wish languages would have native equality and order operators on (immutable) arrays, so that [1,1]<[1,2]<[2,0]<[2,0,-1] would work...

I guess it's a nice feature to have, but I tend to forget that it exists. Clearly it's not exactly a new feature I was ever very excited about.

It doesn't help that writing my own sorting callbacks is itself something I rarely need to do.

Or reading their free book https://symfony.com/book

That said, if you care about performance, be wary of shared hosts. Some frameworks, like Symfony, need quite a bit of CPU and IO to build a up a cache to get acceptable execution speeds. Nothing too dramatic, but shortly after setting up a website it may be slow on shared hosts with strict CPU and memory limits.

But shared hosting is a security nightmare. VPSes are super cheap nowadays, it's way better to go with that if you're trying to start/run a business.

    ['abc' => 2, 'def' => 3][$x] ?? 'default';

    return match ($key) {
        "id", "ID" => unique_id(),
        "UUID" => generate_uuid(),
        default => findExternalId($key),
    };

['abc' => 2, 'def' => 3][$x] ?? 'default';

Also PHP's Composer no longer supports Hack. Hack was supposed to get its own package manager but AFAIK that never materialized.

PHP today is so so SO much better then the blubbering eldritch horror that was php 4/5.

I'm still not going to use it until they fix the ad-hoc/chaotic naming of their built in functions, but it seems there's a proposal to alias all their functions to new names that make sense and are consistent with each other. When that happens php will not just be widely productive, it'll be widely liked too.

What should those negligent people use instead, particularly?

What's your suggestion for an alternative system that is as deployable?

I mean, in the "stances", just as an example -- "a language must be concise"?

Really? It must? I think this is inappropriately assertive. IMO the better JS I have seen has avoided some of the more unnecessary conciseness. And that is before we discuss the worst example of "conciseness" thinking in a generation: JSX.

PHP and its community is, if you want a different opinion, more mature, more pragmatic and entirely less screwed up than Node.js, which is, to borrow the terminology, a fractal of indiscipline.

PHP's developers and its wider community have gone about fixing problems while NPM just seems to create new ones.

(The author of that post is in fact a Python fan, which makes it even more chucklesome when looked at over a ten-year timescale. One of the two languages managed to bring developers along for that whole decade with a campaign of carefully planned major improvements and deprecations, without causing major schisms, and it wasn't Python.)

Many of the points in the decade-old article still stand, but the ecosystem around PHP has papered over a lot of the cracks in a variety of ways.

The PHP internals maintainers don't have the time to maintain a tool like Composer alongside the rest of the language. And if it was bundled with PHP, it would be stuck in lock-step with PHP version releases, which means improvement can only be made once a year, basically. That's not acceptable. Composer wouldn't be what it is if it had to release so slowly.