A lot of people are too proud to be associated with PHP. I am ready to admit that know nothing about the language except that a lot of people make cool things with it.
My favourite PHP product at the moment is BookStack (https://www.bookstackapp.com/), a really good wiki. I run an instance for my family and it's great.
But there are loads of things. And I notice that many of the sites I like using...are built on well maintained PHP stacks.
Modern PHP is a damn fine, fast language. I wrote production PHP from 2021 to 2023. The problem with PHP wasn't the language or the ecosystem (PHP community packages are very solid in my experience), it's the existing PHP code you'll work with and the people that hire for PHP.
My salary literally doubled within two years of getting a gig that wasn't PHP. If you see a listing for PHP dev work, there's a good chance it's notably lower salary. There are still solid gigs for it, but I swear they lean lower.
The other problem is the existing codebases. There is some awful legacy PHP 4 era code. There are also a lot of practices that old PHP had that are just awful to work with, and there's a bit of variety in there. So many bad data access patterns out there. Many of old PHP codebases have their own spin on that kind of thing.
I understand this isn't actually due to the language, but there is a real correlation (in my experience) between old bad code and it being in PHP. Which is totally fair because it was a good tool to reach for to "get shit done (r)" and that code was successful enough to have to continue to live.
Modern PHP has, thanks to the core language and the big frameworks, made it wonderful. I lead a big push to go from PHP 5.8 to PHP 8.1 at the time at my last company. It was wonderful. The quality of the code we were enabled to write was huge.
If I was starting a new project today, I probably wouldn't reach for PHP, but I'd gladly join in on a modern (last ten years) Laravel project.
PHP is a very pleasant and straight-forward language to work with. I enjoyed my time working with it, though I did also see quite a lot of very poor code.
I think the danger with PHP is more its ability to easily cause *very bad things*.
This would partially be poor training (my University literally taught PHP with SQL-injectable examples), and I think the language itself making it very easy, such that less-experienced developers using it - most of them, early on - don't realise what's wrong until it's gone wrong.
With PHP being such an early tool online, and the above properties existing, it earned a reputation for being insecure and bad.
It's like walking on minefields with very different "mine densities"; when using something stricter, you would have one mine per acre, with PHP you would have ten.
For the longest time the language had been developed with this mentality that it's okay to continue running if something broke, that it's better to print out something than to do nothing and bail out.
Which means that for things to run reliably, you have to write very defensive code that checks everything you can think of. Which is probably a good idea with any language, but I find that old PHP requires much more of this.
Thankfully, they've been changing that over the past decade while still maintaining decent compatibility with old code. I just recently finished porting a pretty large project (~2 mil SLoC) from the ten year old 5.6 to the currently latest 8.4, and it's been pretty painless. The only things that broke were those that were never actually properly implemented and worked by pure chance.
Give me an example where PHP invites developers to do terrible things and I'll show you 2 other popular languages that invite equally bad or worse things :)
Or as Bjarne Stroustrup put it: There's two types of languages: The ones people complain about and the ones noone uses
You can do crazy things in every language. However, in a language like Java, the crazy things are more conceptual (factory for factory of factories) and not basic things like what does == mean or problems with weak typing and implicit conversions. A lot of the issues with PHP can be avoided in modern PHP using things like strict_types=1, but most of the time, we don't get to work with projects using best practices. And I'd rather work with a bad Java project than any bad PHP project (which I have had the misfortune of maintaining).
Funny that you picked == as an example when == is very counter intuitive in Java and is one of the common pitfalls for beginners:
String a = new String();
String b = new String();
a = "test";
b = a + "";
if (a == "test")
{
// true
}
if (b == "test")
{
// false
}
if (a == b)
{
// false
}
Just like PHP, you have to read the docs to use it properly.
This is a decade-old PHP defence fallacy. No one says other languages have no problems, so "disproving" that is the fallacy. PHP just has far more problems and footguns. Maybe now it has fewer, but still. Far more.
So you're going to ignore the rest of what I wrote? I'll just assume you agree with me and the rest of my comment, but you don't want to admit it. Works for me.
The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate.
PHP has an operator for something you should never do in a sane codebase.
You know that python wants good good to look good?
PHP was written in a way that makes bad code look good. And if we want Software Engineering to be a serious field that evolves, we have to be able to be honest with ourselves. It is a bad tool. Good programmers can even write good programs with bad tools. Doesn't mean you shouldn't avoid bad tools given the option.
There probably is a "PHP the good parts". But Javascript actually had a pretty nice core, and an utility of being in all web browsers that no other language could replicate. What niche does PHP have where it brings more value there other nicer languages can't be used instead?
You absolutely can use @ in sane codebases. And you give the example yourself: In other languages you often enough see that boilerplate where thrown exception is discarded, because there is no sane reaction to some edge case and you just want the program to continue, because you know it will work anyway. And that's @.
Note though that @ was already neutered in some earlier recent PHP releases.
One common use case for the @ operator, is when "destructuring" array members into variables. In some cases, you can't know if the member will be available, but it's not important if it's missing. In that case, you can silence the warning.
> The @ operator of php. In languages like Java, to silently catch all exceptions and do nothing with them requires at least some boiler plate.
The @ operator doesn't get rid of exceptions it get rids of "warnings" which are basically built in log messages.
It used to get a bad wrap for also silencing fatal errors, but it stopped doing that a while ago.
The @ operator is something that should only be rarely used, but it is no way comparable to catching exceptions and doing nothing with them. There are sane uses for it.
The claim was "PHP invites bad code" - but your point is for "bad code can be written in PHP" which is really not the same thing. A quick google for the @ brought up https://stackoverflow.com/questions/136899/suppress-error-wi... where the highest voted response is ~"NO, don't use it please".
No use case I've come across during the past 10 years has required or even nudged me in the direction of @. It's an ancient relic that the whole community considers a no-no. I'd be curious if you really want to argue that this state of affairs "invites" using the @.
At least in my experience, the early years of PHP was lacking more enterprisey users; back then there was a small revolution when RoR came out and introduced the MVC pattern to a lot of (web) developers, who didn't have as opinionated a pattern / architecture up until then.
During that same period, there were a lot of mediocre tutorials and documentation online, including on the PHP website itself which allowed people in comments to post code examples, but as far as I know there wasn't a lot of moderation on those.
And finally, a lot of people ended up writing their own frameworks and the like, because they could. But also because there weren't any or not many good and widely adopted frameworks out there, that came later with first Zend Framework and then Laravel, the latter being the de-facto standard nowadays.
I'd take PHP instead of JS/TS + framework-of-the-day on the backend anytime. Ok, PHP is usually also paired with a framework (cough Laravel cough), but at least there the situation is more stable, not to mention more mature. Unfortunately, I'm not the only one making the decisions...
PHP has introduced breaking changes, deprecations etc. in a somewhat rapid fashion.
PHP doesn't prioritize stability, but language features and cleanup. It's an impressive technical endeavor that has its merits, but comes with a tradeoff.
Within the last 10 years, the language itself broke twice. And that's not counting the ecosystem on top of it. Common frameworks, libraries etc. tend to break relatively often as well.
There are languages that are _much_ more stable and reliable than that.
That has not been my experience and I have a project that started in 2017 with PHP 7.1 & Symfony 3.3 and is now at PHP 8.4 & Symfony 7.3 with plenty of dependencies.
Not everything will always update flawlessly but with Composer and a popular framework with planned depreciations and releases the ecosystem tends to sync fairly well.
A lot of mediocre devs sitting at corporations that migrated from PHP to Java and currently can’t write relatively good code in any language make jokes of PHP, because it was popular for some time.
They won’t admit the language gave them food, they have no idea how language looks today and are way too proud to admit any of that.
Definitely one of the weaker areas in the current LLM boom. Comparing models, or even different versions of the same model, is a pseudo-scientific mess.
I'm still using https://lmarena.ai/leaderboard. Perhaps there is something better and someone will pipe up to tell me about it. But we use LLMs at work and have unexplainable variations between them.
And when we get a prompt working reliably on one model, we often have trouble porting it to another LLM - even straight "version upgrades" such as from GPT-4 to -5. Your prompt and your model become highly coupled quite easily.
I dunno what to do about it and am tending to just pick Gemini as a result.
Even professional human evaluators are quite vulnerable to sycophancy and overconfident-and-wrong answers. And LMArena evaluators aren't professionals.
A lot of the sycophancy mess that seeps from this generation of LLM stems from reckless tuning based on human feedback. Tuning for good LMArena performance has similar effects - and not at all by a coincidence.
It's biased to small context performance, which is why I don't pay much attention to it as a developer aside from a quick glance. I need performance at 40-100k tokens which models like Deepseek can't deliver but Gemini 2.5 Pro and ChatGPT 5.0 Thinking can.
And even "long term performance" splits itself into "performance on multi-turn instruction following" and "performance on agentic tasks" down the line. And "performance on agentic tasks" is a hydra in itself.
Capturing LLM performance with a single metric is a hopeless task. But even a single flawed metric beats no metrics at all.
This is something I've stuggled with for my site, I made https://aimodelreview.com/ to compare the outputs of LLMs over a variety of prompts and categories, allowing a side by side comparison between them. I ran each prompt 4 times for each model with different temperature values available as a toggles.
My thinking was to just make the responses available to users and let them see how models perform. But from some feedback, turns out users don't want to have to evaluate the answers and would rather see a leaderboard and rankings.
The scalable solution to that would be LLM as judge that some benchmarks already use, but that just feels wrong to me.
LM Arena tries to solve this with the crowd sourced solution, but I think the right method would have to be domain expert human reviewers, so like Wirecutter VS IMDb, but that is expensive to pull off.
>when we get a prompt working reliably on one model, we often have trouble porting it to another LLM
I saw a study where a prompt massively boosted one model's performance on a task, but significantly reduced another popular model's performance on the same task.
> Comparing models, or even different versions of the same model, is a pseudo-scientific mess.
Reminder that in most cases, it's impossible to know if there is cross-contamination from the test set of the public benchmarks, as most LLMs are not truely open-source. We can't replicate them.
So arguably it's worse in some cases, pretty much fraud if you account for the VC money pouring in. This is even more evident in unknown models from lesser known institutes like from UAE.
> the amazing resources of BBC radio (that precede all modern internet podcasts and the best of which still wipe the floor with most of them) are often forgotten
I don't know, there are some definite bright spots like IOT but the typical output of Radio 4 is definitely not massively in advance of the big podcasts. The Rest Is History/Politics are clearly hugely popular inside the UK and basically constitute "the competition" for your average R4 listener.
I actually think that the podcast model is a big threat for traditional radio. Podcasts are much more lucrative for the makers, the reach is as-big (or bigger) and you don't have to negotiate with the government like R4 does.
There are podcasts I like but a lot of the popular ones in the UK are very self indulgent. The Rest Is Politics is definitely one of those. They're also able to be opinionated in a way that the BBC's output obviously can't be as a state broadcaster. I always find the BBC output more professionally scripted, presented and edited as well, even if the content is similar. Some podcasts are horrendous at not balancing the audio - Not Another One (politics) is one of those even though I think it's great.
the typical output of Radio 4 is definitely not massively in advance
I agree, I chose the wording "best of" rather than "typical" for that reason.
For instance, I regret the asinine tendency to provide "humourous" expositions of subjects in the various programmes co-chaired by second-rate comedians and apparently aimed at what low-expectations BBC execs feel young people can handle.
TRIP was formed in the turbulence of the crashing conservative governerment and it was a breath of fresh air to have people close to the inside who were commenting on unfolding events nearly daily while also saying all the things that traditional media didn't. I looked forward to TRIP every time Boris blundered so that I could hear the guys disect it with a few personal anecdotes thrown in from their time in power. Now, there's nothing much new about hearing Alasdair talk about Tony Blair again and I don't think the centrist dad approach has anything much to say about Kier Starmer's government.
I find Political Currency better these days since Ed Balls and Osborne are at least both people who had very key political roles in their own right (Balls during the Blair government in the Treasury with Gordon Brown, then Shadow Chancellor, Osborne as part of Cameron's rise to power and Chancellor), plus there's the odd tidbit of opinion on the current government which you sometimes wonder whether is coming through from inside knowledge due to Balls being married to Yvette Cooper.
I read your link and it does not support your view that the facts are different than they appear. He calculates a bit differently (including not just currently living bats but those bats yet unborn) but still I feel the tunnel was not necessary
You're looking at someone saying "look at this tiny pothole and how awful it is on a road" when 50 yards further down there's a massive chasm.
It's a distraction technique as old as the hills, and implies the blame for the missing 100b is because of bat boxes, while others run off with the remaining 99b.
No it's not. The bad boxes are both literal and metaphorical. There are many stupid straws on this stupid camel and every stupid straw is there because a stupid person said "but what about my bats, or whatever" without consideration and/or caring for the big picture.
What is missing? The ORM works with asyncio, you can have async views, you can have long running connection-oriented async stuff for websockets etc (via django channels). Maybe there is something important that I'm missing but that seems more complete than most async-only frameworks.
There are numerous things still missing in terms of async support. Most notably for me is DB transaction support which leads to most non-safe endpoints running on the shared sync_to_async thread and me having to separate my code into one async function calling another sync function wrapped in sync_to_async.
In fact if you look at the source there is a lot of async methods in the framework itself which just straight up calls sync_to_async e.g. caching. This doesn't matter as much as hopefully it will get added proper async eventually. But I think believing your requests wont block just because you're using async is a bit naive at this point in Django and the async implementation has been going for years.
Not to mention that the majority of third party libraries lack support for async so you'll probably have to write your own wrappers for e.g. middleware.
> But I think believing your requests wont block just because you're using async is a bit naive at this point in Django
TBH personally I have yet to work on any professional async Python project (Django based or not) which did not have event loop pauses due to accidental blocking IO or CPU exhaustion.
I take your point fully though that a lot of Django's "async" methods are really using a thread pool. (True for much closed source async code as well!)
I think many groups effectively died during that period - but were just able to limp along a bit longer as a virtual meet rather than physical. Once your meetup is sub 30 attendees (attendees who actually attend - so ~45 RSVPs) you lose critical mass and everything from getting people to talk to finding a space to meet becomes very difficult.
Sparing everyone else a browse of the bugtracker: the maintainer does not seem to use a bot to autoclose issues. The close issues appeared to be actually closed and it seemed from a quick glance that he actually investigated each filing.
Yep, no bots. A real bug not only means that I wasted someone else’s time, but reporting is a gift for an improvement. If a misunderstanding then it’s motivation that my project is used and deserves a generous reply. This perspective and treating as strictly a hobby, rather than as a criticism or demand for work, makes OSS feel more sustainable.
Yeah the London ones were enormous back in the day. I seem to remember 100+ attendees. We only have a tenth of the population - so my expectations are appropriately "managed" :)
Haha, bold thread. I can understand the frustration as probably we all know this monkey business is too common - but I suspect that an open invitation to "name some names" is not probably not going to be a productive and useful as you might hope :)
My favourite PHP product at the moment is BookStack (https://www.bookstackapp.com/), a really good wiki. I run an instance for my family and it's great.
But there are loads of things. And I notice that many of the sites I like using...are built on well maintained PHP stacks.