I still love PHP. 23 years ago we created some encryption software for it and it is still going. I also run a PHP newsletter. There's still a strong community of people and whilst there are other languages which I also use (Python, Node.js) I still find myself gravitating towards PHP for fast and simple work
The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since the launch of PHP 5 and so it isn't as easy to understand from scratch as it used to be
PHP is a perfect example of how to undergo major transitions correctly.
In the time that it took Python to go from Python 2 to 3, PHP underwent 5.2 -> 5.3 and 5.6 -> 7.0. 5.3 changed how you write PHP in a fundamental way by introducing namespaces and PSR0 autoloading. Then, 5.6 -> 7.0 cleaned up the parser, resulting in massive speed improvements.
They did this by not breaking the universe in these major updates...or really, any of there updates. Each update would break a few specific things, warn you about a few other things that were going to break in the near future, while giving you ways to shim the old behavior if you _really_ needed it.
They also gave you ample carrots reasons to update - aside from what was already mentioned, my personal favorite update was PHP 5.4 because it introduced short array syntax, made UTF-8 the default charset, introduced traits, and finally put register globals and magic quotes out of their misery...but giving you a shim if you had some ancient project that needed it.
If you're wondering why PHP 6 was abandoned, it was because it was an update in the style of Python 3 by breaking strings everywhere. In retrospect, I think the decision to cancel 6 was the right one. Somehow, I doubt that PHP would've had the influx of data science and AI that saved Python 3.
Hats off to the project - I've long been off of the CGI-style web development narcotic, but the language put food on my table for quite some time, and the people steering the language treated their community well.
> They did this by not breaking the universe in these major updates
I don't think the amount of breakage per se was the problem with Python 3. I think the problem was that for a long time (until u"" strings in 3.3? four years after 3.0?) there was ~no way for a library to support both 2 and 3 in a single codebase. That meant that each project had to either maintain a fork, or do a "flag day" migration, which in practice meant you couldn't migrate until all your dependencies were migrated. Big mistake in retrospect.
I've seen a few other comments also talk about PHP becoming more complex. However, I have "simple" code built using 5.3 and it works perfectly fine in 8. So I guess it CAN be complex, but doesn't really need to be. The biggest changes I would make to that code are fixing the multiple 'switch' and 'if/else' blocks to an anonymous function or some mapping... but it's not required.
This is true. As long as only one person interacts with the code, all languages can be simple. C++ can be simple.
But once multiple people are involved and I have to read someone else's code, then I really start to appreciate languages with less features. There are some language I love to write code in, like Ruby or Haskell, where I feel like a damn genius when I write it, but want to pull my hair out when I have to read someone else's code.
I think PHP 8 is easy to understand if you write it from scratch, you just have to learn doing things the right way, read up on PSRs and so on. It is a bit more complex but much more secure and supports quite a lot of things now that are definitely helpful to have.
PHP's evolution since PHP 5 has been substantial, and I think this is a real problem. As someone who learned the language years ago, the pace of change (generics, attributes, match expressions, typed properties) makes modern codebases genuinely difficult to follow.
I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for the community but a barrier to re-entry.
IMO, newer PHP is still very readable. I programmed with C++ for a decade, but I can safely say that I cannot understand a modern C++ code base anymore.
The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.
> The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.
I'm glad it's not just me who finds the syntax of some of the new PHP features confusing and complicated. And it's not just this version either, they keep adding weird "sugar" in each new release.
People still complain about PHP saying how it is not secure at all, how shitty of a language it is, and so on, because they are stuck at PHP 5. Everyone should just start from PHP 8.
I have no clue what the future brings for PHP, but PHP 8 is definitely a good start, and we should put PHP 5 to rest.
PHP 10 might not be that different from PHP 8 for all I know.
We do not know if there will be "constant change". Out of curiosity, what programming language do you use that you also love?
FWIW, if by "constant change" you mean improvements or bug fixes, then I do not see why we should not have those. I do not even mind breaking backwards compatibility if the reasons for breaking justifies it, but it has to be a really good reason.
It gets updated but breaking changes are not that many and always well justified. Most breaking changes I've seen the past decade only broke if your code was already bad relying on non standard ways of using language features. There are tools that help with migration.
People also hate how _slowly_ Python moves and complained forever about that. They also complained forever during the many years of 5.x PHP releases that PHP was moving too slow. It was only after Facebook forked first the runtime (HHVM) and the language (Hacklang) and showed how fast and advanced PHP could be made that the PHP team started accelerating. Which I think has been a boon to the community. This is all given away for free as open-source after all.
It's a real problem with almost all software today, nothing ever gets done. they just keep piling unto it no matter how great it was. the idea of simplicity as a goal and feature is lost on this generation.
Simplicity may often get ignored but I think it's been a big reason for Python's success which has gone from about #10 on the TIOBE language list to #1 since when I started learning it, which was probably around when the XKCD "everything is so simple" cartoon came out. (https://xkcd.com/353/)
I think its the other way around. Python became the language of choice for AI because it was already popular. Lots of things made it popular: use for systems management scripts, web apps (Django, especially), then numerical stuff,...
I think the reason is that it is easy to learn enough to get things done, but it is very flexible, very readable, and once the ecosystem started gaining momentum (which it clearly had by the time of the XKCD cartoon) that became an advantage too.
I have been programming in python since the 90's too. The success IMO is still that it retains the simplicity and CFFI. Moving up TIOBE is more of CFFI and the ecosystem.
I dunno; I started with PHP 5 (actually, I think I started in late PHP 4), and I've only been happy with the changes as it's evolved.
The only one that's caused me any significant stress is the deprecation of the old `mysql` DB interface; I had to refactor a whole bunch of code for that, since I'm maintaining a codebase that's been in continuous use & development since 2001.
The additions to PHP since 5 add more things you can do, but they don't really change the simple things you can do to first learn PHP. You can still just create a .php file and start interspersing HTML and <?php script tags with basic operations.
To be fair, that’s true of many languages and programming domains. The web, in particular, is one where you have to keep pace or end up out of the field.
Java and C# are a couple other popular languages where the same is also true.
Most likely this can be said about a lot of languages, most languages are being maintained and improved. I am an hired expert in Java and I needed to explain some new languages features to some colleagues that have been introduced recently, I only mention them if they actually improve readability though.
I think PHP might be slightly different than other languages as a huge amount of people use this to create their first website as a hobby.
C hasn’t changed all that much, and someone who coded in C99 would take about 30mins to catch up to a modern C23 codebase’s changes. Famously so, as conservatism to change is the main friction in the community for about two decades now.
If you pull out examples of the earliest C, sure, it looks weird. But that C was already obsolete in 1989. Since then, it’s had a minor iteration (e.g. five-eight additions/modifications) every decade-ish (99, 11, 17, 23). Has it changed? Sure. Can it be compared to the iteration and speed of things like C#, Java, C++, etc? No way.
C, as a language, is very simple. Which leads to horribly complex and monsterous code, especially in large projects. The language makes even simple paradigms impossible to represent, forcing you, instead, to just remember what to do and then do that every time, forever.
I made no value judgement of the language. Simply an assessment of its simplicity. I’m glad you agree with that. Feel free to let the other commenters know, not me.
I am quite sure many people would fail Pub Quizzes related to C, when taking into account the whole language alongside compiler extensions, regardless of the compiler.
To learn all of the common GCC and MSVC extensions would make up a fraction of the language features of C# or Java. You’re really overstating the complexity to make some invalid point.
“Actually, one of the most notoriously conservative and simple (in feature set) languages is really super complex and has evolved a ton because it has _Generic and varargs now, and __packed__ exists as a compiler feature.”
And to further double down, that minor evolution is over 36 years (arguably a decade longer, but I’m being generous with your argument). Not the 12-16 years (depending which 5 point release you wanna start with) that PHP has morphed into an entirely different language.
A pub quizz would consider more than GCC and MSVC, and still I would bet many would fail if talking only about those two.
And I would double down on my bet regarding ISO C related questions, as I have met a few folks that contrary to myself as language nerd, hardly know what is written there or have even opened the PDF drafts at least once in their life.
It's moot to the aforementioned point. Undefined behavior wasn't introduced as a new language "feature" between C89 and C23; it's existed the whole time. We're talking about specification deltas, not the entire corpus.
But, if you want an answer to your question:
You can learn to avoid undefined behavior in about 30 seconds.
If you're purposefully fiddling with undefined behavior, it's because (ideally) you're A) an advanced developer and you know exactly what you're trying to achieve (and inspecting the generated code) and/or B) you're using a specific compiler and don't plan on porting your code elsewhere.
Before you could assume signed arithmetic overflow will be whatever the CPU does, or null pointer derefs will be trapped by the OS. That is pretty big difference from what can happen now, moved C away from that "portable assembler" moniker so very not moot. Even if it was never explicitly standardized.
> You can learn to avoid undefined behavior in about 30 seconds.
Source? I mean, if it's really that simple then someone already compiled that 30 second advice and you can simply link it here for us. Ideally including examples how to actually do signed arithmetic safely. You can't avoid negative numbers lol.
I think he's thinking more along the lines of PHP 5-8.5
That version 1-latest is understandingly highly different, but these are all decades old languages, which barely changed for some time, but are now all introducing new syntax.
Which I think makes sense, but it's obviously going to leave 9-5 devs behind that don't particularly care for coding and want to invest as little time as possible into their language knowledge.
A person that cares for coding will inevitably code more then 9-5 and consequently get familiar with new syntax
A person that invests time into their language knowledge will not have issues handling new syntax because they spend as much time as necessary to get familiar with the new syntax
So the criteria is being a 9-5 who doesn't particularly care about coding and doesn't invest time into their language knowledge
Not GP, but I assume the suggestion is that it's difficult to stay abreast of new developments within the constraints of a typical work day. Especially if your job utilises older technologies, as most do.
You can still write php 5-esque slop and have it run... mostly (some particulars like the half dozen ways of interpolating a variable into a string have been paired down, some extensions left in the dustbin, but the fundamental "shit out a script and run it" capability still remains doable).
non of the "modern" things are particularly taxing to teach someone with more than two braincells. If they don't understand them then they haven't kept up with ANY programming trends in the past decade and are best placed infront of the TV with an iPad than left to mess with the possible critical infrastructure of a business.
It has nothing to do with being “too hard”, and everything to do with not making sense to the type system. PHP is weakly-typed and heavily reflection-based (so everything is aware of it’s and each other’s type at all times).
Adding generics to PHP would make CS fundamentalists somewhat happy, but do nothing to change the fundamental design of PHP nor offer any of the traditional benefits that generics offer to strongly-typed and compiled languages. And would be a massive headache to implement, while bulking an already heavy VM implementation.
Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen.
> Adding generics to PHP would make CS fundamentalists somewhat happy
PHP has really only one collection datatype (the infamous array), so having generics would be tremendously useful, as an example you cant return an typed array from a function, witch is just really bad.
For an counter example, Python managed to do this, while also being a dynamic language, although having a stronger typing than PHP.
Python managed to do this by not actually checking the types at runtime. If you declare a list[int] return type but you return a list[string] then nothing happens, you're expected to prevent that by running an offline typechecker.
PHP chose to check types at runtime. To check that a value is really an array<int> the runtime could have to loop through the entire array. All the types PHP currently implements are simple and cheap to check. For more elaborate cases you need an offline checker like PHPstan and comment-based type annotations. (PHPstan catches 99% of issues before the runtime gets to it so for my own code I'd prefer the Python approach with its cleaner syntax.)
The runtime checking seems the key difference, not so much the historical strength of the type system. Python's language implementation does very little typechecking itself and PHP's third-party offline typecheckers are respectably advanced.
Precisely. PHP has tools for this too, but lack the syntax. Right now you need to to all typings in comments, and thats just as bad as jsdoc was in 2005.
This could be the way PHP could go, they just need the lexer to handle types, and not do any runtime checking at all.
But i guess that goes against what the php devs want, but it sounds so wasteful, to typecheck the same code time after time even if it passed some sort of initial "compile time step".
The current amount of typechecking might be a net efficiency improvement AFAIK. It provides a hard runtime guarantee that variables are certain types while Python has to check whether something is supported at the last possible moment. But I don't know how much use the optimizer makes of that.
Python is not (usually) run like PHP. Python programs (like most other languages) "run", compared to PHP where you in 99% of all cases instead "execute". (run = the program is running for a long period of time, and execute = run/die immediately).
This subtle difference has huge implications. You could in theory have an "compile step" in. Python, but in PHP you really cant as the program is never "running".
Python built syntax for types / generics etc. Its actually a quite capable typesystem (im not a python developer, but use python on some occasions). Python then has tools for static typechecking that can be run outside execution.
This means that if python would do actual static typechecking on runtime it would be nothing more than wasted cpu cycles.
Thats why python opted for the syntax only, as its basically zero cost. In php land the typechecking is done on EVERY execution, even if the code was unused. (a void functions that has an int param, but gets passed an string, that just discards the parameter). Even worse, a type error thats not executed wont be caught by every execution.
In short PHP typesystem is just runtime checks for primitives / classes and wont catch errors where not executed. Its like the worst of both worlds.
> you cant return an typed array from a function, witch is just really bad.
Why is it bad?
In particular, why is it worse than not being able to declare a typed array in your current scope? (I understand the basic argument in favor of typed arrays, but I also understand why PHP would choose not to go that route; I'm not sure I see how it's worse to not be able to return one from a function, given that they don't exist elsewhere.)
I often return some collection of types in an array eg [User, Config]. Right now my return type is just "array". To get this to work i need to build yet another wrapper class and all that, and thats just wasteful and totally unnecessary.
A even more simpler example is An array of some sort of Item. I cant return array(Item), but i only can return an array.
The parts thats not working is if i return a plain "array" i can then put whatever inside it. Its basically the same as "any" but wrapped inside an array.
But that is no different than if you created the array in that scope.
So, again: Why is it "really bad" that you can't return a typed array from a function? What is worse about that than not being able to create a typed array in the current scope?
Also: What, exactly, about that is "not working"? As I said above, I understand the basic arguments about typed arrays; they're conceptually equivalent to weak/dynamic types. And there is value in having strong and static types. But it's hardly a showstopper not to, and PHP works just fine even if you don't use any. It just...makes it easier for us, as programmers, to make mistakes.
So to say it's "not working" simply because it's possible to add elements to the array that don't match the types you want seems like an exaggeration.
PHP typing is most definitely stronger than python overall.
Yes array is the evil collection type of everything, but that's how it's meant to work. Array is the quick and dirty 'throw everything in there' thing. PHP has classes and they're very full featured and offer lots of type safety - use those.
I mean from a static analysis perspective - type annotations in PHP actually do stuff, and you can type annotate pretty much everything. And people actually do it.
Also, you can just flip on strict typing in PHP, and you should know that.
Strict types determine whether a function accepts a variable of a certain type, casts it, or throws a TypeError. It does not affect int + string operations or anything else really
Kind of but not really. Even without strict types, functions will throw a type error if you give them the wrong thing for almost all types, except primitives, which will be automatically coerced. Strict types turns that coercion off.
Really, that's probably enough for a lot of cases, because PHP doesn't have operator overloading. Yes, you can add '10' + 10 and get 20, but not if either of those go into any function. If you have a function that needs to do string stuff, you take string stuff in, and you don't have to worry about string operations or coercing ints or anything.
You are probably talking about this: https://stitcher.io/blog/generics-in-php-3 . If I remember correctly, the author claims it will either cause runtime overhead or extreme memory overhead. The best solution is to introduce a typed superset of PHP like TypeScript was done for JavaScript.
TLDR: The PHP compiler isn't really suited for the job, it would introduce a lot of complexity to an already complex codebase and the memory/performance hit would be substantial.
Yup, this was pretty much what i recalled. The typesystem, while being incredibly "unintelligent", somehow still is so complex that generics are not going to happen.
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.
A lot of C# and Java code is oriented towards web backends, too. Which are quite big and complex. So it seems natural that languages in the same design space (trad OO) converge on similar features. I think the only exception these days is Go.
I think these days you could change "You can write Fortran in any language" to "You can structure your code like Spring in any language"…
I don't see how making a language more complex can help with that. Complex languages makes sense for system programming where you want to squeeze some performance.
Still, even if it was "just" the web, why wouldn't it evolve? It's a great language, with a big user base, and there's always room for improvements and to increase the developer experience
I downvoted you before reading the fine article. I'm back to correct that.
The new array_first() and array_last() functions are nice, everything else is either reimplantation of existing features or "features"which will make maintainability more difficult. The pipe operator is one such example. I don't need it - these nested methods are not really an issue in any codebase I've seen. The new syntax only works for unary functions, so higher arity functions must be wrapped in an arrow function. It's a mess and more bug prone than just nesting the functions.
Many of the newer features have this problem. Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
Meanwhile it seemingly abandoned features and unique selling points, like the in-built templating, associative arrays with value semantics and the fact that it integrates well with C or the simple fact that it can be used to write web server scripts very easily. To me, many of these cool features have been largely ignored or even moved away from.
>Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
The problem is that the php project is maintained by (mostly) unsponsored contributors. There’s not a giant corporation behind it. Each of these new features are designed by a couple people (per rfc) and then discussed and voted by other contributors. The match keyword, for example, is consider as the future scope of this rfc which is still being worked on: https://wiki.php.net/rfc/pattern-matching
Also, a lot of these half baked features are designed to be implemented in steps because of what I said in my other paragraph and to increase the odds of being accepted (it’s well known that it’s hard to get an rfc accepted and a lot of good ones haven’t been able to pass the voting phase).
When you consider this, it’s amazing that we get so much from so little.
I don't understand how this is more bug prone. The nesting is a HUGE problem because it's extremely unreadable. The arrow is much more readable, and array functions are very simple too.
How many tubes does that appear in any codebase you've worked on? Those types of constructions are typically hidden away in "helper functions" that are straightforward to understand and debug. They are certainly not typical in business logic.
Now we have two syntax to be familiar with and maintain. And you just know the clowns are going to come along and convert one syntax to the other because they can, which completely ruins the git commit and you can't tell what actual functionally was changed at a glance. There will be bickering and bikeshedding about "modernizing" codebases.
I don't know, I think it's really fine. It's very typical to compose a bunch of array functions together and, honestly, I think that's good form most of the time. This makes that a little bit easier.
I'm sort of on the opposite side. I'm unconvinced by extra functions for arrays in the global namespace and I'm happier about syntactic improvements and debugging improvements.
That is an anti-pattern, since it suffers from shell meta-character injection (and argument injection). Since PHP has mkdir, you should use that instead. And pcntl_exec() is the correct API for running processes.
Typical users of this likely don't care the slightest about whether anyone considers it an anti-pattern, because you use those in order to write utility scripts. And those who care would use tooling to detect issues like that anyways.
Yeah, doing things wrong happens quite often. Especially for the meta-character injection issue. Personally I think language designers should deprecate and remove backticks and other shell-executing features from all languages.
Parse_url isn't standards compliant, often fails with relative url's and most importantly only parses urls, not uris (with the exception of file://). I also find it's syntax clunkier than the new uri(), but that's just personal preference.
The pipe operator is indeed just syntactical sugar (and the article links to another article specifically about it which does cover the case of temporary variables), but with the coming partial function application feature it (in my opinion) will make easier to read/reason chains of code than temporary variables or nested function calls.
parse_url() also had no generate_url() counterpart - sure, it could (sometimes) split a URL into its components, but there was no safe way to modify those components and glue them back into a string. The new URI class solves that.
Adding new functions and alternative syntax has a long-term cost for PHP and the projects that use the language. I don't see much value in the new features of PHP5 announced on https://www.php.net/releases/8.5/en.php
- URI extension: there was already the internal `parse_url()` which was imperfect, and alternative libraries that were RFC 3986 compliant. An official extension will bring speed, but now there will be 2 official ways to parse URLs.
- The pipe operator is a matter of taste. In the release notes, the new code is more verbose, because it defines anonymous functions. This alternative syntax means keeping a consistent code style will be harder.
- The update of "clone" replaces 2 lines of code in some cases. Unless I misunderstood, it's a very minor change.
- The #Discard/void will replace the similar feature from static analyzers.
- Closures in constants is one of the 2 features that bring more than an alternative syntax. It's one more little step toward a preprocessor. But I'm not thrilled about the future #attributes assigned with complex closures.
- cURL persistent handles are a real performance feature, because curl_init() is costly.
- array_first() is a minor syntax-sugar. In a project of 100k+ lines of PHP, I probably could use it twice or thrice. Was it worth a global function?
if they was something to learn it was for the Ruby community to learn from the PHP community on how to reinvent itself.
PHP like Ruby had some big companies built on it - Facebook: PHP, Ruby: Github/Shopify
PHP was able to swallow Hack and become PHP8 - they optimized for getting beginners into the language / ecosystem
Ruby while a beautiful / friendly language and ecosystem - got into political wars - didn't optimize for beginners on windows etc
even as a person who favors Rails - Laravel is ahead -> on documentation & bringing various ways to do things into the framework. There's no stick with Hotwire. You wanna do livewire go ahead, we will help you. You wanna do Inertia + JS - go ahead we will help you.
PHP should REALLY focus on getting the core stuff in shape.
Its still so annoying that you have to use mb_real_uppercase($name) for unicode. The other gripe is that the stdlib is SO messy. With PHP 5.3 they had a once in a lifetime opportunity to cleanup the stdlib and introduce a new namespaced API for builtins, and optionally introduce a uniform function call syntax:
"foo"->strtoupper();
Whenever doing PHP the time for concurrency will come sooner or later. Having no way of doing ANY concurrency is a letdown. The Fiber API does nothing on its own, and you are forced to use some third party runtime, that is usually a non-starter for legacy projects.
PHP has come a long way from the PHP 4.0 era, but is still lacking in multiple areas, and i dont see it being a pick for greenfield projects in 2025.
Just looked at Laravel, and it feels like its trying its hardest to lipstick the PHP warts. When i look at a framework like it i see just bloat. You really only need like 5-10% of stuff thats there. Thats why its most likely slow and heavy, and looks like it was cowboy copied from some legacy .NET enterprisey framework from the early 2010s.
Jobs? Sure. There are PHP jobs, and the PHP devs are a dime a dozen. But i will agree with you, Laravel is a fine pick for websites, but not so much for more real world, high load applications.
Theres also 100x more jobs for WordPress than Laravel, so if you want to do PHP, i suggest going the WordPress route instead.
That’s a strange thing to say. If I wasn’t self employed, I’d pick the job that pays more (Laravel) instead of the job that (according to you) is 100x more available.
And who really cares about bloat anyway? Hardware is super cheap nowadays. People are expensive. So why not use a framework that enables you to be (in your terms) 100x more productive?
On top of that, you’re arguing about languages and frameworks you’re not even familiar with. Why does your opinion matter at all?
> And who really cares about bloat anyway? Hardware is super cheap nowadays.
That told me all i need to know. When you work on missing critical software bloat is usually THE killer in disguise. And its really hard to get rid of after a certain point.
> So why not use a framework that enables you to be (in your terms) 100x more productive?
Because i can be just as productive, and even more so by vetting, and choosing my dependencies with some hindsight. I dont cowboy pick some hype of the day thing, i take a real close look at the code and want to actually understand whats happening.
> On top of that, you’re arguing about languages and frameworks you’re not even familiar with.
I am indeed familiar with the PHP ecosystem, been there and done that.
As for concurrency/async, it's possible to do requests in parallel with curl_multi_*. Other async/prallel things are also possible, but tend to be more complicated compared to JS or other languages with promise and async support.
Your second option was rejected years ago I believe. The pipes were designed to work alongside this rfc that was supposed to be in this new version (8.5) but due to time constraints it had to be delayed and it’s currently being voted https://wiki.php.net/rfc/partial_function_application_v2
One of the things I have noticed in languages is that after some iterative evolution the piled on features and syntaxis sugar make them look bizarre and hard to read. Probably the weight of backwards compatibility and that the initial paradigms have picked up the easy to understand real estate. And there are no good ways of getting out of the corner you have coded yourself in.
Probably because compile/interpret is one way street. There is no way to lets say view/transform a part of the code in functional or imperative depending on what you need to do with it.
Reading modern php or even worse mixed generations code base feels like another full time job on top of the regular one - coding with it.
Why is it that all these languages like PHP, but also typescript are becoming like impossible puzzles to read. I find these generics, types and other language features very often causing complex software architecture. I see so many collegues these days struggling in understanding codebases. You almost need a PHD brain to be a frontend web developer.
I assume it is some inferiority complex, on many sides. PHP itself was laughed at being too simple, underpowered and inconsistent, now they overcorrected with types, annotations and breaking backwards compatibility with every release so that no old code base can remain intact. Frontend devs yearned to be regarded as real developers, which in their context means construction of unwieldly and overcomplex enterprise bullshit, thus typescript etc. And in the backend you have that same mechanism, devs having to prove they are no beginners and thus using (wrongly) design patterns, instructed by software architects, instead of avoiding abstraction and thus complexity.
Can you share an example of what you're talking about in PHP 8.5? On the linked web page, the only code pattern that looks remotely complicated to me is the following:
#[SkipDiscovery(static function (Container $container): bool {
return ! $container->get(Application::class) instanceof ConsoleApplication;
})]
final class BlogPostEventHandlers
{ /\* … \*/ }
Is PHP still unhelpful when it comes to writing secure code?
I remember when escaping SQL input data was "the correct way" to use your mysql database. Parametrization? Nah, just use mysql_escape_string or whatever it was called.
php has kept around a lot of functionality that can be misused, but PDO has had parameterization since forever and is the go to method if you want to connect to a database. Beyond that though, most PHP projects at this point are likely using a query builder/orm like eloquent.
So I guess it depends on what you mean by unhelpful. PHP as a language makes it pretty easy to do bad stuff. PHP as a community makes it easy to Do The Right Thing.
Prepared statements have been available in PHP for over 20 years, when it deprecated the old mysql libraries. They were removed entirely in PHP 7.
And let's be real - most handwritten SQL code in existence in most languages just builds queries from concatenated strings, even when more secure options exist. A lot of code doesn't even bother to escape anything. That's not a language problem so much as a developer laziness and assumption that "simplicity always equals correctness and frameworks are always wrong" problem.
I remember the discussions at the time about which filename extension to use - and I can not believe that .php3 won. I think that I was the first to bring up the subject for PHP 4, to use .php again and not include the version number.
It seems that pipe operator was introduced largely because PHP arrays and strings don't have "methods". You can't write something in "OOP" style: "some_string"->str_replace("some", "replacement")->strtoupper(). With PHPs array / string procedural way writing such chains is much bulkier. Pipe operator will somewhat reduce the boilerplate, but the native "OOP" style is still much better.
Although there is a proposal for adding "methods" but I don't remember the link.
I'm not a blind PHP hater, but it seems like PHP community members sometimes celebrate new PHP features when their equivalents have been there for many years in other programming languages. https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab...
No, the OOP style isn't better. The set of functions one can use in OOP is closed.
Imagine I want to AfD a custom string function for a feature which uPpErCaSeS every second letter as I need that for some purpose: I can't do in OOP style.
In OOP I could extend the string class, but most other parts of the code won't magically use my string type now.
Thus I have to create a free standing function for this (which probably also is better as I don't need internal state of thee object, thus livingnoutisde is good for encapsulation)
And thus my string function works different from other string functions.
my_casing($string->trim())->substr(3);
(The example of course is non sensical and could be reordered, but we argue syntax)
Having them all be simple functions makes it equal.
Of course there are alternative approaches. C++ argues for years about "uniform call syntax" which would always allow "object style" function calls, which could also find non-memwbr functions where the first argument is of compatible type, but such a thing requires stricter (or even static) typing, this won't work in PHP.
What do you mean developers should deal with functions like those? They're used when necessary, yes, just like any function. And no IDE is required. I'm really puzzled.
Either working with PHP for 21 years is not long enough or simply too long. I honestly think these small inconsistencies are irrelevant in the big picture of building something complex. Like you said, programmers should deal with them. It just doesn't sound like a big deal.
> I honestly think these small inconsistencies are irrelevant in the big picture of building something complex.
Big picture is PHP is a poor tool. I enumerated only one annoyance about writing software on PHP, 80% of all websites on the web being built on it doesn't make it any better. Some companies keep building on it, because:
1. They started writing the codebase in PHP, now they are "locked" (cost of switching to another language is extremely high)
2. Hiring PHP developers usually costs a lot less (at least 20%) than say Java/Python developers
People keep arguing that, for seasoned developers it doesn't matter what tool one chooses. Then what is the point of choosing a tool over another, if you gotta check the docs constantly for inconsistencies? (I'm sorry, you gotta use IDE anyways)
With that said, there is no ideal language, however PHP is single most annoying language after JavaScript.
Such a change makes it a completely different language with no compatibility. Thus all previous code is lost, no easy migration paths (especially for libraries which would like to support both during transition)
Would it though? I’ve been thinking about this for a while.
What about introducing a new file extension for this? Something like MyClass.p so that .php is for classic syntax and .p Can support newer syntax? You could support old codebases while at the same time support better syntax.
It’s probably too much for the core php team to maintain both though
I think php should have stopped at php4 or php5 and maybe just develop a new/sane standard library.
And a new language could have been developed , call it hack or whatever Facebook tried. Anyway I remember php coding gave me headaches. Tried it again 2 years ago and found out the same kind of issues(outdated /inexistent documentation, different ways to do the same thing that actually didn’t work and stuff like that). Try to connect to sql database using ssl and see what I mean.
I see no reason to learn PHP anymore or start up your company using php.
We live in a vps/docker age. The advantage of php hosts everywhere has been lost.
Without specifics it's hard to understand what kind of difficulties you had.
But PHP is still so strong because it offers much more than "easy hosting".
What I personaly love most is the instant save file->see results feedback loop. There's no perceptible compilation step. Meanwhile my Java project takes a minute to compile.
Also the shared-nothing model by default is powerful and rare.
Laravel is probably the most well documented frameworks even comparing frameworks from other languages. And symfony, also a PHP framework, is not far from that.
When you say "SSL" I can only think your reasoning is based on outdated information since no one calls it SSL anymore. It's TLS for some years now. And I have been connecting to databases using PHP TLS/SSL since version 5. For almost a decade now.
I still love PHP. 23 years ago we created some encryption software for it and it is still going. I also run a PHP newsletter. There's still a strong community of people and whilst there are other languages which I also use (Python, Node.js) I still find myself gravitating towards PHP for fast and simple work
The only issues I have. is that this is a 'double edged sword' in that PHP has become far more complex since the launch of PHP 5 and so it isn't as easy to understand from scratch as it used to be
PHP is a perfect example of how to undergo major transitions correctly.
In the time that it took Python to go from Python 2 to 3, PHP underwent 5.2 -> 5.3 and 5.6 -> 7.0. 5.3 changed how you write PHP in a fundamental way by introducing namespaces and PSR0 autoloading. Then, 5.6 -> 7.0 cleaned up the parser, resulting in massive speed improvements.
They did this by not breaking the universe in these major updates...or really, any of there updates. Each update would break a few specific things, warn you about a few other things that were going to break in the near future, while giving you ways to shim the old behavior if you _really_ needed it.
They also gave you ample carrots reasons to update - aside from what was already mentioned, my personal favorite update was PHP 5.4 because it introduced short array syntax, made UTF-8 the default charset, introduced traits, and finally put register globals and magic quotes out of their misery...but giving you a shim if you had some ancient project that needed it.
If you're wondering why PHP 6 was abandoned, it was because it was an update in the style of Python 3 by breaking strings everywhere. In retrospect, I think the decision to cancel 6 was the right one. Somehow, I doubt that PHP would've had the influx of data science and AI that saved Python 3.
Hats off to the project - I've long been off of the CGI-style web development narcotic, but the language put food on my table for quite some time, and the people steering the language treated their community well.
> They did this by not breaking the universe in these major updates
I don't think the amount of breakage per se was the problem with Python 3. I think the problem was that for a long time (until u"" strings in 3.3? four years after 3.0?) there was ~no way for a library to support both 2 and 3 in a single codebase. That meant that each project had to either maintain a fork, or do a "flag day" migration, which in practice meant you couldn't migrate until all your dependencies were migrated. Big mistake in retrospect.
> I don't think the amount of breakage per se was the problem with Python 3.
The lack of u"" is just another manifestation of the complete breakage they wrought upon Python's string handling, isn't it?
It was closer to a decade (3.7) till they'd put enough of the bits they'd ripped out back in for Py3 to be suitable for the things I used Py2 for.
I've seen a few other comments also talk about PHP becoming more complex. However, I have "simple" code built using 5.3 and it works perfectly fine in 8. So I guess it CAN be complex, but doesn't really need to be. The biggest changes I would make to that code are fixing the multiple 'switch' and 'if/else' blocks to an anonymous function or some mapping... but it's not required.
This is true. As long as only one person interacts with the code, all languages can be simple. C++ can be simple.
But once multiple people are involved and I have to read someone else's code, then I really start to appreciate languages with less features. There are some language I love to write code in, like Ruby or Haskell, where I feel like a damn genius when I write it, but want to pull my hair out when I have to read someone else's code.
> 23 years ago we created some encryption software for it
ZEND?
I remember "nulling" software in the mid-00's and Zend was always a terrible ball-ache.
Which, if that was your project, is high praise. :)
I think PHP 8 is easy to understand if you write it from scratch, you just have to learn doing things the right way, read up on PSRs and so on. It is a bit more complex but much more secure and supports quite a lot of things now that are definitely helpful to have.
PHP's evolution since PHP 5 has been substantial, and I think this is a real problem. As someone who learned the language years ago, the pace of change (generics, attributes, match expressions, typed properties) makes modern codebases genuinely difficult to follow.
I suspect this affects many developers who cut their teeth on PHP but haven't kept up. The language has become a different beast, which is a strength for the community but a barrier to re-entry.
IMO, newer PHP is still very readable. I programmed with C++ for a decade, but I can safely say that I cannot understand a modern C++ code base anymore.
Are the new features really readable? I have no idea what this code from the OP is meant for:
As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#". See https://wiki.php.net/rfc/closures_in_const_exprThe examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.
Given that the cat effectively is out of the bag, does the example on the release page (sneak preview) make more sense to you: https://www.php.net/releases/8.5/en.php#closures-in-const-ex...?
> As a side note, even PHP's official wiki cannot highlight correctly the multiline attributes behind a "#"
Yes, unfortunately the off-the-shelf software of the Wiki uses a custom-built highlighter instead of the `highlight_string()` function that is bundled with PHP: https://www.php.net/manual/en/function.highlight-string.php
> The examples in TFA are terrible and I don't get why it was necessary to jump the gun by submitting that article instead of actually waiting for the release and the official release page with more carefully designed examples.
Clout.
I'm glad it's not just me who finds the syntax of some of the new PHP features confusing and complicated. And it's not just this version either, they keep adding weird "sugar" in each new release.
I think PHP is way better now than it used to be. Learn PHP 8 and you are good to go.
Until two years later the same thing is said about PHP 9, 10, 11. Constant change is not good.
People still complain about PHP saying how it is not secure at all, how shitty of a language it is, and so on, because they are stuck at PHP 5. Everyone should just start from PHP 8.
I have no clue what the future brings for PHP, but PHP 8 is definitely a good start, and we should put PHP 5 to rest.
PHP 10 might not be that different from PHP 8 for all I know.
We do not know if there will be "constant change". Out of curiosity, what programming language do you use that you also love?
FWIW, if by "constant change" you mean improvements or bug fixes, then I do not see why we should not have those. I do not even mind breaking backwards compatibility if the reasons for breaking justifies it, but it has to be a really good reason.
It gets updated but breaking changes are not that many and always well justified. Most breaking changes I've seen the past decade only broke if your code was already bad relying on non standard ways of using language features. There are tools that help with migration.
People also hate how _slowly_ Python moves and complained forever about that. They also complained forever during the many years of 5.x PHP releases that PHP was moving too slow. It was only after Facebook forked first the runtime (HHVM) and the language (Hacklang) and showed how fast and advanced PHP could be made that the PHP team started accelerating. Which I think has been a boon to the community. This is all given away for free as open-source after all.
It's a real problem with almost all software today, nothing ever gets done. they just keep piling unto it no matter how great it was. the idea of simplicity as a goal and feature is lost on this generation.
Simplicity may often get ignored but I think it's been a big reason for Python's success which has gone from about #10 on the TIOBE language list to #1 since when I started learning it, which was probably around when the XKCD "everything is so simple" cartoon came out. (https://xkcd.com/353/)
Doubtful it is anything to do with simplicity.
Python's success is explained by it being the language of choice for AI.
Python has been massive since the 2000s. When AI rolled around, it was already there, a bunch of people knew it, and it was Good Enough (tm).
I think its the other way around. Python became the language of choice for AI because it was already popular. Lots of things made it popular: use for systems management scripts, web apps (Django, especially), then numerical stuff,...
I think the reason is that it is easy to learn enough to get things done, but it is very flexible, very readable, and once the ecosystem started gaining momentum (which it clearly had by the time of the XKCD cartoon) that became an advantage too.
I have been programming in python since the 90's too. The success IMO is still that it retains the simplicity and CFFI. Moving up TIOBE is more of CFFI and the ecosystem.
I dunno; I started with PHP 5 (actually, I think I started in late PHP 4), and I've only been happy with the changes as it's evolved.
The only one that's caused me any significant stress is the deprecation of the old `mysql` DB interface; I had to refactor a whole bunch of code for that, since I'm maintaining a codebase that's been in continuous use & development since 2001.
The additions to PHP since 5 add more things you can do, but they don't really change the simple things you can do to first learn PHP. You can still just create a .php file and start interspersing HTML and <?php script tags with basic operations.
but would you even be considering re-entry if it hadn't improved dramatically?
To be fair, that’s true of many languages and programming domains. The web, in particular, is one where you have to keep pace or end up out of the field.
Java and C# are a couple other popular languages where the same is also true.
Most likely this can be said about a lot of languages, most languages are being maintained and improved. I am an hired expert in Java and I needed to explain some new languages features to some colleagues that have been introduced recently, I only mention them if they actually improve readability though. I think PHP might be slightly different than other languages as a huge amount of people use this to create their first website as a hobby.
This is true for most languages though, compare C# 14 with C# 1.0, Java 25 with Java 1.0, C 23 (plus common compiler extensions) with K&R C,....
C hasn’t changed all that much, and someone who coded in C99 would take about 30mins to catch up to a modern C23 codebase’s changes. Famously so, as conservatism to change is the main friction in the community for about two decades now.
If you pull out examples of the earliest C, sure, it looks weird. But that C was already obsolete in 1989. Since then, it’s had a minor iteration (e.g. five-eight additions/modifications) every decade-ish (99, 11, 17, 23). Has it changed? Sure. Can it be compared to the iteration and speed of things like C#, Java, C++, etc? No way.
C, as a language, is very simple. Which leads to horribly complex and monsterous code, especially in large projects. The language makes even simple paradigms impossible to represent, forcing you, instead, to just remember what to do and then do that every time, forever.
I made no value judgement of the language. Simply an assessment of its simplicity. I’m glad you agree with that. Feel free to let the other commenters know, not me.
I am quite sure many people would fail Pub Quizzes related to C, when taking into account the whole language alongside compiler extensions, regardless of the compiler.
To learn all of the common GCC and MSVC extensions would make up a fraction of the language features of C# or Java. You’re really overstating the complexity to make some invalid point.
“Actually, one of the most notoriously conservative and simple (in feature set) languages is really super complex and has evolved a ton because it has _Generic and varargs now, and __packed__ exists as a compiler feature.”
And to further double down, that minor evolution is over 36 years (arguably a decade longer, but I’m being generous with your argument). Not the 12-16 years (depending which 5 point release you wanna start with) that PHP has morphed into an entirely different language.
A pub quizz would consider more than GCC and MSVC, and still I would bet many would fail if talking only about those two.
And I would double down on my bet regarding ISO C related questions, as I have met a few folks that contrary to myself as language nerd, hardly know what is written there or have even opened the PDF drafts at least once in their life.
[flagged]
It definitely is, because we are discussing knowledge of programming languages specification across their whole lifetime.
[flagged]
Yeah, it does not take a long time to learn GCC / Clang extensions, IMO. Have an LLM give you a list of these with examples, really. :P
You can learn everything about undefined behavior in 30mins?
It's moot to the aforementioned point. Undefined behavior wasn't introduced as a new language "feature" between C89 and C23; it's existed the whole time. We're talking about specification deltas, not the entire corpus.
But, if you want an answer to your question:
You can learn to avoid undefined behavior in about 30 seconds.
If you're purposefully fiddling with undefined behavior, it's because (ideally) you're A) an advanced developer and you know exactly what you're trying to achieve (and inspecting the generated code) and/or B) you're using a specific compiler and don't plan on porting your code elsewhere.
Before you could assume signed arithmetic overflow will be whatever the CPU does, or null pointer derefs will be trapped by the OS. That is pretty big difference from what can happen now, moved C away from that "portable assembler" moniker so very not moot. Even if it was never explicitly standardized.
> You can learn to avoid undefined behavior in about 30 seconds.
Source? I mean, if it's really that simple then someone already compiled that 30 second advice and you can simply link it here for us. Ideally including examples how to actually do signed arithmetic safely. You can't avoid negative numbers lol.
Before you could assume...null pointer derefs will be trapped by the OS
Before when?
(system hangs)In DOS you always had to manage your expectations, not sure what you're trying to prove here?
[flagged]
Hey can you please not cross into personal attack? We're trying for something else here, and you can make your substantive points without that.
https://news.ycombinator.com/newsguidelines.html
I think he's thinking more along the lines of PHP 5-8.5
That version 1-latest is understandingly highly different, but these are all decades old languages, which barely changed for some time, but are now all introducing new syntax.
Which I think makes sense, but it's obviously going to leave 9-5 devs behind that don't particularly care for coding and want to invest as little time as possible into their language knowledge.
And what exactly 9-5 has to do with caring for coding or time investment in language learning?
A person that cares for coding will inevitably code more then 9-5 and consequently get familiar with new syntax
A person that invests time into their language knowledge will not have issues handling new syntax because they spend as much time as necessary to get familiar with the new syntax
So the criteria is being a 9-5 who doesn't particularly care about coding and doesn't invest time into their language knowledge
Not GP, but I assume the suggestion is that it's difficult to stay abreast of new developments within the constraints of a typical work day. Especially if your job utilises older technologies, as most do.
I work on projects from PHP 5.6-8.4 and I can't say it feels that different. It's mostly just type differences.
But PHP 5 was released 21 years ago and is unsupported. Companies using it are putting their customers at risk.
I used laracasts.com plus AI code assistants to bring myself back up to speed pretty quickly.
Wasn't AI meant to disenfranchise? https://news.ycombinator.com/item?id=45994928
You can still write php 5-esque slop and have it run... mostly (some particulars like the half dozen ways of interpolating a variable into a string have been paired down, some extensions left in the dustbin, but the fundamental "shit out a script and run it" capability still remains doable).
non of the "modern" things are particularly taxing to teach someone with more than two braincells. If they don't understand them then they haven't kept up with ANY programming trends in the past decade and are best placed infront of the TV with an iPad than left to mess with the possible critical infrastructure of a business.
PHP has no generics? I read somewhere that is was "too hard" to get right in PHP land, mostly because of how primitive the typesystem is.
It has nothing to do with being “too hard”, and everything to do with not making sense to the type system. PHP is weakly-typed and heavily reflection-based (so everything is aware of it’s and each other’s type at all times).
Adding generics to PHP would make CS fundamentalists somewhat happy, but do nothing to change the fundamental design of PHP nor offer any of the traditional benefits that generics offer to strongly-typed and compiled languages. And would be a massive headache to implement, while bulking an already heavy VM implementation.
> And would be a massive headache to implement
Exactly. The type system was never built for anything even slightly more complex. Its basically annotations for primitive types and classes. PHP has always had an weak type system, so adding generics will most likely never happen.
> Adding generics to PHP would make CS fundamentalists somewhat happy
PHP has really only one collection datatype (the infamous array), so having generics would be tremendously useful, as an example you cant return an typed array from a function, witch is just really bad.
For an counter example, Python managed to do this, while also being a dynamic language, although having a stronger typing than PHP.
Python managed to do this by not actually checking the types at runtime. If you declare a list[int] return type but you return a list[string] then nothing happens, you're expected to prevent that by running an offline typechecker.
PHP chose to check types at runtime. To check that a value is really an array<int> the runtime could have to loop through the entire array. All the types PHP currently implements are simple and cheap to check. For more elaborate cases you need an offline checker like PHPstan and comment-based type annotations. (PHPstan catches 99% of issues before the runtime gets to it so for my own code I'd prefer the Python approach with its cleaner syntax.)
The runtime checking seems the key difference, not so much the historical strength of the type system. Python's language implementation does very little typechecking itself and PHP's third-party offline typecheckers are respectably advanced.
Precisely. PHP has tools for this too, but lack the syntax. Right now you need to to all typings in comments, and thats just as bad as jsdoc was in 2005.
This could be the way PHP could go, they just need the lexer to handle types, and not do any runtime checking at all.
But i guess that goes against what the php devs want, but it sounds so wasteful, to typecheck the same code time after time even if it passed some sort of initial "compile time step".
The current amount of typechecking might be a net efficiency improvement AFAIK. It provides a hard runtime guarantee that variables are certain types while Python has to check whether something is supported at the last possible moment. But I don't know how much use the optimizer makes of that.
Python is not (usually) run like PHP. Python programs (like most other languages) "run", compared to PHP where you in 99% of all cases instead "execute". (run = the program is running for a long period of time, and execute = run/die immediately).
This subtle difference has huge implications. You could in theory have an "compile step" in. Python, but in PHP you really cant as the program is never "running".
Python built syntax for types / generics etc. Its actually a quite capable typesystem (im not a python developer, but use python on some occasions). Python then has tools for static typechecking that can be run outside execution.
This means that if python would do actual static typechecking on runtime it would be nothing more than wasted cpu cycles.
Thats why python opted for the syntax only, as its basically zero cost. In php land the typechecking is done on EVERY execution, even if the code was unused. (a void functions that has an int param, but gets passed an string, that just discards the parameter). Even worse, a type error thats not executed wont be caught by every execution.
In short PHP typesystem is just runtime checks for primitives / classes and wont catch errors where not executed. Its like the worst of both worlds.
> Right now you need to to all typings in comments
What do you mean by this? The types of variables in PHP >8 are not in comments. Or did I misunderstand something?
> you cant return an typed array from a function, witch is just really bad.
Why is it bad?
In particular, why is it worse than not being able to declare a typed array in your current scope? (I understand the basic argument in favor of typed arrays, but I also understand why PHP would choose not to go that route; I'm not sure I see how it's worse to not be able to return one from a function, given that they don't exist elsewhere.)
I often return some collection of types in an array eg [User, Config]. Right now my return type is just "array". To get this to work i need to build yet another wrapper class and all that, and thats just wasteful and totally unnecessary.
A even more simpler example is An array of some sort of Item. I cant return array(Item), but i only can return an array.
What do you mean, "to get this to work"? It's a PHP array. It will return whatever you need it to.
What is not working?
The parts thats not working is if i return a plain "array" i can then put whatever inside it. Its basically the same as "any" but wrapped inside an array.
Sure.
But that is no different than if you created the array in that scope.
So, again: Why is it "really bad" that you can't return a typed array from a function? What is worse about that than not being able to create a typed array in the current scope?
Also: What, exactly, about that is "not working"? As I said above, I understand the basic arguments about typed arrays; they're conceptually equivalent to weak/dynamic types. And there is value in having strong and static types. But it's hardly a showstopper not to, and PHP works just fine even if you don't use any. It just...makes it easier for us, as programmers, to make mistakes.
So to say it's "not working" simply because it's possible to add elements to the array that don't match the types you want seems like an exaggeration.
PHP typing is most definitely stronger than python overall.
Yes array is the evil collection type of everything, but that's how it's meant to work. Array is the quick and dirty 'throw everything in there' thing. PHP has classes and they're very full featured and offer lots of type safety - use those.
> PHP typing is most definitely stronger than python overall.
LOL, no its not. PHP has an weak type system, while python is strong. Both are dynamic.
I mean from a static analysis perspective - type annotations in PHP actually do stuff, and you can type annotate pretty much everything. And people actually do it.
Also, you can just flip on strict typing in PHP, and you should know that.
Strict types determine whether a function accepts a variable of a certain type, casts it, or throws a TypeError. It does not affect int + string operations or anything else really
Kind of but not really. Even without strict types, functions will throw a type error if you give them the wrong thing for almost all types, except primitives, which will be automatically coerced. Strict types turns that coercion off.
Really, that's probably enough for a lot of cases, because PHP doesn't have operator overloading. Yes, you can add '10' + 10 and get 20, but not if either of those go into any function. If you have a function that needs to do string stuff, you take string stuff in, and you don't have to worry about string operations or coercing ints or anything.
You are probably talking about this: https://stitcher.io/blog/generics-in-php-3 . If I remember correctly, the author claims it will either cause runtime overhead or extreme memory overhead. The best solution is to introduce a typed superset of PHP like TypeScript was done for JavaScript.
If you're interested about generics in PHP, you can read this blog post by the PHP foundation: https://thephp.foundation/blog/2024/08/19/state-of-generics-... or this PR by Nikita: https://github.com/PHPGenerics/php-generics-rfc/issues/45.
TLDR: The PHP compiler isn't really suited for the job, it would introduce a lot of complexity to an already complex codebase and the memory/performance hit would be substantial.
Yup, this was pretty much what i recalled. The typesystem, while being incredibly "unintelligent", somehow still is so complex that generics are not going to happen.
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.
> I think the danger with PHP is more its ability to easily cause very bad things.
Is there any language where you can't?
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.
Probably not, but not most languages are not inviting to do them.
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:
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.
This.
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.
$array = ['apple', 'pear']; @list($mainFruit, $secondaryFruit, $tertiaryFruit);
Since I suppress the warning that would occur due to the third member not being present, the program will continue executing instead of halting.
> 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 miss doing drive-by SQL injection attacks against my classmate's string concatenations with bonus no input validation queries
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 is a reasonable choice if you care about writing something that will still work out of the box 10 years from now.
But of course this assumes that you work with a team that can see a year ahead, let alone 10.
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.
This has not been my experience at all.
PHP code requires very little maintenance to keep working for a decade+.
Which specific deprecations and breaking changes are you referring to?
I’ve made my living amd career off of PHP and I enjoy its modernization.
Coding in PHP can be a lot like playing the guitar or writing poetry: many people can do it, but it’s easy to do very badly.
https://github.com/AzuraCast/AzuraCast
AzuraCast because I like learning by looking at code and hosting my own radio/music
> A lot of people are too proud to be associated with PHP.
How so?
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.
Vanity, it's "PersonalHomePage" language
> My favourite PHP product at the moment is BookStack (https://www.bookstackapp.com/), a really good wiki.
Another wiki that uses php is Wikipedia.
People like to shit on php but it powers some of the largest sites in the world.
At the end of the day, programming language doesn't matter much. You can be a good programmer in any language and a bad programmer in any language.
It's flarum for me - https://flarum.org/
A really good forum software.
The most exciting thing about the PHP8.5 announcement is the stability and maturity of PHP
PHP becomes a complex language with each update. For what reason? Its application is still limited to the web, mostly.
A lot of C# and Java code is oriented towards web backends, too. Which are quite big and complex. So it seems natural that languages in the same design space (trad OO) converge on similar features. I think the only exception these days is Go.
I think these days you could change "You can write Fortran in any language" to "You can structure your code like Spring in any language"…
The web is not getting any simpler.
Exactly, I'd even argue that web development (back & front-end) is by far the largest job / industry in software development.
I don't see how making a language more complex can help with that. Complex languages makes sense for system programming where you want to squeeze some performance.
Making a language more complex often leads to simpler code. Keeping a language too simple often forces overly complex code.
Obviously you haven't heard of NativePhp :)
Still, even if it was "just" the web, why wouldn't it evolve? It's a great language, with a big user base, and there's always room for improvements and to increase the developer experience
I downvoted you before reading the fine article. I'm back to correct that.
The new array_first() and array_last() functions are nice, everything else is either reimplantation of existing features or "features"which will make maintainability more difficult. The pipe operator is one such example. I don't need it - these nested methods are not really an issue in any codebase I've seen. The new syntax only works for unary functions, so higher arity functions must be wrapped in an arrow function. It's a mess and more bug prone than just nesting the functions.
> The pipe operator [...] syntax only works for unary functions, so higher arity functions must be wrapped in an arrow function.
It's coming - but to get PHP RFCs to pass they have to be salami-sliced, otherwise they're voted down.
https://wiki.php.net/rfc/partial_function_application_v2
The pipe operator makes it much easier to create home-grown cryptographic hash functions, as everybody used to do in the early 2000s:
Oh, now I'm convinced!
Many of the newer features have this problem. Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
Meanwhile it seemingly abandoned features and unique selling points, like the in-built templating, associative arrays with value semantics and the fact that it integrates well with C or the simple fact that it can be used to write web server scripts very easily. To me, many of these cool features have been largely ignored or even moved away from.
>Like the match keyword, enums, closures etc. They are half-baked versions of what could be powerful and expressive features.
The problem is that the php project is maintained by (mostly) unsponsored contributors. There’s not a giant corporation behind it. Each of these new features are designed by a couple people (per rfc) and then discussed and voted by other contributors. The match keyword, for example, is consider as the future scope of this rfc which is still being worked on: https://wiki.php.net/rfc/pattern-matching
Also, a lot of these half baked features are designed to be implemented in steps because of what I said in my other paragraph and to increase the odds of being accepted (it’s well known that it’s hard to get an rfc accepted and a lot of good ones haven’t been able to pass the voting phase).
When you consider this, it’s amazing that we get so much from so little.
I don't understand how this is more bug prone. The nesting is a HUGE problem because it's extremely unreadable. The arrow is much more readable, and array functions are very simple too.
How many tubes does that appear in any codebase you've worked on? Those types of constructions are typically hidden away in "helper functions" that are straightforward to understand and debug. They are certainly not typical in business logic.
Now we have two syntax to be familiar with and maintain. And you just know the clowns are going to come along and convert one syntax to the other because they can, which completely ruins the git commit and you can't tell what actual functionally was changed at a glance. There will be bickering and bikeshedding about "modernizing" codebases.
I don't know, I think it's really fine. It's very typical to compose a bunch of array functions together and, honestly, I think that's good form most of the time. This makes that a little bit easier.
I'm sort of on the opposite side. I'm unconvinced by extra functions for arrays in the global namespace and I'm happier about syntactic improvements and debugging improvements.
I'm glad to hear a dissenting opinion. Interesting that we experience PHP differently.
What is your background? I've been working mostly with PHP and Python for about 25 years. Do you come from e.g. Java?
Can’t believe we’re getting array_first, array_last and fatal error stack traces in PHP before GTA6.
Nice additions, but haven't really missed them a lot.
Most of the time if I want the first or last element I don't care about the array itself so array_shift and array_pop work just fine.
Official release notes: https://www.php.net/releases/8.5/en.php
like in `mkdir $dirname`;
That is an anti-pattern, since it suffers from shell meta-character injection (and argument injection). Since PHP has mkdir, you should use that instead. And pcntl_exec() is the correct API for running processes.
Typical users of this likely don't care the slightest about whether anyone considers it an anti-pattern, because you use those in order to write utility scripts. And those who care would use tooling to detect issues like that anyways.
Yeah, doing things wrong happens quite often. Especially for the meta-character injection issue. Personally I think language designers should deprecate and remove backticks and other shell-executing features from all languages.
The pipe operator example omits the typical way you would write this code in any language: simply by introducing temporary variables or by shadowing.
The url parse example is not being compared to the builtin parse_url function that is just as easy to use.
Parse_url isn't standards compliant, often fails with relative url's and most importantly only parses urls, not uris (with the exception of file://). I also find it's syntax clunkier than the new uri(), but that's just personal preference.
The pipe operator is indeed just syntactical sugar (and the article links to another article specifically about it which does cover the case of temporary variables), but with the coming partial function application feature it (in my opinion) will make easier to read/reason chains of code than temporary variables or nested function calls.
parse_url() also had no generate_url() counterpart - sure, it could (sometimes) split a URL into its components, but there was no safe way to modify those components and glue them back into a string. The new URI class solves that.
Adding new functions and alternative syntax has a long-term cost for PHP and the projects that use the language. I don't see much value in the new features of PHP5 announced on https://www.php.net/releases/8.5/en.php
- URI extension: there was already the internal `parse_url()` which was imperfect, and alternative libraries that were RFC 3986 compliant. An official extension will bring speed, but now there will be 2 official ways to parse URLs.
- The pipe operator is a matter of taste. In the release notes, the new code is more verbose, because it defines anonymous functions. This alternative syntax means keeping a consistent code style will be harder.
- The update of "clone" replaces 2 lines of code in some cases. Unless I misunderstood, it's a very minor change.
- The #Discard/void will replace the similar feature from static analyzers.
- Closures in constants is one of the 2 features that bring more than an alternative syntax. It's one more little step toward a preprocessor. But I'm not thrilled about the future #attributes assigned with complex closures.
- cURL persistent handles are a real performance feature, because curl_init() is costly.
- array_first() is a minor syntax-sugar. In a project of 100k+ lines of PHP, I probably could use it twice or thrice. Was it worth a global function?
PHP has really come a long way since I used it in the 90s on my first little website.
if they was something to learn it was for the Ruby community to learn from the PHP community on how to reinvent itself.
PHP like Ruby had some big companies built on it - Facebook: PHP, Ruby: Github/Shopify
PHP was able to swallow Hack and become PHP8 - they optimized for getting beginners into the language / ecosystem
Ruby while a beautiful / friendly language and ecosystem - got into political wars - didn't optimize for beginners on windows etc
even as a person who favors Rails - Laravel is ahead -> on documentation & bringing various ways to do things into the framework. There's no stick with Hotwire. You wanna do livewire go ahead, we will help you. You wanna do Inertia + JS - go ahead we will help you.
PHP should REALLY focus on getting the core stuff in shape.
Its still so annoying that you have to use mb_real_uppercase($name) for unicode. The other gripe is that the stdlib is SO messy. With PHP 5.3 they had a once in a lifetime opportunity to cleanup the stdlib and introduce a new namespaced API for builtins, and optionally introduce a uniform function call syntax:
Whenever doing PHP the time for concurrency will come sooner or later. Having no way of doing ANY concurrency is a letdown. The Fiber API does nothing on its own, and you are forced to use some third party runtime, that is usually a non-starter for legacy projects.PHP has come a long way from the PHP 4.0 era, but is still lacking in multiple areas, and i dont see it being a pick for greenfield projects in 2025.
> i dont see it being a pick for greenfield projects in 2025
You don't see it because you're not looking. There are many Laravel jobs in my area. If you think that is only for Legacy projects, might be mistaken.
Just looked at Laravel, and it feels like its trying its hardest to lipstick the PHP warts. When i look at a framework like it i see just bloat. You really only need like 5-10% of stuff thats there. Thats why its most likely slow and heavy, and looks like it was cowboy copied from some legacy .NET enterprisey framework from the early 2010s.
Jobs? Sure. There are PHP jobs, and the PHP devs are a dime a dozen. But i will agree with you, Laravel is a fine pick for websites, but not so much for more real world, high load applications.
Theres also 100x more jobs for WordPress than Laravel, so if you want to do PHP, i suggest going the WordPress route instead.
That’s a strange thing to say. If I wasn’t self employed, I’d pick the job that pays more (Laravel) instead of the job that (according to you) is 100x more available.
And who really cares about bloat anyway? Hardware is super cheap nowadays. People are expensive. So why not use a framework that enables you to be (in your terms) 100x more productive?
On top of that, you’re arguing about languages and frameworks you’re not even familiar with. Why does your opinion matter at all?
> And who really cares about bloat anyway? Hardware is super cheap nowadays.
That told me all i need to know. When you work on missing critical software bloat is usually THE killer in disguise. And its really hard to get rid of after a certain point.
> So why not use a framework that enables you to be (in your terms) 100x more productive?
Because i can be just as productive, and even more so by vetting, and choosing my dependencies with some hindsight. I dont cowboy pick some hype of the day thing, i take a real close look at the code and want to actually understand whats happening.
> On top of that, you’re arguing about languages and frameworks you’re not even familiar with.
I am indeed familiar with the PHP ecosystem, been there and done that.
Yeah, the core ergonomics is significantly lagging behind most other backend languages despite improvements in some areas. I even wrote an article https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab... .
As for concurrency/async, it's possible to do requests in parallel with curl_multi_*. Other async/prallel things are also possible, but tend to be more complicated compared to JS or other languages with promise and async support.
When I look at the new pipe syntax ...
... I think why not just something like the following?The three dots in trim(...) make a callable out of a function, that was already in, so seem best to re-use that syntax, at least for now. [1]
As for the partial function application, there is already an RFC to add that, but it's not decided on as of now. [2]
1: https://www.php.net/manual/en/functions.first_class_callable...
2: https://wiki.php.net/rfc/partial_function_application_v2
Your second option was rejected years ago I believe. The pipes were designed to work alongside this rfc that was supposed to be in this new version (8.5) but due to time constraints it had to be delayed and it’s currently being voted https://wiki.php.net/rfc/partial_function_application_v2
That example in article is straight up terrible. The Java version would be:
That is until you realize there is no reason to go weird with arrow operators when String is an object: It looks like they solved the wrong issue but that is probably just side effect of using trivial examples.One of the things I have noticed in languages is that after some iterative evolution the piled on features and syntaxis sugar make them look bizarre and hard to read. Probably the weight of backwards compatibility and that the initial paradigms have picked up the easy to understand real estate. And there are no good ways of getting out of the corner you have coded yourself in.
Probably because compile/interpret is one way street. There is no way to lets say view/transform a part of the code in functional or imperative depending on what you need to do with it.
Reading modern php or even worse mixed generations code base feels like another full time job on top of the regular one - coding with it.
PHP is still an incredibly verbose and tedious language to work with. I'm glad that it's continuing to improve because I'm stuck with it everyday.
Why is it that all these languages like PHP, but also typescript are becoming like impossible puzzles to read. I find these generics, types and other language features very often causing complex software architecture. I see so many collegues these days struggling in understanding codebases. You almost need a PHD brain to be a frontend web developer.
Counterpoint (from the same website): https://stitcher.io/blog/evolution-of-a-php-object
PHP 8.2 has this:
``` readonly class BlogData
{
}```
Whereas in php 5.6, to accomplish the same you need all this:
``` class BlogData { /* @var string / private $title;
} ```I assume it is some inferiority complex, on many sides. PHP itself was laughed at being too simple, underpowered and inconsistent, now they overcorrected with types, annotations and breaking backwards compatibility with every release so that no old code base can remain intact. Frontend devs yearned to be regarded as real developers, which in their context means construction of unwieldly and overcomplex enterprise bullshit, thus typescript etc. And in the backend you have that same mechanism, devs having to prove they are no beginners and thus using (wrongly) design patterns, instructed by software architects, instead of avoiding abstraction and thus complexity.
No, I'm not bitter.
Can you share an example of what you're talking about in PHP 8.5? On the linked web page, the only code pattern that looks remotely complicated to me is the following:
It's somewhat comforting to read my insecurities shared by others in this thread
Which parts of PHP have become harder to read?
Like on of my sibling comment, I truly believe this is connected to some degree of social pressure.
People pointing fingers to "outdated" languages for not having some of the most trendy constructs.
The pipe operator is definitely one of the feature that create more ways to do the same thing while providing unclear benefit.
Never in my life I was in a situation like "with the pipe operator this I would have saved me hours of debugging/reading/creating code".
Is PHP still unhelpful when it comes to writing secure code?
I remember when escaping SQL input data was "the correct way" to use your mysql database. Parametrization? Nah, just use mysql_escape_string or whatever it was called.
php has kept around a lot of functionality that can be misused, but PDO has had parameterization since forever and is the go to method if you want to connect to a database. Beyond that though, most PHP projects at this point are likely using a query builder/orm like eloquent.
So I guess it depends on what you mean by unhelpful. PHP as a language makes it pretty easy to do bad stuff. PHP as a community makes it easy to Do The Right Thing.
Prepared statements have been available in PHP for over 20 years, when it deprecated the old mysql libraries. They were removed entirely in PHP 7.
And let's be real - most handwritten SQL code in existence in most languages just builds queries from concatenated strings, even when more secure options exist. A lot of code doesn't even bother to escape anything. That's not a language problem so much as a developer laziness and assumption that "simplicity always equals correctness and frameworks are always wrong" problem.
You use PDO and prepared statements. Although realistically, you are going to be using a framework and some kind of Active Record pattern.
SQL named parameters was a feature introduced into PHP on 24th Nov 2005, with the release of PHP 5.1.0.
the MySQL extension was dropped in PHP 7.0.
Looking forward for true async to land - nothing here gets me too excited.
You probably know about https://openswoole.com right?
still remember been on #php with count down to php3 announcement
I remember the discussions at the time about which filename extension to use - and I can not believe that .php3 won. I think that I was the first to bring up the subject for PHP 4, to use .php again and not include the version number.
i still have phtml and php3 files somewhere in backups. used to run on php one of biggish local sites that you probably know
Starts with the letter R? PHP of that era, completely procedural with concatenated SQL, such fond memories.
not with R. with P
Thanks PHP for bringing pipe operator in 2025.
Do people have any recommendations for modern PHP tutorials and learning sources?
Yes, see: https://news.ycombinator.com/item?id=39989663
---
Books:
* PHP & MySQL: Novice to Ninja by Tom Butler
* PHP 8 - Quick Scripting Reference by Mikael Olsson
* PHP 8 Objects, Patterns, and Practice by Matt Zandstra
* Programming PHP (2020) by Kevin Tatroe and Peter MacIntyre
I personally found them to be really good. I learned a lot from the first book especially.
You can find the code from the first book here: https://github.com/spbooks/phpmysql7
I hope this helps.
https://phptherightway.com/ Is a good place to start
arggg.... PHP introduce pipe operator before ecmascript. I want it in Javascript!
Has NativePHP gotten any legs?
tl;dr: nothing interesting, just stability and maturity
And a pipe operator, which is also being discussed in a number of other languages.
It seems that pipe operator was introduced largely because PHP arrays and strings don't have "methods". You can't write something in "OOP" style: "some_string"->str_replace("some", "replacement")->strtoupper(). With PHPs array / string procedural way writing such chains is much bulkier. Pipe operator will somewhat reduce the boilerplate, but the native "OOP" style is still much better.
Although there is a proposal for adding "methods" but I don't remember the link.
I'm not a blind PHP hater, but it seems like PHP community members sometimes celebrate new PHP features when their equivalents have been there for many years in other programming languages. https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab...
No, the OOP style isn't better. The set of functions one can use in OOP is closed.
Imagine I want to AfD a custom string function for a feature which uPpErCaSeS every second letter as I need that for some purpose: I can't do in OOP style.
In OOP I could extend the string class, but most other parts of the code won't magically use my string type now.
Thus I have to create a free standing function for this (which probably also is better as I don't need internal state of thee object, thus livingnoutisde is good for encapsulation)
And thus my string function works different from other string functions.
(The example of course is non sensical and could be reordered, but we argue syntax)Having them all be simple functions makes it equal.
Of course there are alternative approaches. C++ argues for years about "uniform call syntax" which would always allow "object style" function calls, which could also find non-memwbr functions where the first argument is of compatible type, but such a thing requires stricter (or even static) typing, this won't work in PHP.
[flagged]
What do you mean developers should deal with functions like those? They're used when necessary, yes, just like any function. And no IDE is required. I'm really puzzled.
> And no IDE is required.
What else to say, good luck.
You didn't get the anecdote, that's probably because you haven't worked with PHP (long enough).
I will give hint: inconsistency.
Either working with PHP for 21 years is not long enough or simply too long. I honestly think these small inconsistencies are irrelevant in the big picture of building something complex. Like you said, programmers should deal with them. It just doesn't sound like a big deal.
> I honestly think these small inconsistencies are irrelevant in the big picture of building something complex.
Big picture is PHP is a poor tool. I enumerated only one annoyance about writing software on PHP, 80% of all websites on the web being built on it doesn't make it any better. Some companies keep building on it, because:
1. They started writing the codebase in PHP, now they are "locked" (cost of switching to another language is extremely high)
2. Hiring PHP developers usually costs a lot less (at least 20%) than say Java/Python developers
People keep arguing that, for seasoned developers it doesn't matter what tool one chooses. Then what is the point of choosing a tool over another, if you gotta check the docs constantly for inconsistencies? (I'm sorry, you gotta use IDE anyways)
With that said, there is no ideal language, however PHP is single most annoying language after JavaScript.
PHP should do a real major compatibility break and remove $ sigil from variable names. It's gonna be worth the pain!
Hello Perl 6!
Such a change makes it a completely different language with no compatibility. Thus all previous code is lost, no easy migration paths (especially for libraries which would like to support both during transition)
I would love that. But yeah, it would probably kill PHP because it would break all code.
Maybe https://getrector.com could auto-fix 99% of code but it would still be very hard to get adoption.
Would it though? I’ve been thinking about this for a while.
What about introducing a new file extension for this? Something like MyClass.p so that .php is for classic syntax and .p Can support newer syntax? You could support old codebases while at the same time support better syntax.
It’s probably too much for the core php team to maintain both though
I think php should have stopped at php4 or php5 and maybe just develop a new/sane standard library.
And a new language could have been developed , call it hack or whatever Facebook tried. Anyway I remember php coding gave me headaches. Tried it again 2 years ago and found out the same kind of issues(outdated /inexistent documentation, different ways to do the same thing that actually didn’t work and stuff like that). Try to connect to sql database using ssl and see what I mean.
I see no reason to learn PHP anymore or start up your company using php. We live in a vps/docker age. The advantage of php hosts everywhere has been lost.
Without specifics it's hard to understand what kind of difficulties you had.
But PHP is still so strong because it offers much more than "easy hosting".
What I personaly love most is the instant save file->see results feedback loop. There's no perceptible compilation step. Meanwhile my Java project takes a minute to compile.
Also the shared-nothing model by default is powerful and rare.
Laravel is probably the most well documented frameworks even comparing frameworks from other languages. And symfony, also a PHP framework, is not far from that.
When you say "SSL" I can only think your reasoning is based on outdated information since no one calls it SSL anymore. It's TLS for some years now. And I have been connecting to databases using PHP TLS/SSL since version 5. For almost a decade now.